Re: [VOTE] Release ServiceMix 3.1.1
Guillaume, I've just retried a few of the samples as well as some of my own SAs. Everything seems to work fine, so here's my +1 now... Gert gnodet wrote: > > It should be fixed now. I have updated the tag and uploaded a new distro. > Thanks for reporting that ! > > On 5/16/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: >> >> >> L.S., >> >> The WSDL-first example doesn't seem to work. It gives a >> javax.jbi.messaging.MessagingException: Do not understand pattern: null >> when >> testing it with the client.html on this machine. The xbean.xml file no >> longer contains the defaultMep attribute (has been removed while solving >> SM-901: Upgrade to xfire 1.2.5). >> >> Regards, >> >> Gert >> >> >> gnodet wrote: >> > >> > I have uploaded a version of ServiceMix 3.1.1 in the standard repo >> > for you to review. See >> > http://incubator.apache.org/servicemix/servicemix-311.html >> > for all the links and release notes. >> > >> > [ ] +1 Release ServiceMix 3.1.1 >> > [ ] +/- 0 >> > [ ] -1 Do not release ServiceMix 3.1.1 >> > >> > I will upload a rat report asap. >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> > >> > Principal Engineer, IONA >> > Blog: http://gnodet.blogspot.com/ >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.1-tf3758807s12049.html#a10639960 >> Sent from the ServiceMix - Dev mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.1-tf3758807s12049.html#a10671058 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release ServiceMix 3.1.1
On 5/17/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: > [ X ] -1 Do not release ServiceMix 3.1.1 > > I will upload a rat report asap. I figure I'll -1 this before it gets to [EMAIL PROTECTED] Issues: 1) Procedural: you published these into the release repository. Thus, they are already released. They should be staged into a staging area, voted on there, then if the vote passes, moved into the release repository. As it stands right now, it's technically already released without a vote. One of the problem is to be able to test it. Archetypes depends on the repository where the artifacts are deployed, so if you deploy to a staging repo, there's no way to test them. The problem only happen because we are in incubation, thus artifacts are not available through public repository. Btw, the maven incubating repo is not completely endorsed by the ASF, so I don't think they should be considered released as soon as they are there. Anyway, the main problem is the former and I don't see any simple solution to it unfortunately. 2) The sources jars and javadoc jars don't have the disclaimer, notice, or license files in them. Thus, they are not releasable. (look into the remote-resources plugin, the cxf/trunk/parent pom is an example.) We use our own plugin for that. I guess we can switch to the official one it it works better. 3) Nothing has been gpg signed. All release artifacts must be gpg signed. A "release" profile with the gpg plugin would solve this. (you can use the cxf/trunk pom as an example) This is already configured, but using maven release plugin is not really an option. I just forgot to activate the profile :-( Anyway, IMO, it's not ready to go.If you have problems with the maven stuff, feel free to ping me. I'd be glad to help out. Thanks ! I'll fix that and redeploy a release. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release ServiceMix 3.1.1
On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: > [ X ] -1 Do not release ServiceMix 3.1.1 > > I will upload a rat report asap. I figure I'll -1 this before it gets to [EMAIL PROTECTED] Issues: 1) Procedural: you published these into the release repository. Thus, they are already released. They should be staged into a staging area, voted on there, then if the vote passes, moved into the release repository. As it stands right now, it's technically already released without a vote. 2) The sources jars and javadoc jars don't have the disclaimer, notice, or license files in them. Thus, they are not releasable. (look into the remote-resources plugin, the cxf/trunk/parent pom is an example.) 3) Nothing has been gpg signed. All release artifacts must be gpg signed. A "release" profile with the gpg plugin would solve this. (you can use the cxf/trunk pom as an example) Anyway, IMO, it's not ready to go.If you have problems with the maven stuff, feel free to ping me. I'd be glad to help out. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
[jira] Created: (SM-952) ClassLoaderXmlPreprocessor not able to load shared libraries from xbean.xml
ClassLoaderXmlPreprocessor not able to load shared libraries from xbean.xml --- Key: SM-952 URL: https://issues.apache.org/activemq/browse/SM-952 Project: ServiceMix Issue Type: Bug Components: servicemix-common Affects Versions: 3.2 Reporter: Honi Jain Priority: Critical Fix For: 3.2 Attachments: ClassLoaderXmlPreprocessor.java If we dont specify location child node but specify library child node of parent node classpath in xbean.xml we are getting Null Pointer Exception when we deploy our service assembly in servicemix. getClassLoader method of ClassLoaderXmlPreprocessor parses the xbean.xml for the tag 'classpath'. For loading shared-libraries it searches for the child nodes with tag name 'library'. After it found all the child library nodes it adds to the arraylist for the shared library using the child node list of 'location'. This will give null pointer exception if no location node is there. Even if location node is present when the code will try to look for shared library it will give an error. I am attaching the patch file ClassLoaderXmlPreprocessor .java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Remote deployment of service assemblies
Hi, After quite a break, I am back with the issue relating to this thread. What I did was creating a jsr-181 WSDL first service, for which I set a ComponentContext *). The setup is different from what had been outlined earlier, as I am creating a service assembly ZIP based on parameters I receive. My idea was to obtain a DeliveryChannelImpl from the ComponentContext and to then follow the steps Guillaume has pointed out below. However, the ComponentContext that is being set by SM is an EndpointComponentContext which doesn't give me access to this information. Any hints of how I can get hold of the JBIContainer or its AdminCommandsServiceMBean? Thanks in advance, Ciao, Philipp *) http://incubator.apache.org/servicemix/servicemix-jsr181.html **) For the moment, I am creating a service assembly zip file for WSN subscriptions once the service gets invoked. Parameters are the wsa:address, the topic and an identifier. > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: martes, 20 de marzo de 2007 11:21 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: Remote deployment of service assemblies > > On 3/20/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > Once you have the JBIContainer, just retrieve the needed interface: > > > JBIContainer container = dci.getContainer(); > > > AdminCommandsServiceMBean admin = > > container.getAdminCommandsService(); > > > > > > Then, you can use it to deploy / undeploy, manage life cycle, etc .. > > >admin.installComponent() > > >admin.startComponent() > > >admin.listServiceAssemblies() ... > > Ok, that is quite a bit cleaner... > > > > > all the administrative tasks are available from this interface, so I > > guess > > > the WSDL > > > should be quite easy to write. On the implementation side, one way is > > to > > > use > > > jaxb2 (not the full jsr181 though) as done in the WS-Notification > > > component. > > > See org.apache.servicemix.wsn.component.WSNEndpoint class. > > What I was thinking about was a WSDL wrapper around the > > AdminCommandsServiceMBean methods. > > > > I'm currently investigating the WSN component to use it for > > notifications based on message content (see > > http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me > > ssageExchange--content-tf3409844s12049.html), but I must say I'm afraid > > I don't really understand your idea (which may be due to my limited > > experience with jaxb2). > > > > It seems to me that the wsn component WSNEndpoint uses the annotations > > done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy (an > > object of this class is passed in as "pojo" in the constructor) to > > obtain a class object "endpointInterface" which is then used to get hold > > of the methods published in that interface. Jaxb2 seems to be used to > > unmarshal incoming normalized message content and to marshal it to > > outgoing exchanges (method: process). > > > > However, if I'm ""only"" writing a provider service and not a > > full-fledged component, what would be the advantages of the approach > > taken in WSNEndpoint? > > > > Or am I misinterpreting, and you're using jaxb2 for creating a jsr181 > > code skeleton based on a previously generated WSDL? > > > Yeah, that's the point. > The WSNEndpoint is used to invoke an annotated POJO generated > from the WSDL like AbstractNotificationBroker. > The AbstractNotificationBroker#init method calls register, which > ultimately > creates a WSNEndpoint with the AbstractNotificationBroker class as the > pojo. > > So, once the WSDL is written, you can use wsgen to generate the interfaces > and messages, create your own POJO implementation and wrap it with > the WSNEndpoint. (It makes me think that this class may be put in > servicemix-common). > > But this is only one way to do that. Feel free to use your own if you > prefer. > > The last question is how do we package that. I'm thinking about > a SE, but without any support for deployments of SU, > I guess another way could be to leverage the JSR181 component and > just write a SU for it (and another for the http BC i guess). > The last way would be to configure it directly on the JBI container > without any JBI packaging ... > Need to think about pros / cons ... > > > .. and discussions about servicemix developement should take place on > > the > > > dev > > > list ... ;-) > > Done :-) > > > Thanks in advance, > > Ciao, > > Philipp > > > > > -Mensaje original- > > > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > > > Enviado el: lunes, 19 de marzo de 2007 16:56 > > > Para: [EMAIL PROTECTED] > > > Asunto: Re: Remote deployment of service assemblies > > > Importancia: Baja > > > > > > On 3/19/07, Rossmanith, Philipp <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > > Currently, remote deployment is not supported by the ant tasks. > > > > > The only way to do currently that is to start a servicemix console > > > > > on the sam
