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? > .. 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: servicemix-users@geronimo.apache.org > 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: servicemix-users@geronimo.apache.org > > > 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.
