Re: [VOTE] Release CXF dOSGi 1.0
Hi Dan, On the samples, they are not part of the distribution because they can be installed straight from the internet. All of the DOSGi documentation is available here: http://cxf.apache.org/distributed-osgi.html and which contains links to the sample source code and a very detailed walkthrough of the greeter sample: http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html As the OSGi containers install stuff straight from the internet, you don't have to have the bundles available locally. Once the release is out I'm planning to update this page to point straight to the sample artefacts in maven. There is no such page for the spring-dm demo, I'll take an action to provide such a page with the DOSGi documentation, but I don't think this should hold up the release. Hope this makes sense to you, David 2009/5/4 Daniel Kulp : > > I think I have to -1 this. Couple legal things need to get ironed out: > > 1) Since this is a full "distribution" type thing, what parts of that staging > area will go into www.apache.org/dist/cxf? I ASSUME the mutimodule bundle, > but not really sure. Also, there needs to be a tar.gz or zip of a "source" > distribution of the whole contents of the tag. That would also go into > dist. > > 2) I think some stuff in the NOTICE can be removed. For example: DOSGi > doesn't ship the MTOSI stuff, that could be removed. Not major, but if a > build has to be respun, let's get that cleaned up. > > 3) For the "distribution" builds, the LICENSE file needs to have at least the > pointers to the LICENSES of the bundled deps appended to it. See the LICENSE > in the cxf distributions. (remote-resources can do that, I may be able to > help out tomorrow if I get out from under my backlog of email. :-( ) > > 4) Actually, IS there a distribution that includes the samples, possible a > readme, etc...? Should there be? Not a big deal either way, but a bit > strange. > > > Dan > > > > > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote: >> Folks, >> >> I'm calling a vote to release CXF Distributed OSGi 1.0. >> >> The dOSGi subproject of CXF provides the Reference Implementation of >> the Distribution Software (DSW) component of the Distributed OSGi >> Specification[1]. >> >> The staging area can be found at: >> >> http://people.apache.org/~eglynn/stage_cxf_dosgi >> >> This release is tagged with cxf-dosgi-ri-1.0 at: >> >> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 >> >> The vote will remain open for at least 72 hours. >> >> Please consider this call to vote as my +1. >> >> Cheers, >> Eoghan >> >> [1] See RFC 119 in http://www.osgi.org/download/osgi-4.2-early-draft3.pdf > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Fwd: [VOTE] Release CXF dOSGi 1.0
Sent this earlier to dkulp individually, I meant to reply-all. -- Forwarded message -- From: Eoghan Glynn Date: 2009/5/5 10:13 Subject: Re: [VOTE] Release CXF dOSGi 1.0 To: Daniel Kulp 2009/5/4 Daniel Kulp : > On Mon May 4 2009 5:30:49 pm Eoghan Glynn wrote: > >> On issue #4, I'm of a mind to just pull in the samples bundles >> directly in from maven. This is especially convenient when using the >> Pax URL mvn protocol, allowing a mvn:groupId:artifactId:version style >> of URL to referenced directly from the OSGi shell. This would be the >> most natural approach for SMX4 in any case (BTW I'm planning to wrap >> dOSGi up as a couple of SMX4 features, which would add another layer >> of convenience). > > Well, part of the purpose of a "sample" is to provide the CODE for the sample > so they can see how it works, modify it, learn from it, etc... Pulling the > existing stuff from maven kind of defeats that purpose, does it not? Well no, I wouldn't say it defeats the purpose. The demo is described in a very detailed walkthrough on the wiki[1] with links into SVN for browsing the code. I think this is sufficient for understanding and learning etc. Note the dOSGi samples are a bit different from the core CXF demos in that the emphasis is on the simplicity of enabling pre-existing OSGi code for distribution. So the actual application code is really of secondary importance. The crucial thing is the few knobs that need to be set in order to transparently expose or consume an OSGi service as a remote web service. Cheers, Eoghan [1] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html
Re: [Build Error] Missing Artifact
Hi http://people.apache.org/repo/m2-incubating-repository/org/apache/abdera/abdera-i18n/0.4.0-incubating/ contains this jar - may be it was a transient error ? cheers, Sergey - Original Message - From: "rahul.soa" To: Sent: Monday, May 04, 2009 9:47 PM Subject: [Build Error] Missing Artifact Hello Devs, I am trying to build Apache CXF, checking out from here svn co http://svn.apache.org/repos/asf/cxf/trunk I am getting the following error while running with -e option. Could you please help me in this? Many Thanks. Rahul *//quote* Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/abdera/abdera-i18n/0.4.0-incubating/abdera-i18n-0.4.0-incubating.jar 595K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/abdera/abdera-i18n/0.4.0-incubating/abdera-i18n-0.4.0-incubating.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.2-SNAPSHOT 2) org.apache.abdera:abdera-core:jar:0.4.0-incubating 3) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating -- 1 required artifact is missing. for artifact: org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.2-SNAPSHOT from the specified remote repositories: apache.incubating (http://people.apache.org/repo/m2-incubating-repository ), ibiblio.org (http://repo1.maven.org/maven2), maven2-repository.dev.java.net (http://download.java.net/maven/2/), apache.org (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-i18n -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.2-SNAPSHOT 2) org.apache.abdera:abdera-core:jar:0.4.0-incubating 3) org.apache.abdera:abdera-i18n:jar:0.4.0-incubating -- 1 required artifact is missing. for artifact: org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.2-SNAPSHOT from the specified remote repositories: apache.incubating (http://people.apache.org/repo/m2-incubating-repository ), ibiblio.org (http://repo1.maven.org/maven2), maven2-repository.dev.java.net (http://download.java.net/maven/2/), apache.org (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at or
Re: [VOTE] Release CXF dOSGi 1.0
OK. That kind of make sense (along with what Eoghan said). However, I really think there needs to at least be a "README" in the distributions that describes a little what it is along with pointers to the walkthroughs and such on the website. Right now, I download and unpack the the tarball and I look at it and say "uhh. what do I do with this?"We definitely need a readme in there to describe things as well as provide pointers off to the web site, the users@ list for questions, etc. Dan On Tue May 5 2009 5:31:49 am David Bosschaert wrote: > Hi Dan, > > On the samples, they are not part of the distribution because they can > be installed straight from the internet. All of the DOSGi > documentation is available here: > http://cxf.apache.org/distributed-osgi.html and which contains links > to the sample source code and a very detailed walkthrough of the > greeter sample: > http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html > As the OSGi containers install stuff straight from the internet, you > don't have to have the bundles available locally. Once the release is > out I'm planning to update this page to point straight to the sample > artefacts in maven. > > There is no such page for the spring-dm demo, I'll take an action to > provide such a page with the DOSGi documentation, but I don't think > this should hold up the release. > > Hope this makes sense to you, > > David > > 2009/5/4 Daniel Kulp : > > I think I have to -1 this. Couple legal things need to get ironed out: > > > > 1) Since this is a full "distribution" type thing, what parts of that > > staging area will go into www.apache.org/dist/cxf? I ASSUME the > > mutimodule bundle, but not really sure. Also, there needs to be a > > tar.gz or zip of a "source" distribution of the whole contents of the > > tag.That would also go into dist. > > > > 2) I think some stuff in the NOTICE can be removed. For example: DOSGi > > doesn't ship the MTOSI stuff, that could be removed. Not major, but if > > a build has to be respun, let's get that cleaned up. > > > > 3) For the "distribution" builds, the LICENSE file needs to have at least > > the pointers to the LICENSES of the bundled deps appended to it. See > > the LICENSE in the cxf distributions. (remote-resources can do that, I > > may be able to help out tomorrow if I get out from under my backlog of > > email. :-( ) > > > > 4) Actually, IS there a distribution that includes the samples, possible > > a readme, etc...? Should there be? Not a big deal either way, but a > > bit strange. > > > > > > Dan > > > > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote: > >> Folks, > >> > >> I'm calling a vote to release CXF Distributed OSGi 1.0. > >> > >> The dOSGi subproject of CXF provides the Reference Implementation of > >> the Distribution Software (DSW) component of the Distributed OSGi > >> Specification[1]. > >> > >> The staging area can be found at: > >> > >> http://people.apache.org/~eglynn/stage_cxf_dosgi > >> > >> This release is tagged with cxf-dosgi-ri-1.0 at: > >> > >> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 > >> > >> The vote will remain open for at least 72 hours. > >> > >> Please consider this call to vote as my +1. > >> > >> Cheers, > >> Eoghan > >> > >> [1] See RFC 119 in > >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to determine whether a soap message have an attachment
Doesn't it already support MTOM? Basically, it provides a OutputSteam to the dispatching and if the runtime needs to handle attachments and such, it will write it as mime stuff to the stream. Dan On Tue May 5 2009 12:53:48 am liucong wrote: > Hi all, > > When I want to add MTOM support for SOAP/JMS, I should know whether a > soap message have an attachment. But I don't know the details how to > judge wheter the message have an attachment. > Is anyone give me any prompt about where the code is? Or some code example? > > Thank you very much. > > Best regards > > Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: WSDL Usage for SOAP/JMS specification
I think the place to look at would be the JMSOldConfigHolder.createJMSConfigurationFromEndpointInfo method. You'll probably need/want to create a similar method for the "new" style stuff. In that method, you see the EndpointInfo is passed in and extensors are grabbed from there (would correspond to the wsdl port).The EndpointInfo also holds onto it's ServiceInfo (wsdl service) and the BindingInfo (which would be the wsdl binding). Thus, you should be able to grab the extensors from all the various locations and process them appropriately. Dan On Mon April 27 2009 11:10:25 pm liucong wrote: > Hi, All, Willem, > > In the past several days, We have discussed the usage of JMS transport, > MTOM over SOAP/JMS. By debugging the code of CXF and JMS Transport, I > think I have know the overview of the CXF and JMS Transport.(Except > Spring configuration). > > I want to learn another eara about WSDL usage for > SOAP/JMS(http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-extensions). > In the current JMS implementation, you use the WSDL extension to get the > WSDL information(Is it right?). In the SOAP/JMS specification, the > properties about SOAP/JMS can be placed in three places(Binding, > Serivce, Port). I should get these information. > There are several methods to finish it. > 1. I parse the WSDL, and get information what I need. It is not good. > 2. I use the WSDL extension to get information and SOAP/JMS URI. > > After I get the information from WSDL. What I need to do is to parse > these information, and to get the right configuration which obey the > overriding rules specified in the SOAP/JMS spec. > The orerriding rules is: If a property is specified at multiple levels, > the most specific setting will take precedence (port first, then > service, then binding). > > How can I get the WSDL information for SOAP/JMS specification? Are there > some methods to finish this job or help documentation? > Are the overriding rules already implementation in WSDL parser? If not, > I should consider how to implementation the orverriding rules easily. > > > Best regards > Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
