Re: customized log4j file
Hi,
by default, SMX use the conf/log4j.xml file.
You can change the appender, log category, log level, etc directly in this file.
If you want to use an alternate log4j file (XML or properties), you can :
1/ add the directory that contains your log4j.xml in the classpath. For
example, the log4j.xml file is in the /var/lib/smx/conf directory. You add this
directory in the SMX classpath using the servicemix.conf file :
[app]
load /var/lib/smx/conf
load ${servicemix.home}/conf
load ${servicemix.home}/lib/*.jar
load ${servicemix.home}/lib/optional/*.jar
As your log4j.xml will be the first in the classpath, it will take in place of
the default one.
2/ another way is to use the LogServiceMBean via a JMX client. The
LogServiceMBean defines a LogConfigUrl attribute where you can define your own
log4j.xml. After invoke the reconfigure() method to take care. The advantage of
this solution is that it can be done on the fly (without restarted SMX) but the
configuration is loose if you restart SMX.
Regards
JB
On Friday 27 February 2009 - 04:21, Chandran R wrote:
>
> Hi All,
>
> I am a new-bie to servicemix.How do we configure servicemix to pick a
> different log4j.xml other than the default.
> I want it to pick for ex "customized-log4j.xml".
> Thanks in advance,
>
> Regards,
> R Chandran
>
> --
> View this message in context:
> http://www.nabble.com/customized-log4j-file-tp22244857p22244857.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
-
HomePage
http://www.nanthrax.net
-
Contacts
jbono...@apache.org
j...@nanthrax.net
-
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
---
PGP : 17D4F086
Re: Procedure explaning How to add bundles for SMX4 ?
+1 I think it's better to manage and host only ServiceMix bundles. Regards JB On Friday 06 March 2009 - 10:40, Guillaume Nodet wrote: > Answering to dev as I think this is an issue we have to discuss here. > > My take on this would be to accept creating bundles for stuff somehow > related to ServiceMix goal. I'm not very at ease hosting all kind of > bundles that are completely unrelated to integration. > That said, we're still bound to the Apache policies and are not able to host > any LGPL or GPL licensed code ... > > > On Fri, Mar 6, 2009 at 10:24, cmoulliard wrote: > > > > > Hi, > > > > The following directory > > https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk contains > > bundles (which are also available from apache maven repo : > > > > http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/bundles/ > > ) > > used by SMX4 and potentially by client project. > > > > This directory contains "osgi-fied" bundles and de facto represents a osgi > > repository for Apache OSGI project. > > > > My question are the following : > > > > - Can we extend the content of this directory for our own project because > > this is similar to what springsource does with the bundles they required > > and > > I'm in favor to have one common repository ? > > - How can we create bundles in this directory (maven, ...) ? > > > > Regards, > > > > > > > > - > > Charles Moulliard > > SOA Architect > > > > My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/ > > -- > > View this message in context: > > http://www.nabble.com/Procedure-explaning-How-to-add-bundles-for-SMX4---tp22368856p22368856.html > > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: [VOTE] Release ServiceMix Kernel 1.1.0
+1 Regards JB On Fri 06/03/09 14:32, "Guillaume Nodet" gno...@gmail.com wrote: > I've uploaded a release of ServiceMix Kernel 1.1.0 at > http://people.apache.org/~gnodet/staging/kernel-1.1.0 [1] > Tag is available at > > https://svn.apache.org/repos/asf/servicemix/smx4/kernel/tags/kernel-1.1.0/ > [2] > The download page is available at > http://cwiki.apache.org/SMX4KNL/servicemix-kernel-110.html [3] > > I've kept trunk with 1.1.0-SNAPSHOT version to not break nightly > builds > until the binaries are published. At that time, we'll be able to > upgrade > trunk to 1.2.0-SNAPSHOT and update nmr/features to 1.1.0 > > The vote is open until wednesday 11/03 > Happy review and vote ! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ [4] > > Open Source SOA > http://fusesource.com [5] > > > > Links: > -- > [1] > http://webmail.nanthrax.net/parse.php?redirect=http%3A%2F%2Fpeople.apache.o > rg%2F%7Egnodet%2Fstaging%2Fkernel-1.1.0[2] > http://webmail.nanthrax.net/parse.php?redirect=https%3A%2F%2Fsvn.apache.org > %2Frepos%2Fasf%2Fservicemix%2Fsmx4%2Fkernel%2Ftags%2Fkernel-1.1.0%2F[3] > http://webmail.nanthrax.net/parse.php?redirect=http%3A%2F%2Fcwiki.apache.or > g%2FSMX4KNL%2Fservicemix-kernel-110.html[4] > http://webmail.nanthrax.net/parse.php?redirect=http%3A%2F%2Fgnodet.blogspot > .com%2F[5] > http://webmail.nanthrax.net/parse.php?redirect=http%3A%2F%2Ffusesource.com > >
JavaBeans and XML advice
Hi guys, I'm currently in Roumania for a project where I use ServiceMix 3.3. For one of my service, I have used servicemix-bean to expose a bean inside = SMX. This bean call another one. In this one, I need to read data from XML file. Currently, I use Commons Digester to load the XML file into a JavaBean but = I would like your advise about=20 which API can I use to load JavaBeans from XML. What do you think about (I = can change the XML format) : - manual loading using Commons Digester (as I make currently) - usage of Apache XmlBeans - usage of JDK XmlBeanReader - usage of jdom The purpose is to easily load JavaBeans (from a Spring factory) from XML co= ntent (from a InputStream). Thanks for your support Regards JB
Re: [VOTE] Release ServiceMix Kernel 1.1.0 (second try), Specs 1.3.0 and jaxp-api-1.4 bundle
+1 JB On Friday 13 March 2009 - 14:16, Guillaume Nodet wrote: > I've uploaded a new release candidate of ServiceMix Kernel 1.1.0 along with > the required changed in the dependencies, i.e. ServiceMix Specs 1.3.0 and > the jaxp-api-1.4 bundle. > The specs contains the SAX parsing problem fix and also fixes in the > activation / javamail jars that prevented the use of javamail in smx4. > The jaxp-api bundle has been enhanced to avoid a warning about unrecognized > encodings (mostly visible when deploying a spring app through the deploy > folder in my case). > > Staging repo: > > http://people.apache.org/~gnodet/staging/kernel-1.1.0<http://people.apache.org/%7Egnodet/staging/kernel-1.1.0> > Tags are available at > https://svn.apache.org/repos/asf/servicemix > /smx4/kernel/tags/kernel-1.1.0/ > https://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/ > > https://svn.apache.org/repos/asf/servicemix/smx4/bundles/tags/org.apache.servicemix.bundles.jaxp-ri-1.4.2_2/ > The download page is available at > http://cwiki.apache.org/SMX4KNL/servicemix-kernel-110.html > > The vote will be closed on Tuesday. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
SMPP component
Hi all, for your information, I have updated the servicemix-shared version for the SMPP component (from 2008.02-SNAPSHOT to 2009.01-SNAPSHOT). Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: [VOTE] Release ServiceMix NMR 1.0.0, ServiceMix Components 2009.01 and ServiceMix 4.0.0
+1 I have deployed all my SAs/SUs (CXF, HTTP, SMPP, Camel, ...) without problem. I have deployed a OSGi bundle and exposed using HTTP using a XML file too. I resume my tests but it looks good for me. Regards JB On Saturday 21 March 2009 - 02:52, Guillaume Nodet wrote: > The staging repo for everything being released is at > http://people.apache.org/~gnodet/staging/nmr-1.0.0/ > Apache ServiceMix 4.0.0 includes all the other artifacts being > released at this time. > > Apache ServiceMix 4.0.0 > - tag is available at > http://svn.apache.org/repos/asf/servicemix/smx4/features/tags/features-4.0.0/ > - the download page is http://cwiki.apache.org/SMX4/servicemix-400.html > > Apache ServiceMix NMR 1.1.0 > - tag is available at > http://svn.apache.org/repos/asf/servicemix/smx4/nmr/tags/nmr-1.0.0/ > - the download page is http://cwiki.apache.org/SMX4NMR/servicemix-nmr-100.html > > JBI components 2009.01 release -- this includes the root POM, the > shared libaries as well as all the components. > - tags are available in their respective projects under > http://svn.apache.org/repos/asf/servicemix/components > > For the Maven plugins, the vote includes: > - Maven plugins POM version 2 > - depends-maven-plugin 1.1 > - features-maven-plugin 1.1 > - jbi-maven-plugin 4.1 > - xfire-maven-plugin 4.1 > Tags for the Maven plugins are available in their respective projects > under http://svn.apache.org/repos/asf/servicemix/maven-plugins/ > > ServiceMix Utils 1.1.0 is being released as well > - tag is available at > http://svn.apache.org/repos/asf/servicemix/utils/tags/servicemix-utils-1.1.0/ > > And finally, 3 OSGi bundles have been updated and 7 new bundles have been > added > - cglib 2.1_3_2 > - commons-dbcp 1.2.2_3 > - geronimo-javamail_1.4_provider 1.8-r755222_1 > - isorelax 20050913_1 > - jettison 1.0.1_1 > - jsmpp 2.0_1 > - quartz 1.6.1_2 > - stringtemplate 3.2_1 > - xmlbeans 2.4.0_1 > - xmlschema 1.4.3_1 > Tags for the bundles are available at > http://svn.apache.org/repos/asf/servicemix/smx4/bundles/tags/ > > Direct links to the Apache ServiceMix 4.0.0 and NMR 1.1.0 distributions: > > http://people.apache.org/~gnodet/staging/nmr-1.0.0/org/apache/servicemix/apache-servicemix/4.0.0/ > > http://people.apache.org/~gnodet/staging/nmr-1.0.0/org/apache/servicemix/nmr/apache-servicemix-nmr/1.0.0/ > > The vote will be closed on Tuesday 24. > > Happy reviewing and voting. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject
I think that moving SMX Kernel as a subproject of Felix is a good idea from the two points of view : - increase the community around Kernel and provide a great OSGi framework by gathering both Felix and Kernel - for the ServiceMix community, we can focus on the first purpose of ServiceMix : provide a great ESB. So we can focus on the ServiceMix NMR, bundles and components. Regards JB On Monday 30 March 2009 - 18:03, Guillaume Nodet wrote: > During ApacheCon last week, there has been some discussions around > moving ServiceMix Kernel as a subproject of Felix. > ServiceMix Kernel is a packaged distribution of Felix designed for > server side applications (see http://servicemix.apache.org/kernel/ for > more informations). > > I think this would be beneficial for this project as it would enable > to build a much bigger community around it, increase the visibility > and the awareness around it. Of course, it would need a new name, but > that's another problem. > Another area that could be included in this move is the ServiceMix > specs (OSGi enhanced versions of Java EE specifications from Geronimo) > and ServiceMix bundles (we've released a bunch of bundles already, see > http://servicemix.apache.org/smx4/bundles-repository.html). > > I'd like to have feedback from both communities (and any other > interested parties) to gauge the interest in such a move. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > ---- > Open Source SOA > http://fusesource.com -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: Deploying SNAPSHOTs from Hudson
+1 Gert Vanthienen wrote: L.S., Right now, we have two build servers: - Camel builds for deploying nightly snapshots are running on http://projects.open.iona.com/builds/status - Camel builds are running fine on hudson.zones.apache.org for a few weeks now Apache also has a Nexus repository manager installed at http://repository.apache.org now. I'd like to start deploying our SNAPSHOTs to this repository from Hudson directly instead of using the separate build server. In the future, we should also be able to leverage Nexus for the release process as well, i.e. deploy the artifacts under vote to a Nexus staging repo and then just promote the artifacts into the release repo after the vote. The major downside would be that the repository url for snapshots would change from http://people.apache.org/repo/m2-snapshot-repository/ to https://repository.apache.org/content/repositories/snapshots, but I think Chris already did that bit when CXF started using Nexus. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Google Summer of Code 2009
Hi Gert, Thanks for the proposal. I'm interested around the smx web console. If you need help/support on it, keep me posted. Regards JB Gert Vanthienen wrote: L.S., I added two proposals for participating to Google Summer Of Code 2009 to http://cwiki.apache.org/confluence/display/SM/Google+Summer+Of+Code+2009. If this looks OK to people, I'll move them out to the main Apache GSoC page today -- student application period ends this week. Any other suggestions or volunteers for mentoring welcome, by the way... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Google Summer of Code 2009
Maybe we can think about a kind of documentation reference stored in the svn repo (in the DocBook format for example). We can add the documentation generation in the continuous integration process to generate HTML/PDF. Providing a more "professional" PDF user guide can be a skill. Would you like that I raise a Jira task around this and begin the documentation project structure ? Regards JB Gert Vanthienen wrote: Khaled, I'm not sure projects about documentation would really get a lot of attention, but you're absolutely right about the problems with our documentation. Actually, I think the problem is twofold: - some areas are probably really underdocumented and you can hardly find anything about it on the website - most things do have some kind of documentation, but the organisation of the documentation is really bad Especially for ServiceMix 4, the documentation seems to be all scattered around: you'll find bits in the ServiceMix Kernel wiki, the NMR wiki and for the components and the Maven tools you'll have to go into the main ServiceMix (3) wiki/website. With all that being said, we're particularly open to any kind of suggestion on how to improve things (or even a helping hand ;) ). Could you give us an overview of the information you were looking for so we can figure out a way to get that together to start with or something? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Khaled Essghaier : Hi, looks very interesting, i am a student actually and working actually in a SOA project in which we are planning to use an ESB but i think that you should consider projects related with the documentation and samples because i got a hard time those couple of weeks trying to get something working with SM4 which lead me to consider using open-ESB. Regards, *Khaled* My blog = http://thepurplecows.blogspot.com/
Re: [DISCUSS] Move the Camel features into Camel
+1 Regards JB Gert Vanthienen wrote: L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: [DISCUSS] Move the Camel features into Camel
Hi Willem, from my point of view, the Camel bundles should be atomic and standalone, so they need to provide this party bundles. Regards JB Willem Jiang wrote: Just a quick question about it. Since camel components have lots of third party dependencies, if we move the Camel features from SMX to Camel, do we need to provide the third party bundles in Camel or just use the bundles in Servicemix's repository? +1 for moving the Camel features into Camel. Willem. Hadrian Zbarcea wrote: +1 On Apr 1, 2009, at 1:50 PM, Gert Vanthienen wrote: L.S., Currently, a features descriptor for Camel is being generated in the ServiceMix 4 features projects. This descriptor basically is an XML file that allows you to install any Camel component on ServiceMix Kernel in a single command. The information in the descriptor will be used to determine which others OSGi bundles are required. We now released ServiceMix 4.0.0 with a features descriptor for Camel 1.6.0, but on the Camel project itself we're now working on 2.0.0-SNAPSHOT and 1.6.1-SNAPSHOT. I would like to propose to move the generation process of the features descriptor into the Camel project itself, so every release of Camel can come with its own features descriptor. It will also make it easier for people to test a SNAPSHOT for Camel inside ServiceMix Kernel without having to hack up their own descriptor first. If we look at the codebase, it will basically mean that we would have to move the pom.xml and properties file that's currently at https://svn.eu.apache.org/repos/asf/servicemix/smx4/features/trunk/camel/camel-features/ to e.g. a /platform/servicemix-kernel directory in the Camel project. Any thoughs? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Proposition for new features about SMX4 Kernel
Hi Charles, could you give some details around several points : - Add EJB3 support, What do you mean by EJB3 support ? If you talk about using EJB3 inside SMX, you can already do it (you can setup a EJB client). If you talk about deploying EJB3 inside SMX, I'm not sure that it's a good idea as there are good EJB container/application servers that doing that. - Provide web admin interface, I'm agree, I will try to begin a proto soon. - Rotation of the file logs (defined through etc config file or web administration console) I think that it's already possible by changing the org.ops4j.pax.logging.cfg. You can define a RollingFileAppender for example. Thanks, Regards JB
Re: Proposition for new features about SMX4 Kernel
I kinda disagree. I think supporting the EJB3 programming model (by leveraging an existing EJB container such as OpenEJB) and allow easy deployment inside ServiceMix, along with exposing those EJB3 directly as NMR/JBI endpoints would be really nice. Kinda like what servicemix-cxf-se provides, but with full support for EJB3. We could also directly allow EJB3 to be exposed as web services, as we already integrate CXF ... If we talk about integrate an existing EJB container into SMX, I'm totally agree. Exposing directly EJB3 as endpoints it's a overkill feature. My comment was more to avoid to reinvent the wheel by implementing a kind of minimal EJB container inside SMX, it's better to use an existing implementation. - Provide web admin interface, I'm agree, I will try to begin a proto soon. There is a GsoC project for that, see http://cwiki.apache.org/confluence/display/SM/Google+Summer+Of+Code+2009 I'd like not to step on our students work if possible ;-) As I said, I think reusing the felix web console would allow us to not rewrite the full thing. I would have loved a gwt based console, but not sure it's worth spending time to rewrite it from scratch ... No problem, sounds good for me. Regards JB
Re: Google Summer of Code 2009
Hi Khaled, what is very surprising is the fact that no one have the right answer at least for the first use case I think that we already have some material around this. Indeed, I have ServiceMix deployed in production that use EJB via CXF-SE. I'm very sorry, I haven't had any time for now to upgrade the SMX4 EJB documentation. I try to do it as soon as possible. We have discussed this morning (in the dev mailing list) with Guillaume to add an EJB3 container embedded in SMX4. I think it's a killer feature, so we need to going deeper in this way. Back to the documentation part i think that the first things to do is to restructure the documentation and to complete the missing parts (especially the blank pages in SM website) as Gert said. the PDF thing is just how to deliver this documentation which very useful for off line usage and can be shipped with SM releases.BTW i think that confluence can generate PDF files thanks to plugins: http://confluence.atlassian.com/display/DOC/Confluence+to+PDF Some folks talked about making an open source book for SM in the users mailing list see : http://cwiki.apache.org/SM/discussion-forums.html#nabble-td22374793|a22374793 i think that is a great idea too. I'm agree. I have proposed to create a documentation project, build in the continuous integration process. This documentation project will publish DocBook in several output formats (such as PDF/HTML). I have a positive feedback from Lars, I'm waiting for feedback from other team members. Regards JB Regards Khaled My blog = http://thepurplecows.blogspot.com/ On Wed, Apr 1, 2009 at 8:44 AM, Gert Vanthienen wrote: Khaled, I'm not sure projects about documentation would really get a lot of attention, but you're absolutely right about the problems with our documentation. Actually, I think the problem is twofold: - some areas are probably really underdocumented and you can hardly find anything about it on the website - most things do have some kind of documentation, but the organisation of the documentation is really bad Especially for ServiceMix 4, the documentation seems to be all scattered around: you'll find bits in the ServiceMix Kernel wiki, the NMR wiki and for the components and the Maven tools you'll have to go into the main ServiceMix (3) wiki/website. With all that being said, we're particularly open to any kind of suggestion on how to improve things (or even a helping hand ;) ). Could you give us an overview of the information you were looking for so we can figure out a way to get that together to start with or something? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Khaled Essghaier : Hi, looks very interesting, i am a student actually and working actually in a SOA project in which we are planning to use an ESB but i think that you should consider projects related with the documentation and samples because i got a hard time those couple of weeks trying to get something working with SM4 which lead me to consider using open-ESB. Regards, *Khaled* My blog = http://thepurplecows.blogspot.com/
[PROPOSAL] Create documentation project
Hi (again :)), As already discussed on the user mailing list, I propose to create a documentation project. This project is a maven one : - inherit the SMX super POM - define pom.xml - etc It stores DocBook resources. The purpose is to generate (within each SMX continuous integration build) an up to date documentation into several formats : PDF, HTML, etc. It can use Maven Doxia or Google Docbk plugin to generate it into a build phase (package for example). What do you think ? Regards JB
[DISCUSS] Normalized components message format
Hi guys, Some weeks ago (maybe monthes :)), I have sent an e-mail on the dev mailing list to define a kind of standard message format for binding components. To remember, currently, each component defines its own format to marshal/unmarshal JBI normalized messages. This is the purpose on the component marshaler. For example, in the SMPP component, we have the DefaultMarshaler that read/write XML like : [...] The user can override this marshaler by a new one. The problem is when we "facade" this component with another one. The content of the incoming normalized message should be in the format expected by the component. If it's not the case, the user : - need to transform the normalized message content to match the required format - need to create a marshaler to change the expected format. Currently, the format expected by each component is not "standard" and not very well documented. That's why I propose to define a kind of "contract" inside all SMX components. At least, this contract can be a XSD defining a standard XML structure shared by all components. Or, we can use WSDL to define this contract. For example, it can be something like : http://servicemix.apache.org/component.wsdl"; xmlns="http://schemas.xmlsoap.org/wsdl/";> http://servicemix.apache.org/component.xsd"; xmlns="http://www.w3.org/2000/10/XMLSchema";> transport="http://schemas.xmlsoap.org/soap/http"/> soapAction="http://servicemix.apache.org/process"/> Component Exchange Service http://servicemix.apache.org/process"/> It's only a example. In fact the WSDL could contain NormalizedMessage complex type, map describing properties to process, etc. What do you think of that ? Maybe a Binding Component Exchange XSD is enough ? Thanks Regards JB
Re: [PROPOSAL] Create documentation project
Hi Charles, Yes, it's exactly the same as in Camel. In Camel, the user manual is store in the project itself (in the tooling/camel-manual subproject), in the DocBook format, and it uses DocBk to generate output (PDF/HTML). I propose to do exactly the same in SMX. The main purpose is : - to have a documentation already up to date at the build time - store the documentation in a central project - be able to generate more "professional" look and format Regards JB Charles Moulliard wrote: Jean-Baptiste, If the strategy proposed is the same as used to generate Apache Camel documentation, I agree. Otherwise, it makes no sense to reinvent the wheel. Regards, Charles On Thu, Apr 2, 2009 at 2:56 PM, Jean-Baptiste Onofré wrote: Hi (again :)), As already discussed on the user mailing list, I propose to create a documentation project. This project is a maven one : - inherit the SMX super POM - define pom.xml - etc It stores DocBook resources. The purpose is to generate (within each SMX continuous integration build) an up to date documentation into several formats : PDF, HTML, etc. It can use Maven Doxia or Google Docbk plugin to generate it into a build phase (package for example). What do you think ? Regards JB
Re: [PROPOSAL] Create documentation project
It seems that you use DocBk plugin for the manual in the tooling/camel-manuel project, isn't it ? Regards JB James Strachan wrote: Actually we use the wiki in Camel to store the documentation and use pricexml to turn it into a PDF. 2009/4/2 Jean-Baptiste Onofré : Hi Charles, Yes, it's exactly the same as in Camel. In Camel, the user manual is store in the project itself (in the tooling/camel-manual subproject), in the DocBook format, and it uses DocBk to generate output (PDF/HTML). I propose to do exactly the same in SMX. The main purpose is : - to have a documentation already up to date at the build time - store the documentation in a central project - be able to generate more "professional" look and format Regards JB Charles Moulliard wrote: Jean-Baptiste, If the strategy proposed is the same as used to generate Apache Camel documentation, I agree. Otherwise, it makes no sense to reinvent the wheel. Regards, Charles On Thu, Apr 2, 2009 at 2:56 PM, Jean-Baptiste Onofré wrote: Hi (again :)), As already discussed on the user mailing list, I propose to create a documentation project. This project is a maven one : - inherit the SMX super POM - define pom.xml - etc It stores DocBook resources. The purpose is to generate (within each SMX continuous integration build) an up to date documentation into several formats : PDF, HTML, etc. It can use Maven Doxia or Google Docbk plugin to generate it into a build phase (package for example). What do you think ? Regards JB
Re: [PROPOSAL] Create documentation project
Sounds good for me. We can gather wiki pages and add some extra content/presentation using DocBook. Regards JB James Strachan wrote: 2009/4/2 Jean-Baptiste Onofré : It seems that you use DocBk plugin for the manual in the tooling/camel-manuel project, isn't it ? No - we used to a long time ago. See the maven-html-to-pdf plugin we're using in the pom.xml - that shows how we suck out the HTML from the wiki and turn it into a PDF https://svn.apache.org/repos/asf/camel/trunk/tooling/camel-manual/pom.xml
Re: [PROPOSAL] Create documentation project
Understood. I have habit with DocBook and automatically publish the documentation with the project build. I'm going to take a look on princexml and wiki gathering. Thanks, Regards JB James Strachan wrote: 2009/4/2 Jean-Baptiste Onofré : Sounds good for me. We can gather wiki pages and add some extra content/presentation using DocBook. So long as somehow you make a big HTML file that we can feed into princexml, I guess it doesn't matter too much where the HTML comes from. We just found it simplest to just reuse the wiki - as thats where most of the docs were etc
Re: [VOTE] Move ServiceMix Kernel as Karaf subproject in Felix
+1 Guillaume Nodet wrote: This is a formal vote to move ServiceMix Kernel codebase into Felix as Karaf subproject. [ ] +1 : move ServiceMix Kernel as Karaf subproject in Felix [ ] -1 This vote will be closed on Friday morning. Here's my +1 -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: "Web-based management console for ServiceMix" proposal for Google Summer of Code 2009
Hi Marcin, thanks for this introduction. Have you already some idea around the web ui framework (ICEFaces, GWT, etc) ? Regards JB Marcin Wilkos wrote: Hi, My name is Marcin Wilkos. Currently I'm studying a Masters in Computer Science at Cybernetics Faculty Military University of Technology in Warsaw, Poland. I'mnow on 4th year and graduate in 2010. At the University I'mparticipating in research projects about ontologies, GIS, complex networks and simulation. I have 2 years of commercial expirence in Java development. I'm acquainted with Servlets, JSP, JSF, Struts, RMI, JPA, Toplink, Web Services, NetBeans, Eclipse, SVN, etc. Here is link to my proposal: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/mwilkos/t123878519976 The main task for this project is to build a web-based management console to administer the platform. It should allow for easy extension by features being installed on top of Kernel, e.g. ServiceMix 4 installs an NMR and JBI layer on top of Kernel, both of which should be administrable seamlessly through the web UI. ServiceMix is my first contact with OSGi, but I'm studying it intensively now. On this dev-list I read that Apache Felix console can be used here. Could you give me some advice about that? Marcin Wilkos
Re: SMX4 features.xml contains incomplete set of examples
Hi Eoghan, Thanks for the information. I think that it's a forget in the exemples. Could you please a Jira around this (we will close the task if it's a deliberate omission) ? Regards JB Eoghan Glynn wrote: Hi Folks, Quick newbie question for ye ... I've been playing around with some new demos and I've noticed the "master" features.xml[1] doesn't contain definitions for all the examples provided under smx4/features/trunk/examples. So if a user wanted for example to deploy the cxf-ws-addressing demo, they wouldn't have the convenience of just doing a simple "features install examples-cxf-ws-addressing" as they would with the basic examples-cxf-osgi demo. I wonder is this omission deliberate, maybe because some of the examples are incomplete or not that interesting, or does it sound like an over-sight? Cheers, Eoghan [1] http://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/assembly/src/main/filtered-resources/features.xml -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
[DISCUSS] Apache Mashup
Hi all, I'm working on Apache ServiceMix and I think that an enterprise mashup tool can be a great complement to the ESB. Apache Mashup can be a tool that combines : - presentation mashup: provides mashup widgets in a widget container. It can implement the eWidget IBM norm (there is not JCP norm for now around this) and generates portlet from these widgets. The widget container is a Web2.0/AJAX application hosting MAR (Marshup ARchive). - data mashup: extract data from resources (from a "standard" HTML website from exemple) and exposes it as a service in ServiceMix (that can be exposed in WebService, etc). From a ServiceMix point of view, it's a ServiceEngine. - process mashup: combines ServiceMix and ODE to create a new data mashup from existing one. What do you think on that ? I would like to have your feedback (from a general point of view and from ServiceMix team point of view) before submitting a formal proposal. Regards JB
Re: Upgrade to CXF 2.2
+1 On another topic, for your information, I'm going to increase component versions in the SMX3 trunk. Regards JB Edell Nolan wrote: Hi, I think we should upgrade Servicemix trunk for features, components etc to CXF 2.2 Does anyone have any objections ? Edell.
Re: SMX4 features.xml contains incomplete set of examples
Thanks Eoghan, I will take a look this evening. Regards JB Eoghan Glynn wrote: Hi Folks, I just submitted a patch on https://issues.apache.org/activemq/browse/SMX4-271 Can some committer please review and apply it (if its considered kosher). Cheers, Eoghan
Re: [DISCUSS] Setting up Cobertura/CheckStyle/... CI builds
Hi Gert, From my point of view, either if SMX will be add on NemoSonar, I think it can be interesting to add a CI profile in the POMs. It allows people to check if the code style is correct, if there is not cyclic dependencies, etc on the local copy (by activating the profile). To summarize : +1 for a CI profile and add it in Hudson Regards JB Gert Vanthienen wrote: L.S., For a long time, we've had CheckStyle/PMD enabled on ServiceMix 3 and the components. The problem with this was that it was interfering with day-to-day development work: builds taking longer, IDEs need to be configured properly to apply the code conventions correctly, ... I'd like to propose to setup CI builds that do Cobertura/CheckStyle/PMD/... checks so we at least have some metrics on code quality. I know metrics are not absolute, but they can at least help us identify which areas of the code need some work. One option would be to ask the Sonar guys if they could add us to their public instance (http://nemo.sonar.codehaus.org/), the other solution would be to add it to a CI profile in our own POMs that we can run on Hudson. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
ServiceMix Exec snapshot
Hi all, A first usable version of ServiceMix Exec is available in the trunk. I have written a first wiki page: http://cwiki.apache.org/confluence/display/SM/servicemix-exec Any suggestion is welcome. Regards JB
Re: ServiceMix Exec snapshot
Thanks for your feedback Guillaume.
I close the Exec JIRA tasks and open two others for CDATA in output and
error stream.
Thanks again :)
Regards
JB
Guillaume Nodet wrote:
Great work !
Just two comments:
* the use of new StringSource("" + output + "")
won't work if any reserved character (such as '<' happens to be in the
output
* might be a good idea to send the error stream too in an tag
On Thu, Apr 23, 2009 at 09:17, Jean-Baptiste Onofré wrote:
Hi all,
A first usable version of ServiceMix Exec is available in the trunk.
I have written a first wiki page:
http://cwiki.apache.org/confluence/display/SM/servicemix-exec
Any suggestion is welcome.
Regards
JB
Re: [DISCUSS] Setting up Cobertura/CheckStyle/... CI builds
Hi Gert, thanks for the links, it's interesting. The reports provide some way to improve code (adding some unit tests, etc). Regards JB Gert Vanthienen wrote: L.S., The Sonar guys have been so kind to set up reports: - for ServiceMix Components on http://nemo.sonar.codehaus.org/project/index/org.apache.servicemix:all-components - for ServiceMix 4 on http://nemo.sonar.codehaus.org/project/index/org.apache.servicemix:all Haven't really looked at the reports in detail, but at first glance it looks like we could do with a few extra unit tests here and there. For the other reports, not everything is relevant but some of the things (like e.g. unused imports) should be very easy to fix I guess. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/18 Chris Custine : Sounds great to me Gert. I really like the idea of sending a summary email to dev@ list maybe on a weekly basis in addition to the web summary. As long as I don't have to convert someones tabs to spaces, or properly indent someone else's code to get my code to build, I will be happy :-D -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, Apr 16, 2009 at 9:36 AM, Gert Vanthienen wrote: Chris, To avoid breaking each other's build, I'd make it available in on a public server somewhere (hudson or sonar) for people to consult it. We can always send an occasional mail to the dev@ list if our metrics are bad to get people's attention. Personally, I'd avoid adding it again in the default build. Adding it to Sonar would be the easy way to go, because it takes no work whatsoever on our side. Adding it in a build profile is a bit more work, but it would allow people to run things themselves it they really want to. For me, I'd just say we go for Sonar first and add more custom metrics to Hudson if we want those or if we want to be able to run them ourselves. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/16 Chris Custine : +1 The problem before was that this was all enabled by default so it ran on every local build. So then if someone committed code and disabled checkstyle but had syntax or style errors, then everyone else had failures and would have to fix the code themselves usually. Are you proposing that we disable some of the strict style checks, or are you saying that we just have them available on the CI builds for reference and periodic fixing? Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, Apr 16, 2009 at 2:31 AM, Gert Vanthienen wrote: L.S., For a long time, we've had CheckStyle/PMD enabled on ServiceMix 3 and the components. The problem with this was that it was interfering with day-to-day development work: builds taking longer, IDEs need to be configured properly to apply the code conventions correctly, ... I'd like to propose to setup CI builds that do Cobertura/CheckStyle/PMD/... checks so we at least have some metrics on code quality. I know metrics are not absolute, but they can at least help us identify which areas of the code need some work. One option would be to ask the Sonar guys if they could add us to their public instance (http://nemo.sonar.codehaus.org/), the other solution would be to add it to a CI profile in our own POMs that we can run on Hudson. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: Broken dependency to build SMX3 trunk
Currently, SMX3 pom uses servicemix-pom version 2. In this version of the parent POM, the repository repository.apache.org is not present. Maybe I can increase to the new servicemix parent POM that includes the Nexus repository. Regards JB Gert Vanthienen wrote: L.S., CXF is using Nexus (repository.apache.org) to deploy snapshots, just like ServiceMix itself. Perhaps we still need to add the new snapshot repo location somewhere, but ideally we would want to upgrade to version 5 of the Apache parent POM which has all the new Nexus repo information for us. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/24 Edell Nolan : Hi, I have found a snapshot here http://repository.apache.org/snapshots/org/apache/cxf/cxf-codegen-plugin/2.2.1-SNAPSHOT/ Maybe we are expecting to pick it up from somewhere else ? Edell. On Fri, Apr 24, 2009 at 10:12 AM, Jean-Baptiste Onofré wrote: Hi all, I have tried to build the SMX3 trunk and I have a broken dependency on sample WSDL First :: CXFSE SU : Reason: Unable to download the artifact from any repository org.apache.cxf:cxf-codegen-plugin:pom:2.2.1-SNAPSHOT I have checked in the different repository defined in the super POM and I haven't found any version of the codegen plugin for CXF 2.2.1-SNAPSHOT. In the WSDL first example, codegen is used with the wsdl2java goal. Possible workarounds are : - request a codegen plugin 2.2.1-SNAPSHOT version (if the plugin is not deprecated). - use the cxf-java2ws-plugin in place of codegen. - rollback to CXF 2.2 which provides the codegen plugin. What do you think ? Regards JB
Re: Broken dependency to build SMX3 trunk
Thanks Gert, I release a servicemix-pom 3 with apache parent POM 5. I upgrade the servicemix-pom trunk to 4-SNAPSHOT version. Are you OK with that ? Thanks JB Gert Vanthienen wrote: JB, Yes, I think it makes sense to upgrade our servicemix-pom (and everything else) to use apache pom version 5. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/24 Jean-Baptiste Onofré : Currently, SMX3 pom uses servicemix-pom version 2. In this version of the parent POM, the repository repository.apache.org is not present. Maybe I can increase to the new servicemix parent POM that includes the Nexus repository. Regards JB Gert Vanthienen wrote: L.S., CXF is using Nexus (repository.apache.org) to deploy snapshots, just like ServiceMix itself. Perhaps we still need to add the new snapshot repo location somewhere, but ideally we would want to upgrade to version 5 of the Apache parent POM which has all the new Nexus repo information for us. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/4/24 Edell Nolan : Hi, I have found a snapshot here http://repository.apache.org/snapshots/org/apache/cxf/cxf-codegen-plugin/2.2.1-SNAPSHOT/ Maybe we are expecting to pick it up from somewhere else ? Edell. On Fri, Apr 24, 2009 at 10:12 AM, Jean-Baptiste Onofré wrote: Hi all, I have tried to build the SMX3 trunk and I have a broken dependency on sample WSDL First :: CXFSE SU : Reason: Unable to download the artifact from any repository org.apache.cxf:cxf-codegen-plugin:pom:2.2.1-SNAPSHOT I have checked in the different repository defined in the super POM and I haven't found any version of the codegen plugin for CXF 2.2.1-SNAPSHOT. In the WSDL first example, codegen is used with the wsdl2java goal. Possible workarounds are : - request a codegen plugin 2.2.1-SNAPSHOT version (if the plugin is not deprecated). - use the cxf-java2ws-plugin in place of codegen. - rollback to CXF 2.2 which provides the codegen plugin. What do you think ? Regards JB
Broken dependency to build SMX3 trunk
Hi all, I have tried to build the SMX3 trunk and I have a broken dependency on sample WSDL First :: CXFSE SU : Reason: Unable to download the artifact from any repository org.apache.cxf:cxf-codegen-plugin:pom:2.2.1-SNAPSHOT I have checked in the different repository defined in the super POM and I haven't found any version of the codegen plugin for CXF 2.2.1-SNAPSHOT. In the WSDL first example, codegen is used with the wsdl2java goal. Possible workarounds are : - request a codegen plugin 2.2.1-SNAPSHOT version (if the plugin is not deprecated). - use the cxf-java2ws-plugin in place of codegen. - rollback to CXF 2.2 which provides the codegen plugin. What do you think ? Regards JB
[SMX3] POM and repositories cleanup
Hi all, I have updated servicemix-pom to include repositories and plugin repositories common to all ServiceMix projet. Now, the servicemix-pom doesn't override any definition coming from the apache super POM (especially the apache.snapshots repositories which now uses Nexus repository). I have changed the SMX3 trunk POM to take care of this change and make a test starting from an empty local repository (I have made rm -r ~/.m2/repository and a global build using mvn install). All artifacts are resolved and the build is correct. Regards JB
[PROPOSAL] SMX3 new release
Hi all, As we have released SMX4 including new components version (2009.01), I propose to prepare a new 3.3.1 release that include the same components set. I have quickly checked the JIRA tasks related to SMX3. I haven't seen any blocking tasks. Nevertheless, if you want to include some JIRA tasks in the 3.3.1 before releasing, keep me posted, I can work on it. I would like to begin the release preparation tomorrow if all are OK. Thanks Regards JB
Re: [PROPOSAL] SMX3 new release
Lars, is up to you. There is no emergency to release 3.3.1 version, so we can wait for your commit. Regards JB Lars Heinemann wrote: Hi JB, I am currently reworking servicemix-mail. (see SMXCOMP-499) No idea if you want to wait for the changes to finish. Regards Lars 2009/4/28 Jean-Baptiste Onofré : Hi all, As we have released SMX4 including new components version (2009.01), I propose to prepare a new 3.3.1 release that include the same components set. I have quickly checked the JIRA tasks related to SMX3. I haven't seen any blocking tasks. Nevertheless, if you want to include some JIRA tasks in the 3.3.1 before releasing, keep me posted, I can work on it. I would like to begin the release preparation tomorrow if all are OK. Thanks Regards JB
Re: [PROPOSAL] SMX3 new release
Well, it makes sense. So, if we can prepare a SMX3 release including the same component set as in the SMX4 release. Do you see anything else in the SMX3 core that we need to correct before releasing ? Thanks Regards JB Guillaume Nodet wrote: Well, I would not. I think it makes sense to release 3.3.1 with the same set of components as in 4.0.0. Once the fixes in smx-mail got in, we can release this component independantly. On Tue, Apr 28, 2009 at 09:04, Jean-Baptiste Onofré wrote: Lars, is up to you. There is no emergency to release 3.3.1 version, so we can wait for your commit. Regards JB Lars Heinemann wrote: Hi JB, I am currently reworking servicemix-mail. (see SMXCOMP-499) No idea if you want to wait for the changes to finish. Regards Lars 2009/4/28 Jean-Baptiste Onofré : Hi all, As we have released SMX4 including new components version (2009.01), I propose to prepare a new 3.3.1 release that include the same components set. I have quickly checked the JIRA tasks related to SMX3. I haven't seen any blocking tasks. Nevertheless, if you want to include some JIRA tasks in the 3.3.1 before releasing, keep me posted, I can work on it. I would like to begin the release preparation tomorrow if all are OK. Thanks Regards JB
Re: Releasing a few more bundles
+1 Regards JB Gert Vanthienen wrote: L.S., Over the last few weeks, I added a few more bundles that were required for Camel components. If nobody objects, I'd like to release those this evening because they are needed for the next Camel releases (1.6.1 and 2.0-M2 coming up soon). Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
Re: [VOTE] 11 new bundles
+1 Gert Vanthienen wrote: I've uploaded a new set of OSGi bundles at: http://people.apache.org/~gertv/staging/bundles This includes the following new bundles: - cometd-bayeux-6.1.11 - hapi-0.5.1 - freemarker-2.3.15 - mvel2-2.0.8 - opensaml-1.1 - tagsoup-1.2 - velocity-1.6.2 - xalan-2.7.1 - xalan-serializer-2.7.1 - xercesImpl-2.9.1 - xmlsec-1.4.2 The various tags are available at: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/tags/ Please review and vote: [ ] +1 Release those bundles [ ] -1 Do not Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: Test coverage improvement
Thanks Chris, I have begun to take a look on the Jira tasks that you have created. Maybe we can define test coverage by code area: 1/ all core functions should be linked to a unit test 2/ for components/bundles, at least the marshaler feature and deployment (Spring xbean in the case of JBI packaging) should be tested 3/ for binding components that use legacy system should provide mock to test end to end. Regards JB Chris Custine wrote: Hi All, We have had some discussions recently about improving some of the test coverage. I have created some Jira issues for some of the more widely used components so that anyone can take them if desired. Each issue has a link to the sonar report page with test coverage and other metrics. One thing we have not discussed is what level of test coverage we are seeking, so this thread would be a good place to discuss that. Clearly we are lacking good test coverage, but what level should we agree on as our goal? Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: Releases with Nexus?
+1 For sure, centralizing all artifacts on nexus will be great. Regards JB Gert Vanthienen wrote: L.S., Before we start releasing ServiceMix 3.3.1 with the 2009.01 components, we also need to release the ServiceMix parent POM. I think this is a good occasion to start using Nexus for releases. This will allow us to do the staging of artifacts for a vote and promoting them into central repo afterwards as explained in http://maven.apache.org/developers/release/releasing.html. If we decide to go down this route, I'll ask infra to set this up at the Nexus end and will do the necessary changes to the parent POM before releasing that. Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: Message Exchange between two POJO's
Hi Sanky,
If you need to create the POJO, you can use the servicemix-bean
component. If you have existing POJO, you can expose it using the
servicemix-cxf-se component.
For example, you can create a service that use a POJO method like this :
import org.apache.servicemix.jbi.listener.MessageExchangeListener;
import org.apache.servicemix.jbi.util.MessageUtil;
import org.apache.servicemix.jbi.jaxp.SourceTransformer;
import javax.annotation.Resource;
import javax.jbi.messaging.DeliveryChannel;
import javax.jbi.messaging.ExchangeStatus;
import javax.jbi.messaging.MessageExchange;
import javax.jbi.messaging.MessagingException;
import javax.jbi.messaging.NormalizedMessage;
import javax.xml.transform.Source;
public class ListenerBean implements MessageExchangeListener {
@Resource
private DeliveryChannel channel;
public void onMessageExchange(MessageExchange exchange) throws
MessagingException {
if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
NormalizedMessage message =
exchange.getMessage("in");
Source content = message.getContent();
//process content according to your logic
//e.g. to access the message body as a String use
String body = (new
SourceTransformer()).toString(content);
body = MyPOJO.transform(body);
message.setContent(new StringSource(body));
exchange.setMessage(message, "out");
channel.send(exchange);
}
}
}
This POJO is the listener one: it receives a message, extracts the
content and send out (if the MEP InOut is used).
You can deploy it with the following xbean.xml:
For the poller, you can use servicemix-quartz component to call a bean
that trigger the message sending. You can define your own
servicemix-quartz marshaler to define the message content. After you
deploy it using a xbean.xml like this:
targetService="MyService" endpoint="listener">
Regards
JB
sanky wrote:
Hi,All...
I want to exchange message from one POJO(sender) to another(receiver).
I am looking for-
1. how to configure POJO's for this, may be in the form of xbean.xml..
Any example on this will be useful..
I have also gone through the link--
http://servicemix.apache.org/pojo-support.html
But dont understand everything. Please help..
2. Also help me to understand how sender will be triggered to send message
once sender and receiver service assemblies (SA) are deployed
Thanks,
Sanket
Re: Message Exchange between two POJO's
This question is more user related. I forward it into the user mailing list. Thanks JB sanky wrote: Hi,All... I want to exchange message from one POJO(sender) to another(receiver). I am looking for- 1. how to configure POJO's for this, may be in the form of xbean.xml.. Any example on this will be useful.. I have also gone through the link-- http://servicemix.apache.org/pojo-support.html But dont understand everything. Please help.. 2. Also help me to understand how sender will be triggered to send message once sender and receiver service assemblies (SA) are deployed Thanks, Sanket
Re: News regarding new jbi components?
Hi Matteo, We have already released servicemix-exec component. A first snapshot of servicemix-ldap component is available but not yet released (I need to work on it). For the other components, I have to take care of some JIRA and resume implementing it. The first one on the list will be servicemix-jdbc. If you want, you can rate components to define which ones to be implemented first. Regards JB Matteo Redaelli wrote: Ciao Are there any news regarding the roadmap of new JBI components (talend, jdbc, .. in http://servicemix.apache.org/components-list.html)? I see a lot of activities in the forums regarding camel components, I hope SMX will not be limited to be a container for camel routes... Thanks in advance Matteo
Re: Fwd: ASF Board Report - Initial Reminder for Jun 2009
Guys, How I can help on this topic ? What's exactly the report content and what's the actions plan ? Regards JB Guillaume Nodet wrote: Time for another Board report -- Forwarded message -- From: ASF Board Date: 1 Jun 2009 00:50:03 - Subject: ASF Board Report - Initial Reminder for Jun 2009 To: Guillaume Nodet This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 24 June 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - ServiceMix
Re: Apache ServiceMix Features :: ActiveMQ Commands (4.0.0) / Apache Karaf
Hi Charles, it makes sense to migrate ghsell to karaf too. Guillaume, what do you think ? Regards JB Charles Moulliard wrote: Hi, The following Servicemix features cannot be used with Apache Karaf because it requires package : org.apache.servicemix.kernel.gshell instead of org.apache.karaf.kernel.gshell Can we migrate it or duplicate it to have ActiveMq commands on Apache Karaf ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com
Re: Apache ServiceMix Features :: ActiveMQ Commands (4.0.0) / Apache Karaf
Yes Charles (I wasn't very clear). What's the features that references the "old" bundle ? Regards JB Charles Moulliard wrote: Hi Jean-Baptiste, GShell has already been migrated : [ 8] [Active ] [Started] [ 40] Apache Felix Karaf :: GShell Run (1.2.0.SNAPSHOT) [ 14] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Core (1.2.0.SNAPSHOT) [ 16] [Active ] [Started] [ 30] Apache Felix Karaf :: GShell OSGi Commands (1.2.0.SNAPSHOT) [ 26] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell ConfigAdmin Commands (1.2.0.SNAPSHOT) [ 27] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Log Commands (1.2.0.SNAPSHOT) [ 32] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Admin (1.2.0.SNAPSHOT) [ 41] [Active ] [Started] [ 30] Apache Felix Karaf :: GShell Features (1.2.0.SNAPSHOT) [ 42] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell PackageAdmin Commands (1.2.0.SNAPSHOT) Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Fri, Jun 5, 2009 at 11:12 AM, Jean-Baptiste Onofré wrote: Hi Charles, it makes sense to migrate ghsell to karaf too. Guillaume, what do you think ? Regards JB Charles Moulliard wrote: Hi, The following Servicemix features cannot be used with Apache Karaf because it requires package : org.apache.servicemix.kernel.gshell instead of org.apache.karaf.kernel.gshell Can we migrate it or duplicate it to have ActiveMq commands on Apache Karaf ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com
Re: Apache ServiceMix Features :: ActiveMQ Commands (4.0.0) / Apache Karaf
Sorry, I would like to say, you have the issue on servicemix features trunk ? Jean-Baptiste Onofré wrote: Yes Charles (I wasn't very clear). What's the features that references the "old" bundle ? Regards JB Charles Moulliard wrote: Hi Jean-Baptiste, GShell has already been migrated : [ 8] [Active ] [Started] [ 40] Apache Felix Karaf :: GShell Run (1.2.0.SNAPSHOT) [ 14] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Core (1.2.0.SNAPSHOT) [ 16] [Active ] [Started] [ 30] Apache Felix Karaf :: GShell OSGi Commands (1.2.0.SNAPSHOT) [ 26] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell ConfigAdmin Commands (1.2.0.SNAPSHOT) [ 27] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Log Commands (1.2.0.SNAPSHOT) [ 32] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell Admin (1.2.0.SNAPSHOT) [ 41] [Active ] [Started] [ 30] Apache Felix Karaf :: GShell Features (1.2.0.SNAPSHOT) [ 42] [Active ] [ ] [ 30] Apache Felix Karaf :: GShell PackageAdmin Commands (1.2.0.SNAPSHOT) Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Fri, Jun 5, 2009 at 11:12 AM, Jean-Baptiste Onofré wrote: Hi Charles, it makes sense to migrate ghsell to karaf too. Guillaume, what do you think ? Regards JB Charles Moulliard wrote: Hi, The following Servicemix features cannot be used with Apache Karaf because it requires package : org.apache.servicemix.kernel.gshell instead of org.apache.karaf.kernel.gshell Can we migrate it or duplicate it to have ActiveMq commands on Apache Karaf ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com
Re: Change the default port for the OSGI HTTP Service
+1 Edell Nolan wrote: Hi, The default port for the OSGi HTTP Service is 80 - as well as the default port for Tomcat being 8080. Would it be a big deal to add the following into our config.properties by default to change this port - say something like org.osgi.service.http.port=4567 ? Edell.
Re: How can i access Beans with camel via Java DSL?
Hi,
Is the jar containing bean is present in the SU lib directory ?
NB: please post this kind of message on the users mailing list.
Regards
JB
triggershot wrote:
Ok, another Problem. I want to access a Bean with Camel in my
MyRouteBuilder.java. I've tried sth. like that (like on camel.apache.org
described):
from("...").to("bean:beanName?method=beanMethod");
But my SMX cannot find my Bean. Why? How do i register my Bean in SMX so
that Camel can find it?
Thanks.
Re: NoTypeConversionAvailableException with servicemix-camel (Tutorial)
Hi,
I think that the problem is in the message content. When receiving from
a JBI endpoint, the message content is a Source and you need to use the
SourceTransformer to get the String, DOM, etc.
In your case, it looks like that you try to convert a Source to a Camel
DefaultMessage.
Regards
JB
triggershot wrote:
Hey,
i've tried the Camel-Tutorial from servicemix.apache.org. I can deploy the
SA (with SMX 4) but i get an NoTypeConversionAvailableException-Error when
my Timer sends a Message to my JMS-Provider:
09:59:05,500 | ERROR | 000&period=1 | TimerConsumer|
el.component.timer.TimerConsumer 100 | Caught:
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value Message: Hello
World
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value Message: Hello
World
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:121)
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:51)
[...]
I tried the tutorial three times - everytime the same error. If i send the
timer-Message to the SMX-Logger it works fine. Here is my Java Code:
###
package org.apache.servicemix.teste_camel;
import javax.xml.transform.dom.DOMSource;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.builder.BuilderSupport;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.CamelContext;
import org.apache.camel.Exchange;
import org.apache.camel.Message;
import org.apache.camel.NoTypeConversionAvailableException;
import org.apache.camel.TypeConverter;
import org.apache.camel.util.UuidGenerator;
public class MyRouteBuilder extends RouteBuilder
{
public void configure()
{
from("timer://tutorial?fixedRate=true&delay=3000&period=1")
.setBody(constant("Hello World"))
.to("jbi:endpoint:http://servicemix.apache.org/teste/jms/provider";);
from("jbi:endpoint:http://servicemix.apache.org/teste/jms/consumer";)
.to("log:tutorial-jbi")
.convertBodyTo(DOMSource.class)
.to("log:tutorial-domsource")
.convertBodyTo(String.class)
.to("log:tutorial-string");
}
}
###
Where is the fault?
Thanks.
Re: NoTypeConversionAvailableException with servicemix-camel (Tutorial)
Thanks for the tip Freeman.
Has the patch been applied on SMX4 ?
Should it applied ?
Regards
JB
Freeman Fang wrote:
Yeah, I also think so.
And I believe this issue(means find converter from camel bundles)
already get resolived with FUSE ESB 4.1 (which is based on apache smx
4), you can download it from [1] to try it.
[1]http://repo.open.iona.com/maven2/com/iona/fuse/fuse-esb/4.1.0.0/
Freeman
Jean-Baptiste Onofré wrote:
Hi,
I think that the problem is in the message content. When receiving
from a JBI endpoint, the message content is a Source and you need to
use the SourceTransformer to get the String, DOM, etc.
In your case, it looks like that you try to convert a Source to a
Camel DefaultMessage.
Regards
JB
triggershot wrote:
Hey,
i've tried the Camel-Tutorial from servicemix.apache.org. I can
deploy the
SA (with SMX 4) but i get an NoTypeConversionAvailableException-Error
when
my Timer sends a Message to my JMS-Provider:
09:59:05,500 | ERROR | 000&period=1 |
TimerConsumer|
el.component.timer.TimerConsumer 100 | Caught:
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class
org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value Message:
Hello
World
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class
org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value Message:
Hello
World
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:121)
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:51)
[...]
I tried the tutorial three times - everytime the same error. If i
send the
timer-Message to the SMX-Logger it works fine. Here is my Java Code:
###
package org.apache.servicemix.teste_camel;
import javax.xml.transform.dom.DOMSource;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.builder.BuilderSupport;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.CamelContext;
import org.apache.camel.Exchange;
import org.apache.camel.Message;
import org.apache.camel.NoTypeConversionAvailableException;
import org.apache.camel.TypeConverter;
import org.apache.camel.util.UuidGenerator;
public class MyRouteBuilder extends RouteBuilder {
public void configure() {
from("timer://tutorial?fixedRate=true&delay=3000&period=1")
.setBody(constant("Hello World"))
.to("jbi:endpoint:http://servicemix.apache.org/teste/jms/provider";);
from("jbi:endpoint:http://servicemix.apache.org/teste/jms/consumer";)
.to("log:tutorial-jbi")
.convertBodyTo(DOMSource.class)
.to("log:tutorial-domsource")
.convertBodyTo(String.class)
.to("log:tutorial-string"); }
}
###
Where is the fault?
Thanks.
Re: NoTypeConversionAvailableException with servicemix-camel (Tutorial)
Thanks Freeman,
I keep eyes on it :)
Regards
JB
Freeman Fang wrote:
Hi JB,
Yeah, the patch already applied on apache side also, actually it's
apache camel issue, [1] track it
[1]http://issues.apache.org/activemq/browse/CAMEL-1622
Regards
Freeman
Jean-Baptiste Onofré wrote:
Thanks for the tip Freeman.
Has the patch been applied on SMX4 ?
Should it applied ?
Regards
JB
Freeman Fang wrote:
Yeah, I also think so.
And I believe this issue(means find converter from camel bundles)
already get resolived with FUSE ESB 4.1 (which is based on apache smx
4), you can download it from [1] to try it.
[1]http://repo.open.iona.com/maven2/com/iona/fuse/fuse-esb/4.1.0.0/
Freeman
Jean-Baptiste Onofré wrote:
Hi,
I think that the problem is in the message content. When receiving
from a JBI endpoint, the message content is a Source and you need to
use the SourceTransformer to get the String, DOM, etc.
In your case, it looks like that you try to convert a Source to a
Camel DefaultMessage.
Regards
JB
triggershot wrote:
Hey,
i've tried the Camel-Tutorial from servicemix.apache.org. I can
deploy the
SA (with SMX 4) but i get an
NoTypeConversionAvailableException-Error when
my Timer sends a Message to my JMS-Provider:
09:59:05,500 | ERROR | 000&period=1 |
TimerConsumer|
el.component.timer.TimerConsumer 100 | Caught:
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class
org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value
Message: Hello
World
org.apache.camel.NoTypeConversionAvailableException: No type converter
available to convert from type: class
org.apache.camel.impl.DefaultMessage
to the required type: javax.xml.transform.Source with value
Message: Hello
World
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:121)
at
org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(DefaultTypeConverter.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:69)
at
org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:51)
[...]
I tried the tutorial three times - everytime the same error. If i
send the
timer-Message to the SMX-Logger it works fine. Here is my Java Code:
###
package org.apache.servicemix.teste_camel;
import javax.xml.transform.dom.DOMSource;
import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.builder.BuilderSupport;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.CamelContext;
import org.apache.camel.Exchange;
import org.apache.camel.Message;
import org.apache.camel.NoTypeConversionAvailableException;
import org.apache.camel.TypeConverter;
import org.apache.camel.util.UuidGenerator;
public class MyRouteBuilder extends RouteBuilder {
public void configure() {
from("timer://tutorial?fixedRate=true&delay=3000&period=1")
.setBody(constant("Hello World"))
.to("jbi:endpoint:http://servicemix.apache.org/teste/jms/provider";);
from("jbi:endpoint:http://servicemix.apache.org/teste/jms/consumer";)
.to("log:tutorial-jbi")
.convertBodyTo(DOMSource.class)
.to("log:tutorial-domsource")
.convertBodyTo(String.class)
.to("log:tutorial-string");
}
}
###
Where is the fault?
Thanks.
servicemix-http/servicemix-cxf-se bug ?
Hi Guys, I think that I have found a bug into servicemix-http with servicemix-cxf-se. An incorrect WSDL is generated using a HTTP endpoint combined with a CXF-SE one. The namespace prefix in the xbean.xml service name is used as-is in the generated WSDL. For example, I have the following xbean.xml: is translated in: name="fsb:exchange-rate-soap" [...]/> So I have: 1/ tns:fsb:xxx is not a valid namespace format. 2/ the fsb namespace is not even declared in the generated WSDL Is there some properties on cxf-se/http to generate a correct namespace ? Is it a bug ? If so, I will add a jira task and investigate to correct :) Regards JB -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: Boar report
Thanks Guillaume, I have just added a small sentence about JBI component roadmap and the ServiceMix Exec component. Regards JB Guillaume Nodet wrote: I've created a wiki page for the board report: http://cwiki.apache.org/confluence/display/SM/2009-06-24 I've I've missed anything, feel free to edit it.
Re: Release parent pom and ServiceMix 3.3.1
+1 for both parent POM and SMX 3.3.1. Regards JB Gert Vanthienen wrote: L.S., Now that the infra folks have set us up for doing our releases using Nexus (cfr. https://issues.apache.org/jira/browse/INFRA-2047), I would like to do a release of the ServiceMix parent POM later today. Together with that, I would suggest doing a ServiceMix 3.3.1 release so we can test the new release setting in the parent POM and have a ServiceMix 3 release with the same components as our ServiceMix 4.0.0 release out. Are there any outstanding patches that should desperately go into that before we release? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/
[RePing] Basic WSDL support in components
Hi guys, I have open the SMXCOMP-566 concerning basic WSDL support in all SMX components. I have already sent a message on the dev mailing list concerning this topic several weeks ago. Feel free to add any comment in the jira. Depending of the comments, I will begin to write documentation and prototype. Thanks a lot Regards JB
Re: [VOTE] Release servicemix-pom 3
+1 Gert Vanthienen wrote: L.S., The new parent pom under vote has been upgraded to use the latest apache parent pom (version 6) and includes the necessary configuration elements to make it possible to stage new releases in http://repository.apache.org. The staging repo for this release is at https://repository.apache.org/content/repositories/servicemix-staging-015/ The tag for this release is http://svn.apache.org/repos/asf/servicemix/servicemix-pom/tags/servicemix-pom-3/ Thanks for taking the time to review and vote! Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: RemoteServiceMixClient
Hi,
The javax.transaction.SystemException class is provided by
geronimo-jta_1.1_spec-1.1.jar.
In your client, you need to have this jar in the classpath.
Regards
JB
MindeloS wrote:
Hi, I was trying to create a RemoteServiceMixClient connection to servicemix
using standard invocation:
RemoteServiceMixClient client = new
RemoteServiceMixClient("http://localhost:61616";);
client.start();
using this .start() or . init() it gives error :
Exception in thread "main" java.lang.NoClassDefFoundError:
javax/transaction/SystemException
at
org.apache.activemq.pool.PooledConnectionFactory.createConnectionPool(PooledConnectionFactory.java:117)
at
org.apache.activemq.pool.PooledConnectionFactory.createConnection(PooledConnectionFactory.java:110)
at
org.apache.activemq.pool.PooledConnectionFactory.createConnection(PooledConnectionFactory.java:85)
at
org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow.init(AbstractJMSFlow.java:206)
at
org.apache.servicemix.jbi.nmr.DefaultBroker.init(DefaultBroker.java:122)
at
org.apache.servicemix.jbi.container.JBIContainer.init(JBIContainer.java:626)
at
org.apache.servicemix.client.RemoteServiceMixClient.init(RemoteServiceMixClient.java:92)
at Reenvio.main(Reenvio.java:64)
Caused by: java.lang.ClassNotFoundException:
javax.transaction.SystemException
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 8 more
this is probably an problem because some import that was missing, but I
can't find what it is? can some give a standard import list that may be
missing? thanks..
Re: WSDL support for all components ?
Hi Guillaume, I'm rethinking of these discuss related to WSDL support into components as I'm working on RMI and Exec components this morning. As I have a little more experience, let me add some comment to get team feedback. Guillaume Nodet wrote: On Sun, Feb 1, 2009 at 11:41, Jean-Baptiste Onofré wrote: In fact, it's in two parts : 1/ using a WSDL endpoint property to expose a WSDL can be interesting to use a BC directly with a SE supporting WSDL (for example, directly use a HTTP publishing a smpp WSDL). There are multiple things here. The first one is to add a property so that the endpoint exposes a WSDL to the NMR. The second one is to expose those WSDLs to the outside world (i.e. through HTTP for example). The third one, which I'm not clear if that's what you are suggesting, is to make all the BC support SOAP. Let's discuss those points. #1 for endpoints not supporting soap, it makes sense to be able to describe those using WSDL nonetheless when it makes sense. It should just be about adding a property to those endpoints and let the user specify its own abstract WSDL to describe the endpoint (this is already done in a number of EIP patterns for example). Yes, it's exactly the purpose. Basicly, I think that the WSDL can be marshaler related. The WSDL can describe the operation (with arguments) supported by the marshaler. The purpose is to define a manner to get information about message content and operation applied on the command into the endpoint descriptor. #2 I'm not sure about that one. Services exposed in the NMR are not necessarily available for external clients (especially if no BC consumer endpoint has been defined to target a given service). Furthermore, if we really want to expose those WSDLs (or at least the one of the BCs consumers which can be targetted by clients), we need those WSDLs contain the needed informations for the clients to be able to use those. This means that we have to define WSDL extensions for those protocols I suppose (we still have none for JMS, though a standard JMS extension is being worked on somewhere). Agreed, but it means that a "non-SOAP" component (such as exec, file, etc) can't be facaded directly using a HTTP or CXF-BC component. In this case, the user needs to add a component between the HTTP component and the Exec one for example to transform the incoming SOAP envelope into a valid message for the Exec endpoint. If we can add (at least a basic) SOAP support into all BC, the user can expose quickly basic services. AFAIK, OpenESB works like this: you define a WSDL for the component attribute (like in the xbean.xml) and define the endpoint behavior. #3 I don't have any problems with all BCs supporting SOAP. I'm just not sure if there is any real use of SOAP over XMPP, SNMP or SMPP. 2/ currently, BC uses "internal" format. For example, for the SMPP component, Lars has defined a XML format looking like this : +336123456 +336654321 INTERNATIONAL NATIONAL The SMS content If I need to use the SMPP, another SU must "format" the target message (the NormalizedMessage content) into the format expected by the SMPP one. Maybe it can be interesting to define a XSD (BC global or by components group) and linked util class to normalize the format of messages content. Or, in place of a XSD, define a kind of standard WSDL for BCs. I hope I'm clear :) I'm not sure how we can easily define a standard xml schema for all protocols. Each protocol has its own informations that it needs to be able to send the request. Wdyt ? Yes, you have right. But maybe each component can define its own XSD/WSDL. The user can construct a valid incoming message to this BC (using wsdl2java for example). All feedback are welcome. Regards JB Maybe this kind of stuff already exists and, if it's the case, accept my apologize :) Regards JB -- Jean-Baptiste Onofré j...@nanthrax.net BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net On Tue 27/01/09 13:07, "Guillaume Nodet" gno...@gmail.com wrote: Are you thinking about just exposing a WSDL service, or more like full soap support on file / ftp and other protocols ? On Mon, Jan 26, 2009 at 13:17, wrote: Hi all, Implementing the SMPP component, I have think about the WSDL support. Currently, some binding components don't support WSDL (the endpoint descriptor is empty). It's the case for file, ftp, xmpp and smpp components for example. Adding a WSDL property on these endpoints can be great and we will be able to store a SOAP envlope in a flat file (for example) and send directly to a WSDL compliant service engine (such as CXF-SE). What do you think about this ? Regards JB -- Cheers, Guillaume Nodet ---- Blog: http://gnodet.blogspot.com/ Open Source SOA http
Re: Introducing dummy shared library for servicemix-camel component that can be built by users for additional component.
Hi Ulhas, Thanks for your explanation. I guess that you have add the problem using SMX 4, right ? As servicemix-utils are already embedded into SMX and as this servicemix-utils already contains util classes used by servicemix-file, servicemix-soap, etc, we can put camel dependencies into this utils. What do you think of that ? Regards JB Ulhas Bhole wrote: Hi All, I was recently caught by the ClassCastException even though the class being casted was of same type while using servcemix-camel component on redeployment scenario. The problem was due to the class I was casting was loaded by Service Unit's class loader and redeploy or deploying another SA using same camel component (camel-cxf in this case) was not happy about it and throw ClassCastException. I was able to get around this problem by rebuilding servicemix-camel component but also was able to get it to work with creating new shared-library that contains additional components and servicemix-camel have dependency on this shared library. This would be much cleaner in terms of keeping the core servicemix-camel component unaffected from the additional camel components that user want to use. Here is my proposal for the change: We can introduce new dummy servicemix-camel-shared library which may (or may not) contain some dependency or work like a place holder and servicemix-camel component add dependency on this new shared library. In default case it can be just empty shared-library which later a use rebuild and add his own requirement (camel components) to it and this will be much cleaner than asking people to rebuild (and possibly pollute) servicemix-camel component. I am interested in knowing people's reaction and possible problems that I may have overlooked. I am especially interested in comments on how it will affect servicemix 4 OSGi stuff. Regards, Ulhas Bhole
[PROPOSAL] Work on SMX website
Hi guys, I have planned to work on the website and documentation this week end. I propose two first things: 1/ Little refactoring of SMX website navigation Currently, the website is mainly SMX3 oriented. When you click on "user's guide", "download", etc, you get SMX3 related link. To get SMX4 links4, you need first to click on SMX4 in "Community" section. It's reduce the visibility of SMX4. I propose to upgrade the website navigation (the menu on the left of the website) with the following entries: Products ServiceMix3 Getting Started FAQ Download Manual Tutorial ServiceMix4 Getting Started FAQ Download Manual Tutorial Components servicemix-jms ... Community Support Issues Contributing Discussion Forums Mailing Lists News Articles Users Team Developers Developer Guide Source Building IRC Room Related Projects Apache ActiveMQ ... 2/ I propose to add a manual-maven-plugin into SMX tooling. This maven plugin takes wiki pages and generate a professional PDF/HTML manual or users guide. It's the same approach used by Camel. We can begin with the following manual: - SMX3 Manual (gathering information from the current user's guide and other pages) - SMX4 Manual - Developer Guide - Release Guide What do you think on that ? Thanks for your feedback Regards JB -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: [PROPOSAL] Work on SMX website
Hi, I propose to update the homepage mock to begin: http://servicemix.apache.org/home2.html I will keep you posted during the week end. Regards JB Jean-Baptiste Onofré wrote: Hi guys, I have planned to work on the website and documentation this week end. I propose two first things: 1/ Little refactoring of SMX website navigation Currently, the website is mainly SMX3 oriented. When you click on "user's guide", "download", etc, you get SMX3 related link. To get SMX4 links4, you need first to click on SMX4 in "Community" section. It's reduce the visibility of SMX4. I propose to upgrade the website navigation (the menu on the left of the website) with the following entries: Products ServiceMix3 Getting Started FAQ Download Manual Tutorial ServiceMix4 Getting Started FAQ Download Manual Tutorial Components servicemix-jms ... Community Support Issues Contributing Discussion Forums Mailing Lists News Articles Users Team Developers Developer Guide Source Building IRC Room Related Projects Apache ActiveMQ ... 2/ I propose to add a manual-maven-plugin into SMX tooling. This maven plugin takes wiki pages and generate a professional PDF/HTML manual or users guide. It's the same approach used by Camel. We can begin with the following manual: - SMX3 Manual (gathering information from the current user's guide and other pages) - SMX4 Manual - Developer Guide - Release Guide What do you think on that ? Thanks for your feedback Regards JB -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: PROPOSAL: copy actions in SMX via java.nio channels
+1 Lars Heinemann wrote: Hi fellow devs, I added a fastCopy method to the servicemix-utils FileUtil class. This method uses the "powers" of the java.nio to move/copy data between an input and an output stream. This is a lot faster than reading to a byte[] and flushing it to the output stream. I already changed the BinaryFileMarshaler to use the fastCopy and tested the performance. The performance gain was really great especially dealing with big files. It would be nice to use this kind of copy everywhere in SMX where applicable. What do you think about it? Regards Lars
SMX documentation sandbox
Hi all, As I said on the user mailing list last week, I vegun to work on website and documentation. I have created a sandbox project to generate and maintain several guide using DocBook. For now, I have worked on the installation guide: http://svn.apache.org/repos/asf/servicemix/sandbox/jbonofre/documentation/ I have generated a first draft (in PDF and HTML format) to show you the kind of output that we can have: http://maven.nanthrax.net/documentation/ These files use the default DocBook style, of course, we can customize the stylesheet to make beautiful and professional outputs. This fist doc is mainly focused on SMX3 but I will do the same for SMX4 of course. I have think of the several guide: - installation guide: basic installation of SMX and getting start - manual: deeper explanation of the core of SMX and deeper configuration/tuning - contributor guide: how to build from the source, architectural topic All feedbacks are welcome. I have to sleep some hours now :) Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
WSDL support in component: test begin on servicemix-exec
Hi all, as discussed with Lars this afternoon, I begin some test on the servicemix-exec to support WSDL. I have added a first very basic WSDL for servicemix-exec endpoints: http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-exec/trunk/src/main/resources/servicemix-exec.wsdl I haven't yet defined complex type in messages, it's only to give you an overview of that I have in mind. For now, it's a "static" WSDL, it's not generated using JAX-WS using the servicemix-exec marshaler interface for example, but maybe we can generate it at build time. In the endpoint, I plan to do: - in the validate() method: WSDL validation and replace some WSDL attribute using endpoint attribute (to adapt binding name, etc). - in the start() method: loading of the WSDL and registering WSDL definition in the endpoint definition and definition document in the endpoint descriptor. I know that it's very early and I haven't yet do a lot of thing, but I would like to have any of your feedbacks. Thanks guys, Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: WSDL support in component: test begin on servicemix-exec
A last thing that I have forgotten. Of course in the process() method, I get the soap envelope in the "in" message, parse and validate it, push to the marshaler to get the "out" soap envelope. Regards JB Jean-Baptiste Onofré wrote: Hi all, as discussed with Lars this afternoon, I begin some test on the servicemix-exec to support WSDL. I have added a first very basic WSDL for servicemix-exec endpoints: http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-exec/trunk/src/main/resources/servicemix-exec.wsdl I haven't yet defined complex type in messages, it's only to give you an overview of that I have in mind. For now, it's a "static" WSDL, it's not generated using JAX-WS using the servicemix-exec marshaler interface for example, but maybe we can generate it at build time. In the endpoint, I plan to do: - in the validate() method: WSDL validation and replace some WSDL attribute using endpoint attribute (to adapt binding name, etc). - in the start() method: loading of the WSDL and registering WSDL definition in the endpoint definition and definition document in the endpoint descriptor. I know that it's very early and I haven't yet do a lot of thing, but I would like to have any of your feedbacks. Thanks guys, Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: About issue SM-343 - Infinite wait prevents clean shutdown
Thanks Grzesiek for your update.
We will review the issue using your information and update it.
Regards
JB
Grzegorz Kokosiński wrote:
Hi.
Issue:
http://issues.apache.org/activemq/browse/SM-343?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
Lastly I encountered on problem described in this issue. I have looked
inside the code and I found what had happened. I hope that it will help
someone of You to resolve this isssue.
So this how it looks.
First thread is trying to suspend flow and invokes suspend method on
AbstractFlow, so it takes monitor of this object because this method is
synchronized. But it does not lock writeLock for this moment.
The second thread is trying to execute send method. So it locks
readLock, then invokes doSend method of class SedaFlow, then inside this
method it invokes enqueuePacket method and tries to create queue by
method createQueue. But this method is synchronized, and monitor of this
object is taken by first thread, so it cannot execute it till the first
thread will leave suspend method. But first thread is trying to lock
writeLock, but it cannot do that, because second thread lock readLock...
and we have deadlock.
I have copied some of code, maybe it will be helpful.
AbstractFlow.java (servicemix-3.3.1)
116 public void send(MessageExchange me) throws JBIException {
117 if (log.isDebugEnabled()) {
118 log.debug("Called Flow send");
119 }
120 // do send
121 try {
122 lock.readLock().lock();
123 doSend((MessageExchangeImpl) me);
124 } finally {
125 lock.readLock().unlock();
126 }
127 }
AbstractFlow.java (servicemix-3.3.1)
132 public synchronized void suspend() {
133 if (log.isDebugEnabled()) {
134 log.debug("Called Flow suspend");
135 }
136 lock.writeLock().lock();
137 suspendThread = Thread.currentThread();
138 }
SedaFlow.java (servicemix-3.3.1)
176 protected void enqueuePacket(MessageExchangeImpl me) throws
JBIException {
177 ComponentNameSpace cns = me.getDestinationId();
178 SedaQueue queue = queueMap.get(cns);
179 if (queue == null) {
180 queue = createQueue(cns);
181 }
182 try {
183 queue.enqueue(me);
184 } catch (InterruptedException e) {
185 throw new MessagingException(queue + " Failed to enqueue
exchange: " + me, e);
186 }
187 }
188
189 protected synchronized SedaQueue createQueue(ComponentNameSpace
cns) throws JBIException {
Grzesiek
CXF BC and HTTP WSDL proxy
Hi gentlemen, In servicemix-http 2009.01 component, we made an enhancement to be able to get the WSDL provided by the targetService/targetEndpoint using a consumer HTTP endpoint. If the user doesn't provide any WSDL, the component can get the target one from the endpoint description, add binding if required and expose it. This behavior is not present in the HTTP component used in provider mode. Used as provider, the HTTP component requires a WSDL provided by the user. I haven't yet test if we can define a URL as WSDL Resource for provider (for example, using http://targethost:targetport/targetcontext/target.wsdl). Moreover, CXF-BC requires a provided WSDL (both used in provider or consumer). It doesn't support the kind of WSDL proxy as made in HTTP. I propose to: 1/ make a test of a HTTP WSDL Resource in the HTTP and CXF-BC component used as provider. 2/ add WSDL proxy support in the CXF-BC component (when used as consumer) as made in the HTTP component. Does it make sense for you ? Thanks for your feedback, Regards JB
HTTP component and ending / character
Hi all, During my tests on the WSDL support into the servicemix-exec component, I use soapUI to get the generated WSDL, construct the SOAP env and send the request. During the first tests, I was lost because my SOAP env get in the HTTP endpoint correctly but never routed to my exec endpoint. After checking the xbeans, the source code, I never see debug message coming into the exec endpoint. At this moment Magic Gert arrives and said: "try to use / at the end of your locationURI". This time, in soapUI, I have replace http://localhost:8192/fsb/exec by http://localhost:8192/fsb/exec/ and submit. And MIRACLE, it works (thanks again Gert). Shame on me, I remember that I had this issue in the past using HTTP component with CXF-SE. Now my question is: do we consider this ending / as a feature (I can't see the advantage) or as a bug ? Thanks for your feedback. Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: CXF BC and HTTP WSDL proxy
Hi all, I have checked into the CXF-BC trunk and in fact the WSDL proxy is already defined in the consumer mode. I can see a retrieveWSDL() method that, if the wsdl resource is null, get the WSDL of the target server/endpoint. This method is called in the validate() one when the endpoint definition is null. So it seems that the component documentation is not up to date as it's written that the WSDL attribute is required. I make a test and update the wiki page if required. Regards JB Jean-Baptiste Onofré wrote: Hi gentlemen, In servicemix-http 2009.01 component, we made an enhancement to be able to get the WSDL provided by the targetService/targetEndpoint using a consumer HTTP endpoint. If the user doesn't provide any WSDL, the component can get the target one from the endpoint description, add binding if required and expose it. This behavior is not present in the HTTP component used in provider mode. Used as provider, the HTTP component requires a WSDL provided by the user. I haven't yet test if we can define a URL as WSDL Resource for provider (for example, using http://targethost:targetport/targetcontext/target.wsdl). Moreover, CXF-BC requires a provided WSDL (both used in provider or consumer). It doesn't support the kind of WSDL proxy as made in HTTP. I propose to: 1/ make a test of a HTTP WSDL Resource in the HTTP and CXF-BC component used as provider. 2/ add WSDL proxy support in the CXF-BC component (when used as consumer) as made in the HTTP component. Does it make sense for you ? Thanks for your feedback, Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Multi action component aka multi-facet component
Hi all, Currently, in the process() method, our components execute a single action. For example, the servicemix-exec component execute a command, the file poller read file into a directory, etc. For most of components, this single action is enough. But some other components can do multiple actions. For example: - servicemix-exec can execute a command sync or async - servicemix-ldap can query the LDAP server, add LDAP entries, delete LDAP entries - servicemix-file can read files, delete files, copy files. - etc ... As you know (I'm boring you a lot with that :)), servicemix-exec begins to support WSDL and so we can define several operation in a port type. Using this, the user can construct a request corresponding to the expected operation. I would like to qualify this components as "multi-facet" as they can execute different actions (and returns different out messages if the MEP is in-out). Our components can be more agile and answer to a wide user needs. What do you think on that ? Does it make sense to you ? If there is no objection, I will implement sync and async operation in the servicemix-exec component. Thanks Regards JB -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: Cutting over SMX4 features and NMR to Karaf
Hi Eoghan, Did you raised a jira task on the NMR and features branch ? Else, I will create one. Regards JB Eoghan Glynn wrote: Folks, I'd like to put what I've done so far onto an integration branch for review etc. Can some committer create such a branch for the NMR and features SVN repositories? Once this is done, I'll submit a patch for the Karaf port. As I mentioned on another thread, there was a problematic dependency between the NMR/features integration tests and the old kernel AbstractIntegrationTest framework. After discussing this issue with Guillaume last week, I took the pragmatic approach of moving a cut-down version of the testing support into the NMR repo. The problematic tests are now passing. Cheers, Eoghan 2009/7/10 Eoghan Glynn Seems like we broad agreement that this is a good thing, so I'll look into putting together a patch. Obviously I'll need a committer to create the maintenance branches before applying the patch to trunk. Cheers, Eoghan -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: Cutting over SMX4 features and NMR to Karaf
Nevermind, I have just seen your jira tasks :) Eoghan Glynn wrote: Folks, I'd like to put what I've done so far onto an integration branch for review etc. Can some committer create such a branch for the NMR and features SVN repositories? Once this is done, I'll submit a patch for the Karaf port. As I mentioned on another thread, there was a problematic dependency between the NMR/features integration tests and the old kernel AbstractIntegrationTest framework. After discussing this issue with Guillaume last week, I took the pragmatic approach of moving a cut-down version of the testing support into the NMR repo. The problematic tests are now passing. Cheers, Eoghan 2009/7/10 Eoghan Glynn Seems like we broad agreement that this is a good thing, so I'll look into putting together a patch. Obviously I'll need a committer to create the maintenance branches before applying the patch to trunk. Cheers, Eoghan -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: Can ServiceMix ship the java mail ri bundle ?
Hi, no objection on my side to switch to java mail ri bundle. Regards JB On Tuesday 11 August 2009 - 23:23, Willem Jiang wrote: > Hi, > > Recently we got lots of user complains about using camel-mail in > servicemix[1][2][3]. > Since the sun's java mail more stable and more wildly used, a better > solution is to use the sun java mail bundle instead of the geronimo > one. > I found Spring bundle repository provides the mail[3] and the > activation[4] bundle. > Can Servicemix switch to ship java mail ri bundle? > > [1]http://fusesource.com/issues/browse/ESB-681 > [2]http://fusesource.com/issues/browse/ESB-682 > [3]http://fusesource.com/issues/browse/MR-173 > [4]http://www.springsource.com/repository/app/search?query=mail > [5]http://www.springsource.com/repository/app/search?query=activation > > Willem -- Jean-Baptiste Onofré - HomePage http://www.nanthrax.net - Contacts jbono...@apache.org j...@nanthrax.net - OpenSource BuildProcess/AutoDeploy http://buildprocess.sourceforge.net Apache ServiceMix http://servicemix.apache.org --- PGP : 17D4F086
Re: Refactoring NMR management infrastructure
Hi Eoghan, just seen your Jira and patch. I will try to make a review on it tonight. I will keep you posted soon. Regards JB Eoghan Glynn wrote: Folks, I've submitted a patch for SMX4NMR-140 with a refactoring of the NMR management infrastructure to eliminate duplication with multiple ManagementAgent/Contexts and instead share a single ManagementStrategy across the NMR and JBI layers. The other objective of this work to allow the management infrastructure to be more easily pluggable, so as to allow it to be conveniently replaced with an alternative implementation. Towards this end, I've re-cast the insfrastructure to conform to the simple & lightweight FUSEsource commons-management model[1]. I envisage that other Apache projects (such as Camel and CXF) will adopt this model also. The commons-management bundle is Apache licensed, so there's no legal baggage involved in taking a dependency on it. Can some commiter please review the patch and commit it if considered kosher? I'm away on vacation next week, so if there's any feedback or changes required etc., I'll have to deal with that on my return. Cheers, Eoghan [1] http://commonman.fusesource.org/
Re: Upgrade Servicemix-camel to use camel 2.0
Hi, thanks Willem for the patch. I apply on my local working copy and perform some tests. I will keep you posted (on the dev ml or on IRC). Regards JB Willem Jiang wrote: Hi, Since Camel 2.0 is coming out , can someone review my recent patch of SMXCOMP-563[1], which upgrades Servicemix-camel to use camel 2.0 ? Thanks, Willem
Re: Upgrade Servicemix-camel to use camel 2.0
Hi Willem, I begun some tests yesterday evening but encounter some issue especially on SMX 3.3.1. I need to work deeper on it to provide you a global overview. I will work on it this afternoon (FR time). Regards JB Willem Jiang wrote: Hi JB, Thanks for looking into my patch. It may take some time to figure out the relation ship of the camel jbi components and servicemix-camel component. Please feel free to give it a try :) Willem Jean-Baptiste Onofré wrote: Hi, thanks Willem for the patch. I apply on my local working copy and perform some tests. I will keep you posted (on the dev ml or on IRC). Regards JB Willem Jiang wrote: Hi, Since Camel 2.0 is coming out , can someone review my recent patch of SMXCOMP-563[1], which upgrades Servicemix-camel to use camel 2.0 ? Thanks, Willem
Re: [DISCUSS] What versions to put into assembly of SMX4(-SNAPSHOT)
Hi Lars, +1 #2 I prefer the #2. The usage of snapshot is interesting during development cycle. Regards JB lhein wrote: Just an addition to my initial posting: Option #2 has the positive side effect of reminding us to release a contained snapshot bundle before releasing next SMX version. Regards Lars lhein wrote: Hi fellow devs, I am just wondering what is a better approach for handling the build of SMX4 assembly in the means of contained bundle versions. For now the assembly (even 4.1.0-SNAPSHOT) does only come with the recent stable releases of our components and other deps - for instance 2009.01 for components even while the snapshots of those components are improved. So if someone is downloading a dev snapshot of smx4 he will get stable versions of the components but he may be interested in the latest versions maybe. Now he has to uninstall and install a newer version of several bundles inside manually. What do you think is the preferred way to build an assembly. I mean there are 2 possibilities for that: #1: Assemblies always only contain release versions of components and alike #2: Assemblies may contain snapshot versions of components and alike What do you think is best? Regards Lars -- http://lhein.blogspot.com - Regards Lars http://lhein.blogspot.com - Regards Lars http://lhein.blogspot.com http://lhein.blogspot.com
Re: Fwd: ASF Board Report - Initial Reminder for Sep 2009
Thanks for the reminder Guillaume. I guess that we create a wiki page for the september report to allow everyone to add content ? Regards JB Guillaume Nodet wrote: -- Forwarded message -- From: ASF Board Date: Tue, Sep 1, 2009 at 02:50 Subject: ASF Board Report - Initial Reminder for Sep 2009 To: Guillaume Nodet This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 23 September 2009, 2 pm PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - ServiceMix
Re: Fwd: ASF Board Report - Initial Reminder for Sep 2009
Sure, I create right now and add report concerning component. Regards JB Guillaume Nodet wrote: Right, that's how we're used to proceed. Wanna create the page itself ? On Tue, Sep 1, 2009 at 08:27, Jean-Baptiste Onofré wrote: Thanks for the reminder Guillaume. I guess that we create a wiki page for the september report to allow everyone to add content ? Regards JB Guillaume Nodet wrote: -- Forwarded message -- From: ASF Board Date: Tue, Sep 1, 2009 at 02:50 Subject: ASF Board Report - Initial Reminder for Sep 2009 To: Guillaume Nodet This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 23 September 2009, 2 pm PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - ServiceMix
Re: Fwd: ASF Board Report - Initial Reminder for Sep 2009
Guys, I created the september report page here: http://cwiki.apache.org/confluence/display/SM/2009-09-01 (it's a child page of http://cwiki.apache.org/confluence/display/SM/Board+reports). Please, feel free to add comments. Regards JB Guillaume Nodet wrote: Right, that's how we're used to proceed. Wanna create the page itself ? On Tue, Sep 1, 2009 at 08:27, Jean-Baptiste Onofré wrote: Thanks for the reminder Guillaume. I guess that we create a wiki page for the september report to allow everyone to add content ? Regards JB Guillaume Nodet wrote: -- Forwarded message -- From: ASF Board Date: Tue, Sep 1, 2009 at 02:50 Subject: ASF Board Report - Initial Reminder for Sep 2009 To: Guillaume Nodet This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 23 September 2009, 2 pm PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - ServiceMix
[VOTE] Release ServiceMix Exec component
Hi all, I have completed a new version of the ServiceMix Exec component. This version includes WSDL support. It means that an Exec endpoint expose an abstract WSDL that can be used by a SOAP compliant front BC (such as HTTP or CXF-BC). The default Exec marshaler uses JAXB to marshal/unmarshal in/out messages. For example, you can expose directly an Exec endpoint using a HTTP one. The Exec xbean looks like: and the HTTP xbean looks like: http://0.0.0.0:8192/test/exec/"; useJbiWrapper="false"/> The HTTP endpoint generates a concrete WSDL using the porttypedef provided by the exec endpoint. The users can generate a SOAP envelope containing the exec request. I have updated the wiki doc of the exec endpoint to explain this: http://servicemix.apache.org/servicemix-exec.html The exec endpoint source code is here: http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-exec/trunk/ Any comment is welcome, feel free to raise Jira to add enhancement or change request. Thanks, Regards JB
Re: [VOTE] Release ServiceMix Exec component
It depends if the component looks fine for you or not :) Regards JB Guillaume Nodet wrote: This looks more like a discussion thread rather than a vote thread, right ? I'll try to review the code tomorrow. On Wed, Sep 2, 2009 at 10:13, Jean-Baptiste Onofré wrote: Hi all, I have completed a new version of the ServiceMix Exec component. This version includes WSDL support. It means that an Exec endpoint expose an abstract WSDL that can be used by a SOAP compliant front BC (such as HTTP or CXF-BC). The default Exec marshaler uses JAXB to marshal/unmarshal in/out messages. For example, you can expose directly an Exec endpoint using a HTTP one. The Exec xbean looks like: and the HTTP xbean looks like: http://0.0.0.0:8192/test/exec/"; useJbiWrapper="false"/> The HTTP endpoint generates a concrete WSDL using the porttypedef provided by the exec endpoint. The users can generate a SOAP envelope containing the exec request. I have updated the wiki doc of the exec endpoint to explain this: http://servicemix.apache.org/servicemix-exec.html The exec endpoint source code is here: http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-exec/trunk/ Any comment is welcome, feel free to raise Jira to add enhancement or change request. Thanks, Regards JB
[DISCUSS] Abdera bundles
Hi again, I'm working on SMXCOMP-611 to provide bundles required by CXF. I have question regarding abdera bundle. Currently, we have an abdera-0.4.0-incubating bundle linked to the abdera-core dependency. CXF required other abdera dependency. I propose to create the following new bundles: - abdera-core-1.0 - abdera-client-1.0 - abdera-i18n-1.0 - abdera-parser-1.0 - abdera-spring-1.0 - abdera-extensions-geo-1.0 - abdera-extensions-html-1.0 - abdera-extensions-json-1.0 - abdera-extensions-main-1.0 Does it make sense for you ? Thanks Regards JB
Re: [DISCUSS] Abdera bundles
After dealing with Dan on IRC, CXF requires the following bundles: org.apache.abdera:abdera-core:0.4.0-incubating org.apache.abdera:abdera-i18n:0.4.0-incubating org.apache.abdera:abdera-parser:0.4.0-incubating org.apache.abdera:abdera-extensions-json:0.4.0-incubating org.apache.abdera:abdera-extensions-main:0.4.0-incubating Currently, only abdera-core is provided. I have two ways to do it: 1/ create only abdera bundle gathering all abdera components 2/ create one bundle per abdera part. From my point of view, I prefer 2 especially if the life cycle of abdera components is different (if the extensions version goes faster than the core part for example). What's your opinion ? Regards JB Guillaume Nodet wrote: Are they packaged in a way that turning them into OSGi bundles is even possible ? I'm mostly thinking about split packages: if the same package is provided by two different jars (each one contributing a few classes to the package), it won't work in OSGi and we'd have to turn them into a single bundle. On Wed, Sep 2, 2009 at 11:34, Jean-Baptiste Onofré wrote: Hi again, I'm working on SMXCOMP-611 to provide bundles required by CXF. I have question regarding abdera bundle. Currently, we have an abdera-0.4.0-incubating bundle linked to the abdera-core dependency. CXF required other abdera dependency. I propose to create the following new bundles: - abdera-core-1.0 - abdera-client-1.0 - abdera-i18n-1.0 - abdera-parser-1.0 - abdera-spring-1.0 - abdera-extensions-geo-1.0 - abdera-extensions-html-1.0 - abdera-extensions-json-1.0 - abdera-extensions-main-1.0 Does it make sense for you ? Thanks Regards JB
Re: [DISCUSS] Abdera bundles
Lol, in this case, we can gather all in one bundle, ok with that ? Regards JB Daniel Kulp wrote: I don't think Abdera HAS a release life cycle. They've been trying to get 1.0 out for well over a year now.That's why we're stuck on 0.4.0. Dan On Wed September 2 2009 9:24:36 am Jean-Baptiste Onofré wrote: After dealing with Dan on IRC, CXF requires the following bundles: org.apache.abdera:abdera-core:0.4.0-incubating org.apache.abdera:abdera-i18n:0.4.0-incubating org.apache.abdera:abdera-parser:0.4.0-incubating org.apache.abdera:abdera-extensions-json:0.4.0-incubating org.apache.abdera:abdera-extensions-main:0.4.0-incubating Currently, only abdera-core is provided. I have two ways to do it: 1/ create only abdera bundle gathering all abdera components 2/ create one bundle per abdera part. From my point of view, I prefer 2 especially if the life cycle of abdera components is different (if the extensions version goes faster than the core part for example). What's your opinion ? Regards JB Guillaume Nodet wrote: Are they packaged in a way that turning them into OSGi bundles is even possible ? I'm mostly thinking about split packages: if the same package is provided by two different jars (each one contributing a few classes to the package), it won't work in OSGi and we'd have to turn them into a single bundle. On Wed, Sep 2, 2009 at 11:34, Jean-Baptiste Onofré wrote: Hi again, I'm working on SMXCOMP-611 to provide bundles required by CXF. I have question regarding abdera bundle. Currently, we have an abdera-0.4.0-incubating bundle linked to the abdera-core dependency. CXF required other abdera dependency. I propose to create the following new bundles: - abdera-core-1.0 - abdera-client-1.0 - abdera-i18n-1.0 - abdera-parser-1.0 - abdera-spring-1.0 - abdera-extensions-geo-1.0 - abdera-extensions-html-1.0 - abdera-extensions-json-1.0 - abdera-extensions-main-1.0 Does it make sense for you ? Thanks Regards JB
Re: HELLO-WORLD-SE DON'T WORK
Hi Dani, could you provide at least: - your pom.xml - the your component entry class (as defined in the attribute of the jbi-maven-plugin) ? I move this thread in the user mailing list (it's not really dev thread). Thanks Regards JB silgurd wrote: Hello!! I has followed the Hello-World-SE tutorial step by step, but when I am trying to deploy it into Service Mix, I get the following error: java.lang.ClassNotFoundException: org.apache.servicemix.samples.helloworld.se.MyBootstrap in classloader org.apache.servicemix.samples.helloworld.se.MyBootstrap Can anybody help me?? Dani
Re: OSGi bundles and versioning
Hi Guillaume,
you have right, I have seen it when working on the bundles required by CXF.
I guess that we only need to add ;version=${version} in the pom.xml of
each bundle.
I doesn't see any Jira on this topic yes.
If all are right with this change, I raise a Jira task and begin today.
Regards
JB
Guillaume Nodet wrote:
I think we have a problem with lots (if not all) of bundles we've released.
Currently, they are importing their own package and do not use version
ranges.
Importing their own package may lead to real problems when deploying two
different versions of such a bundle. There is a high chance that the second
one will use the classes from the first one instead of their own classes.
Version ranges are also important to avoid some problems if the bundle is
wired to a dependent bundle with a new major version.
So I kinda think we need to update all the poms to change those and release
all those bundles.
Re: OSGi bundles and versioning
Hi Guillaume,
thanks for the explanation.
If I have right understood, the version policy in the super pom (using
bundle plugin) automatically set the version of the export package,
correct ? It's the same thing that doing it manually like this:
org.apache.commons.codec.*;version=${version}
I'm available to work on it.
Regards
JB
Guillaume Nodet wrote:
No, this isn't the only change required.
First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in the parent
pom for all bundles).
We need to add the following instruction for the maven bundle plugin:
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))
Then for each bundle, we need to make sure each package exported is not
imported. For example, if we have:
org.apache.commons.codec*
we need to add the following to imports:
!org.apache.commons.codec*
This line needs to be added at the beginning of the Import-Package
declaration.
If we want to work on that, let me know when you've done the first bundle
and we can check that everything is ok before modifying all the other ones.
On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré wrote:
Hi Guillaume,
you have right, I have seen it when working on the bundles required by CXF.
I guess that we only need to add ;version=${version} in the pom.xml of each
bundle.
I doesn't see any Jira on this topic yes.
If all are right with this change, I raise a Jira task and begin today.
Regards
JB
Guillaume Nodet wrote:
I think we have a problem with lots (if not all) of bundles we've
released.
Currently, they are importing their own package and do not use version
ranges.
Importing their own package may lead to real problems when deploying two
different versions of such a bundle. There is a high chance that the
second
one will use the classes from the first one instead of their own classes.
Version ranges are also important to avoid some problems if the bundle is
wired to a dependent bundle with a new major version.
So I kinda think we need to update all the poms to change those and
release
all those bundles.
Re: OSGi bundles and versioning
OK, it's clear now.
Does it make sense to set the version in the export-package ?
Maybe we can add it into the pom.xml too, can't we ?
Regards
JB
Guillaume Nodet wrote:
No, it is used for imported packages to automatically generate a version
range.
The below policy will transform version=1.5 into version=[1.5,2) for
any imported package.
On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <mailto:j...@nanthrax.net>> wrote:
Hi Guillaume,
thanks for the explanation.
If I have right understood, the version policy in the super pom
(using bundle plugin) automatically set the version of the export
package, correct ? It's the same thing that doing it manually like
this:
org.apache.commons.codec.*;version=${version}
I'm available to work on it.
Regards
JB
Guillaume Nodet wrote:
No, this isn't the only change required.
First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
the parent
pom for all bundles).
We need to add the following instruction for the maven bundle
plugin:
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))
Then for each bundle, we need to make sure each package exported
is not
imported. For example, if we have:
org.apache.commons.codec*
we need to add the following to imports:
!org.apache.commons.codec*
This line needs to be added at the beginning of the Import-Package
declaration.
If we want to work on that, let me know when you've done the
first bundle
and we can check that everything is ok before modifying all the
other ones.
On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
mailto:j...@nanthrax.net>> wrote:
Hi Guillaume,
you have right, I have seen it when working on the bundles
required by CXF.
I guess that we only need to add ;version=${version} in the
pom.xml of each
bundle.
I doesn't see any Jira on this topic yes.
If all are right with this change, I raise a Jira task and
begin today.
Regards
JB
Guillaume Nodet wrote:
I think we have a problem with lots (if not all) of
bundles we've
released.
Currently, they are importing their own package and do
not use version
ranges.
Importing their own package may lead to real problems
when deploying two
different versions of such a bundle. There is a high
chance that the
second
one will use the classes from the first one instead of
their own classes.
Version ranges are also important to avoid some problems
if the bundle is
wired to a dependent bundle with a new major version.
So I kinda think we need to update all the poms to
change those and
release
all those bundles.
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Fwd: OSGi bundles and versioning
Yes, I see in the super POM.
OK to raise the Jira and make a first bundle.
Regards
JB
Guillaume Nodet wrote:
I think it's already done IIRC.
The bundles-pom/pom.xm has the following definition:
${servicemix.osgi.export}
with the default value for servicemix.osgi.export being:
${servicemix.osgi.export.pkg}*;version=${pkgVersion};-split-package:=merge-first
Bundles pom's usually just have to define servicemix.osgi.export.pkg and
pkgVersion properties.
On Mon, Sep 7, 2009 at 10:26, Jean-Baptiste Onofré wrote:
OK, it's clear now.
Does it make sense to set the version in the export-package ?
Maybe we can add it into the pom.xml too, can't we ?
Regards
JB
Guillaume Nodet wrote:
No, it is used for imported packages to automatically generate a version
range.
The below policy will transform version=1.5 into version=[1.5,2) for any
imported package.
On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré > wrote:
Hi Guillaume,
thanks for the explanation.
If I have right understood, the version policy in the super pom
(using bundle plugin) automatically set the version of the export
package, correct ? It's the same thing that doing it manually like
this:
org.apache.commons.codec.*;version=${version}
I'm available to work on it.
Regards
JB
Guillaume Nodet wrote:
No, this isn't the only change required.
First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
the parent
pom for all bundles).
We need to add the following instruction for the maven bundle
plugin:
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))
Then for each bundle, we need to make sure each package exported
is not
imported. For example, if we have:
org.apache.commons.codec*
we need to add the following to imports:
!org.apache.commons.codec*
This line needs to be added at the beginning of the Import-Package
declaration.
If we want to work on that, let me know when you've done the
first bundle
and we can check that everything is ok before modifying all the
other ones.
On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
mailto:j...@nanthrax.net>> wrote:
Hi Guillaume,
you have right, I have seen it when working on the bundles
required by CXF.
I guess that we only need to add ;version=${version} in the
pom.xml of each
bundle.
I doesn't see any Jira on this topic yes.
If all are right with this change, I raise a Jira task and
begin today.
Regards
JB
Guillaume Nodet wrote:
I think we have a problem with lots (if not all) of
bundles we've
released.
Currently, they are importing their own package and do
not use version
ranges.
Importing their own package may lead to real problems
when deploying two
different versions of such a bundle. There is a high
chance that the
second
one will use the classes from the first one instead of
their own classes.
Version ranges are also important to avoid some problems
if the bundle is
wired to a dependent bundle with a new major version.
So I kinda think we need to update all the poms to
change those and
release
all those bundles.
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Merging karaf integration into trunk
Ok Guillaume, thanks for the update. If you need any test or help, please keep me informed. Regards JB Guillaume Nodet wrote: I plan to merge the karag integration work that has been done in the sandbox into trunk later today. This will be a bit dirsuptive, so if you have any ongoing work in trunk (for nmr and features), let me know if that's the case and I'll hold on a bit.
[VOTE] Release ServiceMix Component POM 4
Hi all, Lars has upgraded servicemix parent pom to version 3 to use the Apache Nexus repository. I propose to release a version 4 of the ServiceMix Component POM (and upgrade to version 5-SNAPSHOT) to be able to release new components. This release includes: - usage of servicemix-pom 3 - usage of servicemix-utils 1.2.0 Staging repository: https://repository.apache.org/content/repositories/servicemix-staging-047/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. PS: with the help of Gert, I have updated the release-guide wiki and I used it for this release to be sure it's correct: http://servicemix.apache.org/release-guide.html Thanks Regards JB
Re: [VOTE] Release ServiceMix Component POM 4
Thanks for the review Jamie. I have corrected just right now. Regards JB Jamie G. wrote: All in all a very nice job on the release-guide wiki :) Two very brief comments: 1) In the "Staging the Release Candidate" section the enumeration needs to be corrected (very minor issue). 2) Under "Wait for the Results" the part about "I will copy this release to the Felix dist directory", are there any more instructions regarding this? I would think that we would be copying into our own distribution directory. Jamie On Tue, Sep 8, 2009 at 4:30 PM, Lars Heinemann wrote: Hi, I only upgraded components pom to use the version 3 of the servicemix-pom containing the nexus repos. Lars 2009/9/8 Jean-Baptiste Onofré : Hi all, Lars has upgraded servicemix parent pom to version 3 to use the Apache Nexus repository. I propose to release a version 4 of the ServiceMix Component POM (and upgrade to version 5-SNAPSHOT) to be able to release new components. This release includes: - usage of servicemix-pom 3 - usage of servicemix-utils 1.2.0 Staging repository: https://repository.apache.org/content/repositories/servicemix-staging-047/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. PS: with the help of Gert, I have updated the release-guide wiki and I used it for this release to be sure it's correct: http://servicemix.apache.org/release-guide.html Thanks Regards JB -- http://lhein.blogspot.com -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net j...@nanthrax.net PGP : 17D4F086
Re: [VOTE] Release ServiceMix Component POM 4
Yes, I understand Guillaume. If you want, I can drop the component pom release, upgrade the bundles-pom to use the maven bundle plugin 2.0.0 and help you at least in test. I think it's better to make a RC including: - component pom - bundles pom - bundles What's your thought ? Regards JB Guillaume Nodet wrote: I would have liked to upgrade to maven bundle plugin to 2.0.0 and make sure everything is setup correctly for a release of the NMR and features. I hope there will be no impact on this pom, but given a lot of components do not work yet in the nmr (due to the switch to Karaf) ... Anyway, +1 We can always release a newer version if needed. On Tue, Sep 8, 2009 at 17:17, Jean-Baptiste Onofré wrote: Hi all, Lars has upgraded servicemix parent pom to version 3 to use the Apache Nexus repository. I propose to release a version 4 of the ServiceMix Component POM (and upgrade to version 5-SNAPSHOT) to be able to release new components. This release includes: - usage of servicemix-pom 3 - usage of servicemix-utils 1.2.0 Staging repository: https://repository.apache.org/content/repositories/servicemix-staging-047/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. PS: with the help of Gert, I have updated the release-guide wiki and I used it for this release to be sure it's correct: http://servicemix.apache.org/release-guide.html Thanks Regards JB
Re: [VOTE] Release ServiceMix Component POM 4
Fine for me. To all, sorry for this canceled vote, I drop the staging release and rollback the component pom. I'm going to prepare a new RC including more stuff. Regards JB Guillaume Nodet wrote: Yeah, that would sounds better to me, but I'm not strong on that. Up to you, you're the release manager. On Thu, Sep 10, 2009 at 10:25, Jean-Baptiste Onofré wrote: Yes, I understand Guillaume. If you want, I can drop the component pom release, upgrade the bundles-pom to use the maven bundle plugin 2.0.0 and help you at least in test. I think it's better to make a RC including: - component pom - bundles pom - bundles What's your thought ? Regards JB Guillaume Nodet wrote: I would have liked to upgrade to maven bundle plugin to 2.0.0 and make sure everything is setup correctly for a release of the NMR and features. I hope there will be no impact on this pom, but given a lot of components do not work yet in the nmr (due to the switch to Karaf) ... Anyway, +1 We can always release a newer version if needed. On Tue, Sep 8, 2009 at 17:17, Jean-Baptiste Onofré wrote: Hi all, Lars has upgraded servicemix parent pom to version 3 to use the Apache Nexus repository. I propose to release a version 4 of the ServiceMix Component POM (and upgrade to version 5-SNAPSHOT) to be able to release new components. This release includes: - usage of servicemix-pom 3 - usage of servicemix-utils 1.2.0 Staging repository: https://repository.apache.org/content/repositories/servicemix-staging-047/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. PS: with the help of Gert, I have updated the release-guide wiki and I used it for this release to be sure it's correct: http://servicemix.apache.org/release-guide.html Thanks Regards JB
Re: [VOTE] Release ServiceMix Component POM 4
The component-pom 4 RC has been dropped and the trunk has been rollbacked to the previous development iteration. I will submit a new vote with a whole RC including Guillaume's comment. Regards JB Jean-Baptiste Onofré wrote: Fine for me. To all, sorry for this canceled vote, I drop the staging release and rollback the component pom. I'm going to prepare a new RC including more stuff. Regards JB Guillaume Nodet wrote: Yeah, that would sounds better to me, but I'm not strong on that. Up to you, you're the release manager. On Thu, Sep 10, 2009 at 10:25, Jean-Baptiste Onofré wrote: Yes, I understand Guillaume. If you want, I can drop the component pom release, upgrade the bundles-pom to use the maven bundle plugin 2.0.0 and help you at least in test. I think it's better to make a RC including: - component pom - bundles pom - bundles What's your thought ? Regards JB Guillaume Nodet wrote: I would have liked to upgrade to maven bundle plugin to 2.0.0 and make sure everything is setup correctly for a release of the NMR and features. I hope there will be no impact on this pom, but given a lot of components do not work yet in the nmr (due to the switch to Karaf) ... Anyway, +1 We can always release a newer version if needed. On Tue, Sep 8, 2009 at 17:17, Jean-Baptiste Onofré wrote: Hi all, Lars has upgraded servicemix parent pom to version 3 to use the Apache Nexus repository. I propose to release a version 4 of the ServiceMix Component POM (and upgrade to version 5-SNAPSHOT) to be able to release new components. This release includes: - usage of servicemix-pom 3 - usage of servicemix-utils 1.2.0 Staging repository: https://repository.apache.org/content/repositories/servicemix-staging-047/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. PS: with the help of Gert, I have updated the release-guide wiki and I used it for this release to be sure it's correct: http://servicemix.apache.org/release-guide.html Thanks Regards JB
