ServiceMix 3.1.1 release - when?
Dear all, I've been following the vote about releasing 3.1.1. Did you reach a decision yet? When will it be released? Ciao, Philipp This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
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 :-) >
RE: [jira] Doc reorg
Some propositions: - Everything under Documentation>Architecture should be moved to Developers>... - In Developers, a division into information related to administration (e.g. becoming a committer, ...) and coding (e.g. architecture) would be appreciated - Supplying the glossary with names of standards and links to their implementations (e.g. WS-Notification) - Developers>Tools and Tooling and Utilities is misleading - One could divide the User documentation into parts which are related to/required by the JBI standard (such as explanation of JBI, Ant tasks) - servicemix-common might better be placed at a different location - Tutorials and Guides should be joined - User's guide>ServiceMix Components seems to be redundant with Documentation>...>JBI Components - Lightweight components could be placed under servicemix-lwcontainer to emphasize their connection Ciao, Philipp > -Mensaje original- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 15 de marzo de 2007 11:44 > Para: servicemix-dev@geronimo.apache.org > Asunto: Re: [jira] Doc reorg > > Looks quite nice, congrats :-) > I'm not very keen on changing the underlying engine, > but the folding menu on the left seems quite usable. > > As Philip noted, it would be a nice and easy enhancement ... > Is anyone willing to take a look at writing css /javascript > to have a nice folding menu for ServiceMix ? > > On 3/15/07, kermitt <[EMAIL PROTECTED]> wrote: > > > > > > I would suggest to hav a look at what have done ivy , really great > > http://incubator.apache.org/ivy/write-doc.html > > > > > > > > gnodet wrote: > > > > > > I think we need to reorg the docs so that one can more easily > > > find the informations (we also need to write more docs, but that's > > > another problem). Currently, the only way to really find a page is > > > to go to the site map and browse ... > > > > > > Any ideas on how to do that ? > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > > > > Architect, LogicBlaze (http://www.logicblaze.com/) > > > Blog: http://gnodet.blogspot.com/ > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/Doc-reorg-tf3269938s12049.html#a9491730 > > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > > > > > > -- > 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.
RE: [jira] Commented: (SM-846) Call to default constructor ofJBIContainer changes log4j log level
Hi Guillaume, Sorry, I was already out of office when you sent the mail... I saw that you did a fix, and I'll check if it works for me. Thanks! The problem first occurred in one of my own test cases, but then I reproduced it in the SecuredBroker test case by instantiating a Logger there right before the call to the JBIContainer constructor and observing the log level of its parent, which switched from ALL to ERROR. Ciao, Philipp Rossmanith > -Mensaje original- > De: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 16 de febrero de 2007 19:48 > Para: servicemix-dev@geronimo.apache.org > Asunto: [jira] Commented: (SM-846) Call to default constructor > ofJBIContainer changes log4j log level > > > [ https://issues.apache.org/activemq/browse/SM- > 846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel#action_38541 ] > > Guillaume Nodet commented on SM-846: > > > Philip, > Is the IdGenerator the only issue ? I still don't understand why / how > servicemix > could change the log4j level ... > What's the way to reproduce the problem ? > > > Call to default constructor of JBIContainer changes log4j log level > > --- > > > > Key: SM-846 > > URL: https://issues.apache.org/activemq/browse/SM-846 > > Project: ServiceMix > > Issue Type: Bug > >Affects Versions: 3.0 > > Environment: Windows XP Professional, java version 1.5.0_09, > JUnit 4.1 > >Reporter: Philipp Rossmanith > >Priority: Minor > > > > A call to the default constructor of > org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level > to ERROR. See http://www.nabble.com/Default-constructor-for-JBIContainer- > changes-log-level--tf3235243s12049.html > > Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, > line 63: > > jbi = new JBIContainer(); > > JBIContainer doesn't seem to use org.apache.log4j, but makes calls to > org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: > > >> > > private static final Log log = LogFactory.getLog(JBIContainer.class); > > << > > ... as well as to java.util.logging.Logger: > > >> > > public Logger getLogger(String suffix, String resourceBundleName) throws > MissingResourceException, JBIException > > << > > commons-logging is configured in ServiceMix. Which in turns, starts > log4j if included in the classpath. > > It seems that org.apache.servicemix.id.IdGenerator calls the > java.util.logging package. This is the only call afaik and it should be > removed. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Maven troubles with ServiceMix 3.0 - Follow-up 2
Hi, Given the troubles I had, I think it would be good to update the "Using an IDE" section of the page http://servicemix.org/site/building.html to refer to http://servicemix.org/site/importing-servicemix-into-eclipse.html. How can one obtain a Confluence login or otherwise contribute to documentation? Ciao, Philipp Rossmanith > -Mensaje original- > De: Rossmanith, Philipp > Enviado el: viernes, 19 de enero de 2007 18:23 > Para: servicemix-dev@geronimo.apache.org > Asunto: RE: Maven troubles with ServiceMix 3.0 - Follow-up > > > Not yet :-) I checked "Building", "Documentation", and the main page of > servicemix.org, but that link slipped me. I'll try it out... > > Thanks - you made my day :-) > > Philipp Rossmanith > > > -Mensaje original- > > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > > Enviado el: viernes, 19 de enero de 2007 16:33 > > Para: servicemix-dev@geronimo.apache.org > > Asunto: Re: Maven troubles with ServiceMix 3.0 - Follow-up > > > > > Have you tried following instructions available at > > http://servicemix.org/site/importing-servicemix-into-eclipse.html ? > > > > > On 1/19/07, Rossmanith, Philipp <[EMAIL PROTECTED]> > wrote: > > > > > > Hi, > > > > > > I managed to resolve the problem > > > > " [INFO] Error building POM (may not be this project's POM). > > > > Project ID: null:xfire-all:jar:1.2.1 > > > > Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for > > > project: > > > > null:xfire-all:jar:1.2.1" > > > > > > ... by proceeding as suggested here: > > > > http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061 > > > 0.mbox/[EMAIL PROTECTED], that is, commenting out > the > > > https-repository in > > > > .m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom. > > > > > > Now, my SM 3.0 Maven build works fine. Still, when opening the > project > > > in Eclipse, there are 3388 errors, obviously resulting from missing > > > dependencies. > > > > > > I installed the Maven Eclipse plugin from > > > http://maven.apache.org/eclipse-plugin.html and added the > Maven-managed > > > dependencies to the build-path. > > > > > > This reduces the number of errors to 1166. Still, it gets stuck with > > > tranql-1.3.pom, an issue that has been described in > > > > http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598 > > > 0.html > > > > > > At the moment, I am adding the missing jars manually. However, > that's a > > > major pain. > > > > > > Hence, any feedback on how to resolve this issue would be highly > > > appreciated. Should this post better be sent to a different mailing > > > list, please let me know about it. > > > > > > Thanks in advance, > > > Ciao, > > > Philipp Rossmanith > > > > > > > -Mensaje original- > > > > De: Rossmanith, Philipp > > > > Enviado el: viernes, 19 de enero de 2007 9:30 > > > > Para: servicemix-dev@geronimo.apache.org > > > > Asunto: Maven troubles with yesterday's SNAPSHOT > > > > > > > > > > > > Hi, > > > > > > > > In the project I'm working, we're planning to subclass the > > > DefaultBroker > > > > in order to enhance its features. Hence, I'll have to do some SM > > > > programming and want to make its code available in Eclipse. > > > > > > > > Knowing from the past that the latest features are usually > available > > > in > > > > the SVN, only, I tried to set up today's snapshot > > > > (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I > had > > > > some difficulties with Maven, though. > > > > > > > > I followed the steps described in > > > > http://servicemix.org/site/building.html from within the top-level > src > > > > directory. I also added M2_REPO to my workspace. MD5 checksums are > ok, > > > > as well. > > > > > > > > At first, the build went fine, but when I opened the project, I > got an > > > > error about my build path and some missing libraries. However, > they > > > were > > > > available in my Maven2 repository. > > > > > > > > Assuming it might be related to the Maven repository,
