You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by th...@artenum.com on 2011/10/19 12:49:39 UTC

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi andnon OSGi dependencies

Hi Dileepa,

I am a little off-topic regarding your question about removing unsued jars, but about converting third party jars to OSGi, the eclipse orbit project already provides a number of OSGified jar files here: 
http://download.eclipse.org/tools/orbit/downloads/
and the latest release:
http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/

Maybe it is worth having a look there.

Kind regards,
Ben

Le mer 19/10/11 12:28, Dileepa Jayakody dileepa@wso2.com a écrit:
> Hi,
> 
> I'm also working on something in-line to what's discussed here, so I
> would
> like to share my experience thinking it might be relevant to the
> topic
> discussed here.
> 
> My project uses 3rd party jars wrapped as osgi bundles since the
> project is
> on top of an OSGI runtime. I'm trying to reduce the size of some of
> the
> bundles which wrap 3rd party dependency jars as osgi bundles. (eg:
> apacheds,
> axis2 etc)
> The project uses maven bundle-plugin to make the bundles.
> 
> The general issue I'm facing is: how to remove unused jars(3rd party)
> from
> the  section of the bulky bundles.
> As a work-around, I use to a tool called JBoss Tattletale [1] (A cool
> tool
> to understand the project's classpath details as it gives
> comprehensive
> reports on certain topics.) to get an overview of the project
> class-path
> with regard to unused jars, duplicated jars, same jar with different
> versions, missing classes etc, and then with that information I'm
> able to
> identify unused jars (with no transitive dependency) in the bundle
> and
> remove them from the bundle classpath.
> Here I assume that these unused jars which were previously embedded
> as
> dependencies are no longer required when installing the bundle and
> running
> the system in the OSGI run-time.
> I was able to successfully install the bundles without any OSGI START
> time
> exceptions.
> 
> However I have a doubt if there could be any run-time exceptional
> cases. Can
> anyone give me some advice or point-out cases where it could throw
> errors?
> 
> Such case I can think of is Java reflection where it tries to load a
> particular class dynamically from a jar removed from embedded
> dependencies.
> (I'm not 100% sure if tattletale tracks reflection dependencies when
> reporting on unused jars)
> 
> [1] http://www.jboss.org/tattletale [1]
> 
> Thanks,
> Dileepa
> 
> On Wed, Oct 19, 2011 at 1:45 PM, Barbara Rosi-Schwartz  Barbara.Rosi-Schwartz@iggroup.com> wrote:
> 
> > Good morning, I am back!... ;-)
> >
> > I am trying out Neil's large bundle option as an interim solution.
> I am
> > using the
> >
> > *;scope=compile|runtime
> >
> > Instruction. When I deploy my fat bundle, it falls over with a
> transitive
> > dependency used in one of the embedded jars not being found (log4j,
> of all
> > classes). To fix that, I decided to try and add the instruction
> >
> > true
> >
> > However maven does not seem to like this as it fails to complete
> its job
> > with error:
> >
> > Class in different directory than declared. Path from class name is
> > com/sun/codemodel/CodeWriter.class but the path in the jar is
> > 1.0/com/sun/codemodel/CodeWriter.class from Jar:jaxb-xjc-2.1.10.jar
> >
> > Which I thought was fixed a while back.
> >
> > Any idea anyone?
> >
> > TIA,
> > B.
> >
> > -----Original Message-----
> > From: Neil Bartlett [njbartlett@gmail.com]
> > Sent: 17 October 2011 14:26
> > To: users@felix.apache.org
> > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of
> OSGi
> > and non OSGi dependencies
> >
> > Hi Barbara,
> >
> > I feel ambivalent about it ;-)
> >
> > It's clearly not ideal, but as part of a migration it's acceptable.
> Same
> > with embedding dependencies… both result in a fatter system than
> required.
> >
> > Rgds,
> > Neil
> >
> >
> >
> > On Monday, 17 October 2011 at 14:21, Barbara Rosi-Schwartz wrote:
> >
> > > Neil,
> > >
> > > what I was trying to do, was not to treat the company jars as
> "third
> > party" ones. Since I have access to the projects and their pom
> files, I was
> > trying to get at least the jars my project depends on to be more or
> less
> > proper OSGi bundles, at the same time hiding all of their internal
> > dependencies my project does not care about.
> > >
> > > Having said that, I can see that this implies potentially several
> copies
> > of the same libraries, which is not ideal. How do you feel about
> using a
> > large "3rd party" bundle when what one wants to achieve is
> modularity and
> > download/use of only those bundles and libs that are needed for a
> given user
> > invoked task? Still better than having several copies of the same
> libs?
> > >
> > > Thanks,
> > > B.
> > >
> > > -----Original Message-----
> > > From: Neil Bartlett [njbartlett@gmail.com]
> > > Sent: 17 October 2011 14:11
> > > To: users@felix.apache.org (users@felix.apache.org)
> > > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture
> of
> > > OSGi and non OSGi dependencies
> > >
> > > I appreciate that OSGifying a large set of legacy JARs is a
> significant
> > task.
> > >
> > > One approach you can use as a stepping stone is to create a
> single, large
> > "3rd party" bundle. This would contain basically all of the
> libraries you
> > require, referenced via Bundle-Classpath, and export the packages
> that you
> > need from your own bundles.
> > >
> > > The advantage of this versus embedding is that you only have one
> copy of
> > each library, and also that your main bundles are in pretty much
> the state
> > you want them to be in, using Import-Package etc. You can then
> gradually
> > dissolve the 3rd party bundle by removing a single library from its
> > Bundle-Classpath and OSGifying it in isolation, without needing to
> refactor
> > your own bundles.
> > >
> > > Regards
> > > Neil
> > >
> > >
> > >
> > > On Monday, 17 October 2011 at 13:44, Barbara Rosi-Schwartz wrote:
> > >
> > > > Thanks Neil.
> > > >
> > > > I did try what you suggest, but I got so many bees in my
> bonnet... :-(
> > I was on the path of OSGi-fying the whole organisation here, a lot
> more than
> > I had anticipated... eventually I gave that up in frustration.
> > > >
> > > > -----Original Message-----
> > > > From: Neil Bartlett [njbartlett@gmail.com]
> > > > Sent: 17 October 2011 12:11
> > > > To: users@felix.apache.org (users@felix.apache.org)
> > > > Subject: Re: Hot to configure Maven Bundle plug-in for a
> mixture of
> > > > OSGi and non OSGi dependencies
> > > >
> > > > Barbara,
> > > >
> > > > Why not OSGi-fy those third party dependencies and save the
> results in
> > a repository? You only have to do this once (per dependency) and it
> avoids
> > all the issues with embedding libraries.
> > > >
> > > > Rgds
> > > > Neil
> > > >
> > > >
> > > >
> > > > On Monday, 17 October 2011 at 11:51, Pierre Henry Perret wrote:
> > > >
> > > > > Hi Rosi,
> > > > >
> > > > > It recalls me some similar case I had in a project...
> > > > >
> > > > > I would had the *baz *dependance in the *parent *management
> > > > > section so that it is inherited from all *modules.*
> > > > > *
> > > > > *
> > > > > *WDYT ?
> > > > > *
> > > > > --
> > > > > Pierre-Henry Perret
> > > > > mob2: +33 (0)6 69 52 18 48
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2011/10/17 Barbara Rosi-Schwartz
> > > > >  > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)>
> > > > >
> > > > > > Hello.
> > > > > >
> > > > > > I am using the Maven Bundle plug-in to OSGi-ify
> dependencies
> > > > > > that we have on another team's jars. These jars in turn
> have
> > > > > > their own dependencies, some of which I have already
> OSGi-ified,
> > > > > > whereas others are third parties ones which I would just
> like to
> > embed in the generated bundles.
> > > > > >
> > > > > > Let's assume that the jar I want to OSGi-ify is artefact
> foo-bar
> > > > > > and that it contains a bunch of third party dependencies +
> a
> > > > > > dependency on artefact foo-baz, which I have already
> OSGi-ified.
> > > > > >
> > > > > > To this aim I configure my Maven Bundle plug-in as follows:
> > > > > >
> > > > > > 
> > > > > > 
> > > > > > com.foo.bar.*
> > > > > > ${parent.version}
> > > > > > com.foo.baz.client
> > > > > >
> !foo-baz,*;scope=compile|runtime > > > > > en
> > > > > > cy
> > > > > > 
> > > > > > 
> > > > > >
> > > > > > The generated com.foo.bar's MANIFEST.MF does contain the
> > > > > > expected Import-Package clause, but it also contains
> foo-baz.jar
> > > > > > in the Bundle-ClassPath clause, which is not what I want. I
> have
> > > > > > tried several permutation of the 
> specification,
> > but to no avail.
> > > > > >
> > > > > > How do I correctly specify the instructions to achieve my
> goal?
> > > > > >
> > > > > > TIA,
> > > > > > B.
> > > > > >
> > > > > > BARBARA ROSI-SCHWARTZ
> > > > > > Senior Developer
> > > > > >
> > > > > > IG Group|Cannon Bridge House
> > > > > > 25 Dowgate Hill|London|EC4R ZYA
> > > > > >
> > > > > > t: +44(0)20 7573 0208 (Direct)
> > > > > > t: +44(0)20 7896 0011 (Switchboard)
> > > > > > w: www.iggroup.com (http://www.iggroup.com)
> > > > > >
> > > > > >
> > > > > > ________________________________ The information contained
> in
> > > > > > this email is strictly confidential and for the use of the
> > > > > > addressee only, unless otherwise indicated.
> > > > > > If you are not the intended recipient, please do not read,
> copy,
> > > > > > use or disclose to others this message or any attachment.
> Please
> > > > > > also notify the sender by replying to this email or by
> telephone
> > > > > > (+44 (0)20 7896 0011) and then delete the email and any
> copies of
> > it.
> > > > > > Opinions, conclusions (etc) that do not relate to the
> official
> > > > > > business of this company shall be understood as neither
> given
> > > > > > nor endorsed by it. IG Group Holdings plc is a company
> registered
> > in England and Wales under number 01190902. VAT registration number
> 761 2978
> > 07.
> > > > > > Registered Office: Cannon Bridge House, 25 Dowgate Hill,
> London
> > EC4R 2YA.
> > > > > > Authorised and regulated by the Financial Services
> Authority.
> > > > > > FSA Register number 114059.
> > > >
> > > >
> > > > The information contained in this email is strictly
> confidential and
> > for the use of the addressee only, unless otherwise indicated. If
> you are
> > not the intended recipient, please do not read, copy, use or
> disclose to
> > others this message or any attachment. Please also notify the
> sender by
> > replying to this email or by telephone (+44 (0)20 7896 0011) and
> then
> > delete the email and any copies of it. Opinions, conclusions (etc)
> that do
> > not relate to the official business of this company shall be
> understood as
> > neither given nor endorsed by it. IG Group Holdings plc is a
> company
> > registered in England and Wales under number 01190902. VAT
> registration
> > number 761 2978 07. Registered Office: Cannon Bridge House, 25
> Dowgate Hill,
> > London EC4R 2YA. Authorised and regulated by the Financial Services
> > Authority. FSA Register number 114059.
> >
> >
> 
> 
> 
> Links:
> ------
> [1]
> http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.jboss.org%2Ftattl
> etale[2]
> http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.iggroup.com%29%0D
> %3C%2Ffont
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi andnon OSGi dependencies

Posted by Dileepa Jayakody <di...@wso2.com>.
Thanks Ben. I will sure give a look :-)

