Thanks! Ciao, Philipp
> -----Mensaje original----- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 17 de mayo de 2007 15:21 > Para: [EMAIL PROTECTED] > Asunto: Re: Remote deployment of service assemblies > > See http://issues.apache.org/activemq/browse/SM-858 > which has been fixed a few weeks ago in trunk. > > On 5/17/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > > > 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: [EMAIL PROTECTED] > > > 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 same server, because the console accepts uploads and > > will > > > > > > > be able to point the container to a local file. > > > > > > > > > > > > > > The only way using JMX would be to add a method accepting a > > byte[] > > > > > > > parameter which would be the content of the JBI artifact to > > > > deploy, or > > > > > > > creating an management endpoint on the JBI bus (using an > > > > attachment > > > > > > > for the JBI archetype). Not sure what's the best way. > > > > > > I was thinking about this alternative, as well. There could be a > > > > > > provider service that accepts calls having an SA attachment. It > > > > could > > > > > > then obtain this attachment and physically place it in the > > > > deployment > > > > > > dir. > > > > > > > > > > > > > > > Using the hot deployer is imo not the best solution. > > > > > We should use the AdminCommandsService instead (see below) > > > > > > > > > > In that way, one could use the same access control mechanism as > > for > > > > the > > > > > > rest of the service invocations. Another advantage would be that > > > > through > > > > > > the different binding components, the functionality would be > > > > available > > > > > > in more than just Java. > > > > > > > > > > > > > > > Yeah, agreed. We just need to define a clean WSDL for it. > > > > > > > > > > However, I'd need to access some JBIContainer properties, such as > > the > > > > > > deployment directory. I assume that the best way to obtain > > internals > > > > > > about the JBI container would be to use the client API > > > > > > (http://incubator.apache.org/servicemix/client-api.html). > > > > > > > > > > > > I could then use the following code: > > > > > > >> > > > > > > ... > > > > > > DeliveryChannelImpl dci = (DeliveryChannelImpl) > > > > > > defaultSMClientInstance.getDeliveryChannel(); > > > > > > JBIContainer container = dci.getContainer(); > > > > > > ... > > > > > > String deploymentDirPath = container.getDeploymentDirPath(); > > > > > > ... > > > > > > << > > > > > > > > > > > > However, this hack seems quite (if not: too) dirty. Is there a > > more > > > > > > elegant solution? > > > > > > > > > > > > > > > > > > > > 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() ... > > > > > > > > > > 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. > > > > > > > > > > .. and discussions about servicemix developement should take place > > on > > > > the > > > > > dev > > > > > list ... ;-) > > > > > > > > > > Thanks in advance, > > > > > > Ciao, > > > > > > Philipp > > > > > > > > > > > > > -----Mensaje original----- > > > > > > > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > > > > > > > Enviado el: lunes, 19 de marzo de 2007 16:01 > > > > > > > Para: [EMAIL PROTECTED] > > > > > > > Asunto: Re: Remote deployment of service assemblies > > > > > > > Importancia: Baja > > > > > > > > > > > > > > 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 same server, because the console accepts uploads and > > will > > > > > > > be able to point the container to a local file. > > > > > > > > > > > > > > The only way using JMX would be to add a method accepting a > > byte[] > > > > > > > parameter which would be the content of the JBI artifact to > > > > deploy, or > > > > > > > creating an management endpoint on the JBI bus (using an > > > > attachment > > > > > > > for the JBI archetype). Not sure what's the best way. > > > > > > > > > > > > > > On 3/19/07, Rossmanith, Philipp > > <[EMAIL PROTECTED]> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > In our project, we have several client applications that > > need to > > > > > > deploy > > > > > > > > and undeploy service assemblies at runtime. The majority of > > them > > > > are > > > > > > > > written in Java, others not. > > > > > > > > > > > > > > > > It seems that remote administration is something that would > > best > > > > be > > > > > > > > handled by the administration Ant tasks. > > > > > > > > > > > > > > > > Ant tasks can be called from Java code: > > > > > > > > http://ant.apache.org/manual/antexternal.html > > > > > > > > > > > > > > > > Now I was wondering: > > > > > > > > If I need to do remote un-/deployment from within client > > > > > > applications, > > > > > > > > is there already some existing API for doing that? Perhaps > > an > > > > > > Endpoint > > > > > > > > accepting service assemblies? If not, would some > > Java-wrapper > > > > around > > > > > > the > > > > > > > > aforementioned Ant tasks be a viable alternative? > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > > Ciao, > > > > > > > > Philipp > > > > > > > > > > > > > > > > This e-mail may contain confidential or privileged > > information. > > > > Any > > > > > > > > unauthorised > > > > > > > > copying, use or distribution of this information is strictly > > > > > > prohibited. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Cheers, > > > > > > > Guillaume Nodet > > > > > > > ------------------------ > > > > > > > Architect, LogicBlaze (http://www.logicblaze.com/) > > > > > > > Blog: http://gnodet.blogspot.com/ > > > > > > > > > > > > This e-mail may contain confidential or privileged information. > > Any > > > > > > unauthorised > > > > > > copying, use or distribution of this information is strictly > > > > prohibited. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Cheers, > > > > > Guillaume Nodet > > > > > ------------------------ > > > > > Architect, LogicBlaze (http://www.logicblaze.com/) > > > > > Blog: http://gnodet.blogspot.com/ > > > > > > > > This e-mail may contain confidential or privileged information. Any > > > > unauthorised > > > > copying, use or distribution of this information is strictly > > prohibited. > > > > > > > > > > > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > ------------------------ > > > Architect, LogicBlaze (http://www.logicblaze.com/) > > > Blog: http://gnodet.blogspot.com/ > > > > This e-mail may contain confidential or privileged information. Any > > unauthorised > > copying, use or distribution of this information is strictly prohibited. > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