On Wed, Oct 19, 2011 at 4:19 PM, <th...@artenum.com> wrote:

> Hi Dileepa,
>
> I am a little off-topic regarding your question about removing unsued jars,
> but about converting third party jars to OSGi, the eclipse orbit project
> already provides a number of OSGified jar files here:
> http://download.eclipse.org/tools/orbit/downloads/
> and the latest release:
> http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/
>
> Maybe it is worth having a look there.
>
> Kind regards,
> Ben
>
> Le mer 19/10/11 12:28, Dileepa Jayakody dileepa@wso2.com a écrit:
> > Hi,
> >
> > I'm also working on something in-line to what's discussed here, so I
> > would
> > like to share my experience thinking it might be relevant to the
> > topic
> > discussed here.
> >
> > My project uses 3rd party jars wrapped as osgi bundles since the
> > project is
> > on top of an OSGI runtime. I'm trying to reduce the size of some of
> > the
> > bundles which wrap 3rd party dependency jars as osgi bundles. (eg:
> > apacheds,
> > axis2 etc)
> > The project uses maven bundle-plugin to make the bundles.
> >
> > The general issue I'm facing is: how to remove unused jars(3rd party)
> > from
> > the  section of the bulky bundles.
> > As a work-around, I use to a tool called JBoss Tattletale [1] (A cool
> > tool
> > to understand the project's classpath details as it gives
> > comprehensive
> > reports on certain topics.) to get an overview of the project
> > class-path
> > with regard to unused jars, duplicated jars, same jar with different
> > versions, missing classes etc, and then with that information I'm
> > able to
> > identify unused jars (with no transitive dependency) in the bundle
> > and
> > remove them from the bundle classpath.
> > Here I assume that these unused jars which were previously embedded
> > as
> > dependencies are no longer required when installing the bundle and
> > running
> > the system in the OSGI run-time.
> > I was able to successfully install the bundles without any OSGI START
> > time
> > exceptions.
> >
> > However I have a doubt if there could be any run-time exceptional
> > cases. Can
> > anyone give me some advice or point-out cases where it could throw
> > errors?
> >
> > Such case I can think of is Java reflection where it tries to load a
> > particular class dynamically from a jar removed from embedded
> > dependencies.
> > (I'm not 100% sure if tattletale tracks reflection dependencies when
> > reporting on unused jars)
> >
> > [1] http://www.jboss.org/tattletale [1]
> >
> > Thanks,
> > Dileepa
> >
> > On Wed, Oct 19, 2011 at 1:45 PM, Barbara Rosi-Schwartz
> Barbara.Rosi-Schwartz@iggroup.com> wrote:
> >
> > > Good morning, I am back!... ;-)
> > >
> > > I am trying out Neil's large bundle option as an interim solution.
> > I am
> > > using the
> > >
> > > *;scope=compile|runtime
> > >
> > > Instruction. When I deploy my fat bundle, it falls over with a
> > transitive
> > > dependency used in one of the embedded jars not being found (log4j,
> > of all
> > > classes). To fix that, I decided to try and add the instruction
> > >
> > > true
> > >
> > > However maven does not seem to like this as it fails to complete
> > its job
> > > with error:
> > >
> > > Class in different directory than declared. Path from class name is
> > > com/sun/codemodel/CodeWriter.class but the path in the jar is
> > > 1.0/com/sun/codemodel/CodeWriter.class from Jar:jaxb-xjc-2.1.10.jar
> > >
> > > Which I thought was fixed a while back.
> > >
> > > Any idea anyone?
> > >
> > > TIA,
> > > B.
> > >
> > > -----Original Message-----
> > > From: Neil Bartlett [njbartlett@gmail.com]
> > > Sent: 17 October 2011 14:26
> > > To: users@felix.apache.org
> > > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of
> > OSGi
> > > and non OSGi dependencies
> > >
> > > Hi Barbara,
> > >
> > > I feel ambivalent about it ;-)
> > >
> > > It's clearly not ideal, but as part of a migration it's acceptable.
> > Same
> > > with embedding dependencies… both result in a fatter system than
> > required.
> > >
> > > Rgds,
> > > Neil
> > >
> > >
> > >
> > > On Monday, 17 October 2011 at 14:21, Barbara Rosi-Schwartz wrote:
> > >
> > > > Neil,
> > > >
> > > > what I was trying to do, was not to treat the company jars as
> > "third
> > > party" ones. Since I have access to the projects and their pom
> > files, I was
> > > trying to get at least the jars my project depends on to be more or
> > less
> > > proper OSGi bundles, at the same time hiding all of their internal
> > > dependencies my project does not care about.
> > > >
> > > > Having said that, I can see that this implies potentially several
> > copies
> > > of the same libraries, which is not ideal. How do you feel about
> > using a
> > > large "3rd party" bundle when what one wants to achieve is
> > modularity and
> > > download/use of only those bundles and libs that are needed for a
> > given user
> > > invoked task? Still better than having several copies of the same
> > libs?
> > > >
> > > > Thanks,
> > > > B.
> > > >
> > > > -----Original Message-----
> > > > From: Neil Bartlett [njbartlett@gmail.com]
> > > > Sent: 17 October 2011 14:11
> > > > To: users@felix.apache.org (users@felix.apache.org)
> > > > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture
> > of
> > > > OSGi and non OSGi dependencies
> > > >
> > > > I appreciate that OSGifying a large set of legacy JARs is a
> > significant
> > > task.
> > > >
> > > > One approach you can use as a stepping stone is to create a
> > single, large
> > > "3rd party" bundle. This would contain basically all of the
> > libraries you
> > > require, referenced via Bundle-Classpath, and export the packages
> > that you
> > > need from your own bundles.
> > > >
> > > > The advantage of this versus embedding is that you only have one
> > copy of
> > > each library, and also that your main bundles are in pretty much
> > the state
> > > you want them to be in, using Import-Package etc. You can then
> > gradually
> > > dissolve the 3rd party bundle by removing a single library from its
> > > Bundle-Classpath and OSGifying it in isolation, without needing to
> > refactor
> > > your own bundles.
> > > >
> > > > Regards
> > > > Neil
> > > >
> > > >
> > > >
> > > > On Monday, 17 October 2011 at 13:44, Barbara Rosi-Schwartz wrote:
> > > >
> > > > > Thanks Neil.
> > > > >
> > > > > I did try what you suggest, but I got so many bees in my
> > bonnet... :-(
> > > I was on the path of OSGi-fying the whole organisation here, a lot
> > more than
> > > I had anticipated... eventually I gave that up in frustration.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Neil Bartlett [njbartlett@gmail.com]
> > > > > Sent: 17 October 2011 12:11
> > > > > To: users@felix.apache.org (users@felix.apache.org)
> > > > > Subject: Re: Hot to configure Maven Bundle plug-in for a
> > mixture of
> > > > > OSGi and non OSGi dependencies
> > > > >
> > > > > Barbara,
> > > > >
> > > > > Why not OSGi-fy those third party dependencies and save the
> > results in
> > > a repository? You only have to do this once (per dependency) and it
> > avoids
> > > all the issues with embedding libraries.
> > > > >
> > > > > Rgds
> > > > > Neil
> > > > >
> > > > >
> > > > >
> > > > > On Monday, 17 October 2011 at 11:51, Pierre Henry Perret wrote:
> > > > >
> > > > > > Hi Rosi,
> > > > > >
> > > > > > It recalls me some similar case I had in a project...
> > > > > >
> > > > > > I would had the *baz *dependance in the *parent *management
> > > > > > section so that it is inherited from all *modules.*
> > > > > > *
> > > > > > *
> > > > > > *WDYT ?
> > > > > > *
> > > > > > --
> > > > > > Pierre-Henry Perret
> > > > > > mob2: +33 (0)6 69 52 18 48
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2011/10/17 Barbara Rosi-Schwartz
> > > > > >  > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)>
> > > > > >
> > > > > > > Hello.
> > > > > > >
> > > > > > > I am using the Maven Bundle plug-in to OSGi-ify
> > dependencies
> > > > > > > that we have on another team's jars. These jars in turn
> > have
> > > > > > > their own dependencies, some of which I have already
> > OSGi-ified,
> > > > > > > whereas others are third parties ones which I would just
> > like to
> > > embed in the generated bundles.
> > > > > > >
> > > > > > > Let's assume that the jar I want to OSGi-ify is artefact
> > foo-bar
> > > > > > > and that it contains a bunch of third party dependencies +
> > a
> > > > > > > dependency on artefact foo-baz, which I have already
> > OSGi-ified.
> > > > > > >
> > > > > > > To this aim I configure my Maven Bundle plug-in as follows:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > com.foo.bar.*
> > > > > > > ${parent.version}
> > > > > > > com.foo.baz.client
> > > > > > >
> > !foo-baz,*;scope=compile|runtime > > > > > en
> > > > > > > cy
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The generated com.foo.bar's MANIFEST.MF does contain the
> > > > > > > expected Import-Package clause, but it also contains
> > foo-baz.jar
> > > > > > > in the Bundle-ClassPath clause, which is not what I want. I
> > have
> > > > > > > tried several permutation of the
> > specification,
> > > but to no avail.
> > > > > > >
> > > > > > > How do I correctly specify the instructions to achieve my
> > goal?
> > > > > > >
> > > > > > > TIA,
> > > > > > > B.
> > > > > > >
> > > > > > > BARBARA ROSI-SCHWARTZ
> > > > > > > Senior Developer
> > > > > > >
> > > > > > > IG Group|Cannon Bridge House
> > > > > > > 25 Dowgate Hill|London|EC4R ZYA
> > > > > > >
> > > > > > > t: +44(0)20 7573 0208 (Direct)
> > > > > > > t: +44(0)20 7896 0011 (Switchboard)
> > > > > > > w: www.iggroup.com (http://www.iggroup.com)
> > > > > > >
> > > > > > >
> > > > > > > ________________________________ The information contained
> > in
> > > > > > > this email is strictly confidential and for the use of the
> > > > > > > addressee only, unless otherwise indicated.
> > > > > > > If you are not the intended recipient, please do not read,
> > copy,
> > > > > > > use or disclose to others this message or any attachment.
> > Please
> > > > > > > also notify the sender by replying to this email or by
> > telephone
> > > > > > > (+44 (0)20 7896 0011) and then delete the email and any
> > copies of
> > > it.
> > > > > > > Opinions, conclusions (etc) that do not relate to the
> > official
> > > > > > > business of this company shall be understood as neither
> > given
> > > > > > > nor endorsed by it. IG Group Holdings plc is a company
> > registered
> > > in England and Wales under number 01190902. VAT registration number
> > 761 2978
> > > 07.
> > > > > > > Registered Office: Cannon Bridge House, 25 Dowgate Hill,
> > London
> > > EC4R 2YA.
> > > > > > > Authorised and regulated by the Financial Services
> > Authority.
> > > > > > > FSA Register number 114059.
> > > > >
> > > > >
> > > > > The information contained in this email is strictly
> > confidential and
> > > for the use of the addressee only, unless otherwise indicated. If
> > you are
> > > not the intended recipient, please do not read, copy, use or
> > disclose to
> > > others this message or any attachment. Please also notify the
> > sender by
> > > replying to this email or by telephone (+44 (0)20 7896 0011) and
> > then
> > > delete the email and any copies of it. Opinions, conclusions (etc)
> > that do
> > > not relate to the official business of this company shall be
> > understood as
> > > neither given nor endorsed by it. IG Group Holdings plc is a
> > company
> > > registered in England and Wales under number 01190902. VAT
> > registration
> > > number 761 2978 07. Registered Office: Cannon Bridge House, 25
> > Dowgate Hill,
> > > London EC4R 2YA. Authorised and regulated by the Financial Services
> > > Authority. FSA Register number 114059.
> > >
> > >
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.jboss.org%2Ftattl
> > etale[2]
> >
> http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.iggroup.com%29%0D
> > %3C%2Ffont
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Dileepa Jayakody,
Software Engineer, WSO2 Inc.
Lean . Enterprise . Middleware