On Dec 5, 2009, at 9:55 AM, Felix Meschberger wrote: > Or go for the Sling launcher ;-) It is by no means locked into Sling. It > just happens to live there (in the launchpad folder). +1 Best way to figure out if we need to make any further changes to the Sling launcher is to have non-Sling projects using it. Justin --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Hi Pavol Juhos schrieb: > Hi Felix, > > that's good news. Meanwhile I assume that the recommended approach is > to customize code provided in > > http://svn.apache.org/repos/asf/felix/trunk/http/samples/bridge/ Or go for the Sling launcher ;-) It is by no means locked into Sling. It just happens to live there (in the launchpad folder). Regards Felix > > Best regards, > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Hi Felix, that's good news. Meanwhile I assume that the recommended approach is to customize code provided in http://svn.apache.org/repos/asf/felix/trunk/http/samples/bridge/ Best regards, -- PJ On Sat, Dec 5, 2009 at 22:36, Felix Meschberger <fmeschbe@gmail.com> wrote: > Hi Pavol, > > We have just integrated the Felix Http Service bridge in the Sling > launcher contributed by Justin. > > Basically the Sling community is ok with contributing the launcher to > Felix but we wanted to convert to Felix Http Service first and check out > how exactly to convert. > > While it will probably still take some time to actually move the code > base, chances are that this will happen. > > Regards > Felix > > Pavol Juhos schrieb: >> Hi, >> >> some time ago there was a discussion about adding a Felix web app >> launcher as a default solution when using Apache Felix Http Service / >> Servlet Bridge. Felix Meschberger mentioned a possibility of donating >> Sling launcher to the Apache Felix project. Have the community reached >> any kind of conclusion on these points? >> >> It would be nice to have a standard/default way of embedding Felix in >> a web container as originally pointed out by Justin Edelson. >> >> Thanks! >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Hi Pavol, We have just integrated the Felix Http Service bridge in the Sling launcher contributed by Justin. Basically the Sling community is ok with contributing the launcher to Felix but we wanted to convert to Felix Http Service first and check out how exactly to convert. While it will probably still take some time to actually move the code base, chances are that this will happen. Regards Felix Pavol Juhos schrieb: > Hi, > > some time ago there was a discussion about adding a Felix web app > launcher as a default solution when using Apache Felix Http Service / > Servlet Bridge. Felix Meschberger mentioned a possibility of donating > Sling launcher to the Apache Felix project. Have the community reached > any kind of conclusion on these points? > > It would be nice to have a standard/default way of embedding Felix in > a web container as originally pointed out by Justin Edelson. > > Thanks! > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Hi, some time ago there was a discussion about adding a Felix web app launcher as a default solution when using Apache Felix Http Service / Servlet Bridge. Felix Meschberger mentioned a possibility of donating Sling launcher to the Apache Felix project. Have the community reached any kind of conclusion on these points? It would be nice to have a standard/default way of embedding Felix in a web container as originally pointed out by Justin Edelson. Thanks! -- Pavol Juhos [pavol.juhos@gmail.com] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
You are right ;-) Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard Linkedlin : http://www.linkedin.com/in/charlesmoulliard Apache Camel Group : http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm On Fri, Dec 4, 2009 at 3:28 PM, Karl Pauls <karlpauls@gmail.com> wrote: > On Fri, Dec 4, 2009 at 3:24 PM, Charles Moulliard <cmoulliard@gmail.com> > wrote: > > I try to deploy a camel-example-etl bundle configured to run with openjpa > on > > apache Felix Karaf > > > > When I try to start the bundle, I receive the following errors > > > > The bundle could not be resolved. Reason: Missing Constraint: > > Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" > > > > Here is the config of import > > > > org.apache.openjpa.jdbc.kernel;version="[1.2,2.0)";resolution=optional, > > This needs to be resolution:=optional no? > > regards, > > Karl > > > > > If I try without the resolution=optional, I get this error > > > > The bundle could not be resolved. Reason: Package uses conflict: > > Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" > > > > Here is what export the bundle openjpa > > > > karaf@root> packages:exports 62 > > > > Apache ServiceMix Bundles: openjpa-1.2.1 (62): > > org.apache.openjpa.jdbc.kernel; version="1.2.1" > > > > WHAT IS WRONG ? IS IT A BUG ? > > > > Charles Moulliard > > Senior Enterprise Architect > > Apache Camel Committer > > > > ***************************** > > blog : http://cmoulliard.blogspot.com > > twitter : http://twitter.com/cmoulliard > > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > > > Apache Camel Group : > > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm > > > > > > -- > Karl Pauls > karlpauls@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > >
On Fri, Dec 4, 2009 at 3:24 PM, Charles Moulliard <cmoulliard@gmail.com> wrote: > I try to deploy a camel-example-etl bundle configured to run with openjpa on > apache Felix Karaf > > When I try to start the bundle, I receive the following errors > > The bundle could not be resolved. Reason: Missing Constraint: > Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" > > Here is the config of import > > org.apache.openjpa.jdbc.kernel;version="[1.2,2.0)";resolution=optional, This needs to be resolution:=optional no? regards, Karl > > If I try without the resolution=optional, I get this error > > The bundle could not be resolved. Reason: Package uses conflict: > Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" > > Here is what export the bundle openjpa > > karaf@root> packages:exports 62 > > Apache ServiceMix Bundles: openjpa-1.2.1 (62): > org.apache.openjpa.jdbc.kernel; version="1.2.1" > > WHAT IS WRONG ? IS IT A BUG ? > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > twitter : http://twitter.com/cmoulliard > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > Apache Camel Group : > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm > -- Karl Pauls karlpauls@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
I try to deploy a camel-example-etl bundle configured to run with openjpa on apache Felix Karaf When I try to start the bundle, I receive the following errors The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" Here is the config of import org.apache.openjpa.jdbc.kernel;version="[1.2,2.0)";resolution=optional, If I try without the resolution=optional, I get this error The bundle could not be resolved. Reason: Package uses conflict: Import-Package: org.apache.openjpa.jdbc.kernel; version="[1.2.0,2.0.0)" Here is what export the bundle openjpa karaf@root> packages:exports 62 Apache ServiceMix Bundles: openjpa-1.2.1 (62): org.apache.openjpa.jdbc.kernel; version="1.2.1" WHAT IS WRONG ? IS IT A BUG ? Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard Linkedlin : http://www.linkedin.com/in/charlesmoulliard Apache Camel Group : http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
On Fri, Dec 4, 2009 at 11:30 AM, Charles Moulliard <cmoulliard@gmail.com> wrote: > Why such info is not provided to the console's user !!!! That's what I want as well :) > Surprisingly, using equinox as osgi platform on Apache Felix Karaf allow to > bind the same Hibernate bundles without any issues !! equinox implemented fragment support in different way and doesn't complain the conflict. -Guo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Thx. Adding the property : felix.log.level= 4 in config.properties file of Apache Felix Karaf helps me It should be interesting to add it by default as non commented property in the file otherwise people have to dig Internet ??? Here is the result : DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from com.springsource.org.hibernate due to conflict with imported package javassist.bytecode from com.springsource.org.hibernate DEBUG: Excluding fragment com.springsource.org.hibernate.annotations from com.springsource.org.hibernate due to conflict with imported package org.slf4j from com.springsource.org.hibernate Why such info is not provided to the console's user !!!! Surprisingly, using equinox as osgi platform on Apache Felix Karaf allow to bind the same Hibernate bundles without any issues !! Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard Linkedlin : http://www.linkedin.com/in/charlesmoulliard Apache Camel Group : http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm On Fri, Dec 4, 2009 at 11:59 AM, Guo Du <mrduguo@gmail.com> wrote: > On Fri, Dec 4, 2009 at 8:13 AM, Charles Moulliard <cmoulliard@gmail.com> > wrote: > > I have tested with logging defined as DEBUG or TRACE but no particular > info > > has been reported in the log. > > > > For me, that was working before. > I tried one of my fragment bundle and it works on 2.0.0 and 2.0.1. > > If you provide log information, it may helps to identify the problem. > > You should see "DEBUG: FRAGMENT WIRE: 86.0 -> hosted by -> 89.0" if it > works. > > Otherwise, you should see something like: > DEBUG: Excluding fragment XXX from YYY due to conflict with imported > package ZZZ > > A question for framework developer not related to this mail: do we > need log the conflict as ERROR level message instead of DEBUG level? > Because when there is conflict happens, it means there are something > wrong and user need attention immediately instead of start a debug > session. There are a few mail conversation asked about fragment, our > response are always turn on debug log and see what happens. > > > -Guo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > >
On Fri, Dec 4, 2009 at 8:13 AM, Charles Moulliard <cmoulliard@gmail.com> wrote: > I have tested with logging defined as DEBUG or TRACE but no particular info > has been reported in the log. > > For me, that was working before. I tried one of my fragment bundle and it works on 2.0.0 and 2.0.1. If you provide log information, it may helps to identify the problem. You should see "DEBUG: FRAGMENT WIRE: 86.0 -> hosted by -> 89.0" if it works. Otherwise, you should see something like: DEBUG: Excluding fragment XXX from YYY due to conflict with imported package ZZZ A question for framework developer not related to this mail: do we need log the conflict as ERROR level message instead of DEBUG level? Because when there is conflict happens, it means there are something wrong and user need attention immediately instead of start a debug session. There are a few mail conversation asked about fragment, our response are always turn on debug log and see what happens. -Guo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Thanks for all the suggestions. The maven-bundle-plugin is what I am using right now but it only provides means of creating and maintaining an OSGi infrastructure, not reausing the meat information from OSGi, which is what I am looking for. Both Tycho and Sigil look very promising but for my scenario they both have the same problem: Missing maven 2 integration (Tycho only works with maven 3 and even ships it with the downloadable). I am working in the enterprise area and things there are moving at glacial speed. We will be stuck with maven 2 for quite some time and if I want to get OSGi into our projects I will have to integrate everything with the existing architecture which is maven 2 + hudson. CU Jochen
I have tested with logging defined as DEBUG or TRACE but no particular info has been reported in the log. For me, that was working before. Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard Linkedlin : http://www.linkedin.com/in/charlesmoulliard Apache Camel Group : http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm On Thu, Dec 3, 2009 at 8:09 PM, Chris Custine <chris.custine@gmail.com>wrote: > Hi Charles, > In addition to Richard's suggestion to look at debug level framework > logging, I wonder was this working for you previously? > > 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, Dec 3, 2009 at 9:37 AM, Charles Moulliard <cmoulliard@gmail.com > >wrote: > > > I try to link a fragment bundle to its host but it does not succeed with > > Apache Felix 2.0.1 which is used on Apache Felix Karaf > > > > Here are the bundles installed for Hibernate : > > > > osgi:install -s > > > > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2 > > osgi:install -s mvn:org.antlr/com.springsource.antlr/2.7.7 > > osgi:install -s mvn:org.jgroups/com.springsource.org.jgroups/2.5.1 > > osgi:install -s > > mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3 > > osgi:install -s > > mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0 > > osgi:install -s mvn:org.jboss.javassist/com.springsource.javassist/ > > 3.9.0.GA > > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/ > 3.3.2.GA > > osgi:install -s > > mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/ > > 3.3.0.GA > > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/ > > 3.4.0.GA > > > > and the two bundles involved > > > > [ 86] [Installed ] [ ] [ ] [ 60] JBoss Hibernate > > Entity > > Manager (3.4.0.GA) // Fragment bundle > > [ 89] [Active ] [ ] [ ] [ 60] JBoss Hibernate > > Object-Relational Mapper (3.3.2.GA) // its host > > > > using the command > > > > osgi:refresh 89 > > > > does not affect the host bundle. The list of packages of the fragment > > bundles are not at all exported. > > > > Regards, > > > > Charles Moulliard > > Senior Enterprise Architect > > Apache Camel Committer > > > > ***************************** > > blog : http://cmoulliard.blogspot.com > > twitter : http://twitter.com/cmoulliard > > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > > > Apache Camel Group : > > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm > > >
Hi Charles, In addition to Richard's suggestion to look at debug level framework logging, I wonder was this working for you previously? 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, Dec 3, 2009 at 9:37 AM, Charles Moulliard <cmoulliard@gmail.com>wrote: > I try to link a fragment bundle to its host but it does not succeed with > Apache Felix 2.0.1 which is used on Apache Felix Karaf > > Here are the bundles installed for Hibernate : > > osgi:install -s > > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2 > osgi:install -s mvn:org.antlr/com.springsource.antlr/2.7.7 > osgi:install -s mvn:org.jgroups/com.springsource.org.jgroups/2.5.1 > osgi:install -s > mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3 > osgi:install -s > mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0 > osgi:install -s mvn:org.jboss.javassist/com.springsource.javassist/ > 3.9.0.GA > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA > osgi:install -s > mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/ > 3.3.0.GA > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/ > 3.4.0.GA > > and the two bundles involved > > [ 86] [Installed ] [ ] [ ] [ 60] JBoss Hibernate > Entity > Manager (3.4.0.GA) // Fragment bundle > [ 89] [Active ] [ ] [ ] [ 60] JBoss Hibernate > Object-Relational Mapper (3.3.2.GA) // its host > > using the command > > osgi:refresh 89 > > does not affect the host bundle. The list of packages of the fragment > bundles are not at all exported. > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > twitter : http://twitter.com/cmoulliard > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > Apache Camel Group : > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm >
Can you set the framework log level to debug to see if it is complaining about a conflict between the host and fragment? -> richard On 12/3/09 11:37, Charles Moulliard wrote: > I try to link a fragment bundle to its host but it does not succeed with > Apache Felix 2.0.1 which is used on Apache Felix Karaf > > Here are the bundles installed for Hibernate : > > osgi:install -s > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2 > osgi:install -s mvn:org.antlr/com.springsource.antlr/2.7.7 > osgi:install -s mvn:org.jgroups/com.springsource.org.jgroups/2.5.1 > osgi:install -s > mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3 > osgi:install -s > mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0 > osgi:install -s mvn:org.jboss.javassist/com.springsource.javassist/3.9.0.GA > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA > osgi:install -s > mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/3.3.0.GA > osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/ > 3.4.0.GA > > and the two bundles involved > > [ 86] [Installed ] [ ] [ ] [ 60] JBoss Hibernate Entity > Manager (3.4.0.GA) // Fragment bundle > [ 89] [Active ] [ ] [ ] [ 60] JBoss Hibernate > Object-Relational Mapper (3.3.2.GA) // its host > > using the command > > osgi:refresh 89 > > does not affect the host bundle. The list of packages of the fragment > bundles are not at all exported. > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > twitter : http://twitter.com/cmoulliard > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > Apache Camel Group : > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
I try to link a fragment bundle to its host but it does not succeed with Apache Felix 2.0.1 which is used on Apache Felix Karaf Here are the bundles installed for Hibernate : osgi:install -s mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2 osgi:install -s mvn:org.antlr/com.springsource.antlr/2.7.7 osgi:install -s mvn:org.jgroups/com.springsource.org.jgroups/2.5.1 osgi:install -s mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3 osgi:install -s mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0 osgi:install -s mvn:org.jboss.javassist/com.springsource.javassist/3.9.0.GA osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/3.3.0.GA osgi:install -s mvn:org.hibernate/com.springsource.org.hibernate.ejb/ 3.4.0.GA and the two bundles involved [ 86] [Installed ] [ ] [ ] [ 60] JBoss Hibernate Entity Manager (3.4.0.GA) // Fragment bundle [ 89] [Active ] [ ] [ ] [ 60] JBoss Hibernate Object-Relational Mapper (3.3.2.GA) // its host using the command osgi:refresh 89 does not affect the host bundle. The list of packages of the fragment bundles are not at all exported. Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard Linkedlin : http://www.linkedin.com/in/charlesmoulliard Apache Camel Group : http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
2009/12/3 David Savage <david.savage@paremus.com> > Hi Jochen, > > You may want to look at Sigil [1] which is hosted here at Felix. This > uses exactly the approach you suggest in that it resolves package > dependencies from OSGi manifest files. > for completeness I should mention the Tycho project, which can do manifest-first or pom-first: http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview as well as our very own Felix maven-bundle-plugin, which is more about re-using Maven details: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html hope that hasn't muddied the waters... > To see an example of a sigil build in action you may want to check out > a recent blog post [2] I made which is actually related to our product > but uses a sigil build to create the necessary bundles. > > Very happy to receive feedback, issues or code contributions in this area > :) > > Regards, > > Dave > > [1] http://felix.apache.org/site/apache-felix-sigil.html > [2] http://chronological-thought.blogspot.com/2009/11/hello-tatooine.html > > On Thu, Dec 3, 2009 at 1:24 PM, Jochen Mader <pflanzenmoerder@gmail.com> > wrote: > > Quite simply: I don't like my build process. > > I am looking for a way of doing builds that stays true with the OSGi > > philosophy. > > I got my builds going with Maven, BND and OBR. But looking at the poms > > always gives me the shivers. > > The thing that drives me nuts is the replication of dependency > information > > (the maven shotgun approach of "give me the bundle" vs the OSGi sniper > > approach "give that package"). > > We have to specify the dependencies once to do our build and a second > time > > to generate the manifest (BND). > > I can't make use of the extended meta information an OSGi bundle contains > > to, let's get wild, resolve my dependencies AND transitive dependencies > from > > an OBR. > > Is there some work being done that goes into that direction? Probably a > > project I could join? > > Something like maven plugin that replaces the dependency declarations > with a > > "go to BND and grab the information from there as we are way too lazy to > > type that stuff more than once" :) > > > > CU > > > > Jochen > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > > -- Cheers, Stuart
Hi Jochen, So trival hudson integration is easy in that it is just an ant build that wraps the sigil build so all the normal hooks apply. I admit I've not looked into any deeper integration - can you provide any links to the sort of functionality you'd be looking for here? Maven integration is something that I'd really like to work towards as it's obviously a big part of the software build ecosystem. The choice of ivy was in the main purely practical, as when we wrote sigil maven 2 didn't provide enough flexibility to plugin package level resolution (at least not to my understanding). I chatted with Jason a while ago when he was in London and Tycho looks like a major step in the write direction in terms of plugability. But hours in the day has meant that I've not made any progress in this area. As it's all OSS if there is sufficient will to bring these two worlds together then it's probably (?) just a matter of man hours. Regards, Dave On Thu, Dec 3, 2009 at 2:14 PM, Jochen Mader <pflanzenmoerder@gmail.com> wrote: > So it does what I want from the OSGi side :) > Now I will have to check how to integrate this with a maven/hudson build and > the underlying structure. > Have you tried something like that? > > CU > > Jochen > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
So it does what I want from the OSGi side :) Now I will have to check how to integrate this with a maven/hudson build and the underlying structure. Have you tried something like that? CU Jochen
Thanks for the quick reply. I will grab it and play around with it this weekend. Cheers, jochen
Hi Jochen, You may want to look at Sigil [1] which is hosted here at Felix. This uses exactly the approach you suggest in that it resolves package dependencies from OSGi manifest files. To see an example of a sigil build in action you may want to check out a recent blog post [2] I made which is actually related to our product but uses a sigil build to create the necessary bundles. Very happy to receive feedback, issues or code contributions in this area :) Regards, Dave [1] http://felix.apache.org/site/apache-felix-sigil.html [2] http://chronological-thought.blogspot.com/2009/11/hello-tatooine.html On Thu, Dec 3, 2009 at 1:24 PM, Jochen Mader <pflanzenmoerder@gmail.com> wrote: > Quite simply: I don't like my build process. > I am looking for a way of doing builds that stays true with the OSGi > philosophy. > I got my builds going with Maven, BND and OBR. But looking at the poms > always gives me the shivers. > The thing that drives me nuts is the replication of dependency information > (the maven shotgun approach of "give me the bundle" vs the OSGi sniper > approach "give that package"). > We have to specify the dependencies once to do our build and a second time > to generate the manifest (BND). > I can't make use of the extended meta information an OSGi bundle contains > to, let's get wild, resolve my dependencies AND transitive dependencies from > an OBR. > Is there some work being done that goes into that direction? Probably a > project I could join? > Something like maven plugin that replaces the dependency declarations with a > "go to BND and grab the information from there as we are way too lazy to > type that stuff more than once" :) > > CU > > Jochen > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Quite simply: I don't like my build process. I am looking for a way of doing builds that stays true with the OSGi philosophy. I got my builds going with Maven, BND and OBR. But looking at the poms always gives me the shivers. The thing that drives me nuts is the replication of dependency information (the maven shotgun approach of "give me the bundle" vs the OSGi sniper approach "give that package"). We have to specify the dependencies once to do our build and a second time to generate the manifest (BND). I can't make use of the extended meta information an OSGi bundle contains to, let's get wild, resolve my dependencies AND transitive dependencies from an OBR. Is there some work being done that goes into that direction? Probably a project I could join? Something like maven plugin that replaces the dependency declarations with a "go to BND and grab the information from there as we are way too lazy to type that stuff more than once" :) CU Jochen
Thanks Rob for the reply.
I am thinking along the same lines but use izpack for example.
Regards,
-Tony
--- On Wed, 12/2/09, Rob Walker <robw@ascert.com> wrote:
> From: Rob Walker <robw@ascert.com>
> Subject: Re: Deployment question...
> To: users@felix.apache.org
> Date: Wednesday, December 2, 2009, 10:45 PM
> Tony
>
> It's possible to use both - a small "shim" launcher that
> deploys via
> WebStart and launches OSGi, which does the rest of your
> deployment and
> then manages updates afterwards. You'll need to write some
> code to do
> this, but it's possible.
>
> -- Rob
>
> Tony Anecito wrote:
> > Hi,
> > I am a newbe to felix and have been using java web
> start for years. I found out via the OSGi forum that the
> framework is not meant for inital deployment and recommended
> staying with web start for that functionality.
> >
> > I am looking for a complete intial deployment and
> update solution. Does Felix also provide the missing piece?
> My goal is deploy like a regular app and update using OSGi
> if possible.
> >
> > Any suggestions?
> >
> > Thanks,
> > -Tony
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> --
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Tony It's possible to use both - a small "shim" launcher that deploys via WebStart and launches OSGi, which does the rest of your deployment and then manages updates afterwards. You'll need to write some code to do this, but it's possible. -- Rob Tony Anecito wrote: > Hi, > I am a newbe to felix and have been using java web start for years. I found out via the OSGi forum that the framework is not meant for inital deployment and recommended staying with web start for that functionality. > > I am looking for a complete intial deployment and update solution. Does Felix also provide the missing piece? My goal is deploy like a regular app and update using OSGi if possible. > > Any suggestions? > > Thanks, > -Tony > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > > -- Ascert - Taking systems to the Edge robw@ascert.com +44 (0)20 7488 3470 www.ascert.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
On Dec 2, 2009, at 1:46 PM, Ziegenlippe wrote: > I had some thoughts on that Osgi serialization issue. > If Osgi would disallow to place one and the same class name in > different bundles (even just by convention) it would be always > possible to find the proper bundle for an input data stream. Unfortunately, OSGi does not impose that restriction. In fact, the ability for more than one bundle to provide or contain the "same" class (by FQN) is one of the key benefits of OSGi. > Class name + version (or serialId) would uniquely identify the class > to be loaded. To add the bundle name to the stream does work but is > somehow strange to me. Fully-qualified class name plus the serial ID might be good enough to unambiguously identify a class, but I don't think it's guaranteed. Regardless of the approach, you need to get to a bundle, because that's how you get the classloader. You could use a heuristic like this to search for the bundle, but for my application at least, it was a lot easier to just include the owning bundle name in the serialized form and use that on the other end. I figure if you can influence the deserialization logic, you can probably also influence the serialization logic, so you may as well have them cooperate... > Having the same interface placed in different bundles seem to me > quite mysterious. For the osgi framework interface package you could > use for instance: > the felix bundle: <groupId>org.apache.felix</groupId> > <artifactId>org.osgi.core</artifactId> > <version>1.4.0</version> > or > the osgi bundle: > <groupId>org.osgi</groupId> > <artifactId>org.osgi.core</artifactId> > <version>4.2.0</version> > What for is this good? In my opinion there should be only one > distribution bundle of an interface. This possibly would make also > serialization easier? One use case I know of for allowing this is to permit multiple versions of the same bundle to be loaded at the same time, to satisfy mutually-exclusive version dependencies of other (presumably) independent bundles. I agree that this is an odd situation in which to find oneself. However, when it does happen, and it's not an accident or oversight, I'd imagine it's because the developers really had no other alternative. The fact that OSGi can accommodate these scenarios at all (afaik no other java container has this level of flexibility) is a bit part of its appeal imo. > Since in Osgi you imports bundles not modules you wouldn't know how > many redistributions of one and the same interface you have in your > environment. > Bye, > Andy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
I had some thoughts on that Osgi serialization issue.
If Osgi would disallow to place one and the same class name in different
bundles (even just by convention) it would be always possible to find
the proper bundle for an input data stream.
Class name + version (or serialId) would uniquely identify the class to
be loaded. To add the bundle name to the stream does work but is somehow
strange to me.
Having the same interface placed in different bundles seem to me quite
mysterious. For the osgi framework interface package you could use for
instance:
the felix bundle:
<groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
<version>1.4.0</version>
or
the osgi bundle:
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.2.0</version>
What for is this good? In my opinion there should be only one
distribution bundle of an interface. This possibly would make also
serialization easier?
Since in Osgi you imports bundles not modules you wouldn't know how many
redistributions of one and the same interface you have in your environment.
Bye,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
A more concrete example would be if you want to store a JMS message. JMS
provides an interface for Message and another interface Session in order
to create it.
I guess the Message interface is always something to be exported whereas
the real message type e.g. MantaMqMessage which implements this
interface is private property.
So what I have is just a pointer to Message:
Message msg=Session.createMessage(){
return new MantaMqMessage();
}
Serialization is no problem so far because you know the MantaMqMessage
through reflection. But deserialization would have to create a
MantaMqMessage instance but cannot find it since is secretly kept in
some bundle classloader.
Bye,
Andy
Angelo vd Sijpt schrieb:
> I'm not quite sure what you're trying to accomplish in that way...
> If the references are not necessary when deserializing, make them transient.
> If they are necessary, there's something peculiar about your design; is it
> really necessary that they are implementations of some interface because
> they're used as services, or are they actually just value objects?
>
> Angelo
>
> On Wed, Dec 2, 2009 at 10:49 AM, andrea ziege <ziegenlippe@googlemail.com>wrote:
>
>
>> This is ok I do it the same way:
>> XStream stream=new XStream();
>> stream.setClassLoader(Activator.class.getClassLoader());
>>
>> My problem was that the class I serialize contains references to interfaces
>> which are visible from my bundle. But the implementation classes are
>> invisible. This isn't a problem for serialization but for deserialization.
>> So even DynamicImport doesn't work. So I would need to make the impl
>> classes
>> public visible. Which I'm not able in all cases and what is in my opinion a
>> dirty fix.
>> Bye,
>> Andy
>>
>> 2009/12/2 Angelo vd Sijpt <angelovds@gmail.com>
>>
>>
>>> Maybe I'm going down the wrong path here, but if your bundle B uses
>>>
>> XStream
>>
>>> too, you can make use of that.
>>> XStream will by default use (I believe) the system classloader, and not
>>>
>> the
>>
>>> classloader of bundle B. You can make it use the correct one by passing
>>> your
>>> own classloader:
>>>
>>> new XStream(null, new XppDriver(), BundleBClass.class.getClassLoader());
>>>
>>> You should make sure BundleBClass is some class that is loaded by the
>>> classloader of bundle B, since that has access to the imported classes
>>>
>> from
>>
>>> bundle A.
>>>
>>> Angelo
>>>
>>> On Tue, Dec 1, 2009 at 7:44 PM, Ziegenlippe <ziegenlippe@googlemail.com
>>>
>>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I cannot find a satisfying solution to a simple looking problem for
>>>>
>> quite
>>
>>> a
>>>
>>>> while.
>>>>
>>>> The condensation of the problem:
>>>> Bundle A
>>>> the producer stores objects as xml files (e.g. with XStream)
>>>> it exports the /bundle.a/ package which contains the interface /Item/
>>>>
>>> it
>>>
>>>> contains a private implementation package /bundle.a.impl/ which
>>>>
>> contains
>>
>>> the
>>>
>>>> item implementation class /ItemImpl/
>>>>
>>>> Bundle B
>>>> the consumer needs to load and process /Item/ instances
>>>> therefor it imports package /bundle.a/ which contains the /Item/
>>>>
>>> interface
>>>
>>>> Problem: loading Item instances in bundle B leads always to
>>>> ClassNotFoundExceptions
>>>>
>>>> Even working with the last resort /DynamicImport-Package: * / does not
>>>> solve the problem since it imports only exported packages.
>>>>
>>>> From some hints in the internet I got the feeling that this issue is
>>>>
>> not
>>
>>>> really solved for OSGI. Is there any solution known? How deal others
>>>>
>> with
>>
>>>> that issue e.g. ActiveMq which claims to be OSGI compliant.
>>>> Or am I just on the wrong way?
>>>>
>>>> Thank you in advance,
>>>> Andy
>>>>
>>>>
>>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
I gave it a trial and it really works. Seems to work in general or at
least when you have the chance to replace the ObjectIn/OutputStream
implementation (which is for god sake possible for Hazelcast).
Regarding dynamically going bundles I would say hasta la vista baby. If
your classes are not available you cannot deserialize Osgi or plain Java
there is no difference.
But on the other hand if you update bundles you may have newer and
better classes available which are still compatible. This could be
handled with Kris solution too. This nice PackageAdmin can give you
bundles for version ranges. The only thing you need take care about is a
proper version scheme e.g. like APR does or at least proposes:
http://apr.apache.org/versioning.html. Than the deserializer would know
up to which version it could go. I guess something like that is done
with MS dot net. They have the module system integrated into the
platform and I think there are version compatibility rules too.
Bye,
Andy
Mike Haney schrieb:
> Kris - that's an interesting solution. I'm not familiar enough with the
> inner workings of serialization, but I wonder if it would be possible to do
> this on a global level and package it into a bundle to provide this support
> across the entire OSGi runtime? That would be a decent partial solution to
> the problem. It still doesn't help the problem with bundles dynamically
> coming and going, but should be sufficient for many use cases, for example
> storing data to the HTTP session between request (a la Wicket).
>
> On Tue, Dec 1, 2009 at 3:11 PM, Kris Pruden <kpruden@gmail.com> wrote:
>
>
>> On Dec 1, 2009, at 11:16 AM, Ziegenlippe wrote:
>>
>> Nice. Does this mean I have to take care about serialization by my own? I
>>
>>> use great libs XStream and Hazelcast. Both of them are doing a good
>>> serialization job. But I see without bundle-id+version there is no way.
>>> Thanks for the answer,
>>>
>>>
>> Not necessarily. Some libraries support the injection of custom hooks at
>> various stages of the serialization/deserialization process.
>>
>> As an example, I was able to create OSGi-aware versions of
>> Object{Output,Input}Stream by overriding the annotateClass() and
>> resolveClass() methods, respectively.
>>
>> I'm not familiar with XStream, but it wouldn't surprise me if it offered
>> some way to influence the class loading process..
>>
>> As for Hazelcast, I actually went down that path and got it to work by
>> registering custom serializers which used the OSGi-aware object streams I
>> talked about above.
>>
>> Here's the activator I used:
>>
>> package com.hazelcast.osgi;
>>
>> import org.osgi.framework.BundleActivator;
>> import org.osgi.framework.BundleContext;
>> import org.osgi.framework.ServiceReference;
>> import org.osgi.service.packageadmin.PackageAdmin;
>>
>> import com.hazelcast.core.Hazelcast;
>> import com.hazelcast.nio.Serializer;
>>
>> public class Activator implements BundleActivator {
>> public void start(BundleContext context) throws Exception {
>> ServiceReference ref =
>> context.getServiceReference(PackageAdmin.class.getName());
>> PackageAdmin pkgAdmin = (PackageAdmin) context.getService(ref);
>> Serializer.registerTypeSerializer(new OsgiObjectSerializer());
>> Serializer.registerTypeSerializer(new OsgiDataSerializer(pkgAdmin));
>> }
>>
>> public void stop(BundleContext context) throws Exception {
>> Serializer.registerTypeSerializer(new
>> Serializer.ObjectSerializer());
>> Serializer.registerTypeSerializer(new Serializer.DataSerializer());
>> Hazelcast.shutdown();
>> }
>> }
>>
>> The implementations of OsgiObjectSerializer and OsgiDataSerializer are
>> pretty similar to the versions that come with Hazelcast; they simply inject
>> a bundle name into the stream during serialization, and during
>> deserialization use that name to lookup the bundle to use to load the
>> class..
>>
>> Kris
>>
>>
>> Andy
>>
>>> Kris Pruden schrieb:
>>>
>>>
>>>> I had a similar problem. The solution boils down to delegating to the
>>>> "owning" bundle to load the class. To do this you need of course to know
>>>> the name of the bundle. In my case I was able to solve this problem with
a
>>>> couple helper methods that wrap the PackageAdmin service provided by OSGi:
>>>>
>>>> public String getBundleName(Class<?> cls) {
>>>> Bundle bundle = pkgAdmin.getBundle(cls);
>>>> if (bundle != null) {
>>>> return bundle.getSymbolicName();
>>>> } else {
>>>> return null;
>>>> }
>>>> }
>>>>
>>>> public Class<?> loadClass(String className, String bundleName) throws
>>>> ClassNotFoundException {
>>>> Bundle[] bundles = pkgAdmin.getBundles(bundleName, null);
>>>> if (bundles == null || bundles.length == 0) {
>>>> return null;
>>>> }
>>>> return bundles[0].loadClass(className);
>>>> }
>>>>
>>>> When serializing the object, you can use getBundleName to get the name of
>>>> the bundle which "owns" the class being serialized. This name needs to be
>>>> included in the xml data you store. Then on deserialization, loadClass
>>>> looks up the bundle by the name specified, then uses that bundle to load
the
>>>> class.
>>>>
>>>> This code assumes that there will be only one version of the bundle with
>>>> a given name present, but it would be fairly straightforward to extend this
>>>> to look at bundle versions if needed...
>>>>
>>>> HTH...
>>>>
>>>> Kris
>>>>
>>>> On Dec 1, 2009, at 10:44 AM, Ziegenlippe wrote:
>>>>
>>>> Hello,
>>>>
>>>>> I cannot find a satisfying solution to a simple looking problem for
>>>>> quite a while.
>>>>>
>>>>> The condensation of the problem:
>>>>> Bundle A
>>>>> the producer stores objects as xml files (e.g. with XStream)
>>>>> it exports the /bundle.a/ package which contains the interface /Item/
>>>>> it contains a private implementation package /bundle.a.impl/ which contains
>>>>> the item implementation class /ItemImpl/
>>>>>
>>>>> Bundle B
>>>>> the consumer needs to load and process /Item/ instances
>>>>> therefor it imports package /bundle.a/ which contains the /Item/
>>>>> interface
>>>>>
>>>>> Problem: loading Item instances in bundle B leads always to
>>>>> ClassNotFoundExceptions
>>>>>
>>>>> Even working with the last resort /DynamicImport-Package: * / does not
>>>>> solve the problem since it imports only exported packages.
>>>>>
>>>>> From some hints in the internet I got the feeling that this issue is
not
>>>>> really solved for OSGI. Is there any solution known? How deal others
with
>>>>> that issue e.g. ActiveMq which claims to be OSGI compliant.
>>>>> Or am I just on the wrong way?
>>>>>
>>>>> Thank you in advance,
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Hi,
I am a newbe to felix and have been using java web start for years. I found out via the OSGi
forum that the framework is not meant for inital deployment and recommended staying with web
start for that functionality.
I am looking for a complete intial deployment and update solution. Does Felix also provide
the missing piece? My goal is deploy like a regular app and update using OSGi if possible.
Any suggestions?
Thanks,
-Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Hi,
On 02.12.2009, at 17:08, Sebastian Heib wrote:
> Hi,
>
> I have an iPojo component that asks the user for some input data. This data is then provided
as a service for other bundles. So far - no problem. But I only want to provide the data for
other components, AFTER the user entered something (so as soon as there is actually data available),
and not while the user is still entering data (as the provided data would be empty in this
case).
>
> But as my component must be valid for the user to enter something, the service is also
immediately available. This results in the consuming component to get valid as well, but without
the actual data (this is NOT what I want, I want the consuming component to get valid as soon
as there is real data available). I tried to write a handler for this case that checks if
the user input data is actually valid. Is this the way to go? Or is there an easier way? How
can I re-check the provided service within my handler (currently I check it once in the 'start'
method, but how to I know if something changed on the service side?)?
There is several way to do that.
- Doing a handler will work obviously, but this is really dependent to your case.
- Using the lifecycle controller (@Controller) which allow you to invalid your instance until
the configuration (here the user input) is correct
- Having an instance taking the user input and when it's done, creating another instance (which
provides the service) with the user entry as parameter (i.e. configuration). Something like:
@Requires(filter="factory.name=my.second.component")
Factory myFactory;
public void receiveUserInput(String input) {
Properties conf = new Properties();
conf.put("user.input", input);
try {
myFactory.createComponentInstance(conf);
} catch (UnacceptableConfiguration e) {
e.printStackTrace();
} catch (MissingHandlerException e) {
e.printStackTrace();
} catch (ConfigurationException e) {
e.printStackTrace();
}
}
Regards,
Clement
>
> Thanks,
> Sebastian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
I'm not quite sure what you're trying to accomplish in that way... If the references are not necessary when deserializing, make them transient. If they are necessary, there's something peculiar about your design; is it really necessary that they are implementations of some interface because they're used as services, or are they actually just value objects? Angelo On Wed, Dec 2, 2009 at 10:49 AM, andrea ziege <ziegenlippe@googlemail.com>wrote: > This is ok I do it the same way: > XStream stream=new XStream(); > stream.setClassLoader(Activator.class.getClassLoader()); > > My problem was that the class I serialize contains references to interfaces > which are visible from my bundle. But the implementation classes are > invisible. This isn't a problem for serialization but for deserialization. > So even DynamicImport doesn't work. So I would need to make the impl > classes > public visible. Which I'm not able in all cases and what is in my opinion a > dirty fix. > Bye, > Andy > > 2009/12/2 Angelo vd Sijpt <angelovds@gmail.com> > > > Maybe I'm going down the wrong path here, but if your bundle B uses > XStream > > too, you can make use of that. > > XStream will by default use (I believe) the system classloader, and not > the > > classloader of bundle B. You can make it use the correct one by passing > > your > > own classloader: > > > > new XStream(null, new XppDriver(), BundleBClass.class.getClassLoader()); > > > > You should make sure BundleBClass is some class that is loaded by the > > classloader of bundle B, since that has access to the imported classes > from > > bundle A. > > > > Angelo > > > > On Tue, Dec 1, 2009 at 7:44 PM, Ziegenlippe <ziegenlippe@googlemail.com > > >wrote: > > > > > Hello, > > > > > > I cannot find a satisfying solution to a simple looking problem for > quite > > a > > > while. > > > > > > The condensation of the problem: > > > Bundle A > > > the producer stores objects as xml files (e.g. with XStream) > > > it exports the /bundle.a/ package which contains the interface /Item/ > > it > > > contains a private implementation package /bundle.a.impl/ which > contains > > the > > > item implementation class /ItemImpl/ > > > > > > Bundle B > > > the consumer needs to load and process /Item/ instances > > > therefor it imports package /bundle.a/ which contains the /Item/ > > interface > > > > > > Problem: loading Item instances in bundle B leads always to > > > ClassNotFoundExceptions > > > > > > Even working with the last resort /DynamicImport-Package: * / does not > > > solve the problem since it imports only exported packages. > > > > > > From some hints in the internet I got the feeling that this issue is > not > > > really solved for OSGI. Is there any solution known? How deal others > with > > > that issue e.g. ActiveMq which claims to be OSGI compliant. > > > Or am I just on the wrong way? > > > > > > Thank you in advance, > > > Andy > > > > > > > > >
Hi, I have an iPojo component that asks the user for some input data. This data is then provided as a service for other bundles. So far - no problem. But I only want to provide the data for other components, AFTER the user entered something (so as soon as there is actually data available), and not while the user is still entering data (as the provided data would be empty in this case). But as my component must be valid for the user to enter something, the service is also immediately available. This results in the consuming component to get valid as well, but without the actual data (this is NOT what I want, I want the consuming component to get valid as soon as there is real data available). I tried to write a handler for this case that checks if the user input data is actually valid. Is this the way to go? Or is there an easier way? How can I re-check the provided service within my handler (currently I check it once in the 'start' method, but how to I know if something changed on the service side?)? Thanks, Sebastian --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
On Wed, Dec 2, 2009 at 2:48 PM, Richard S. Hall <heavy@ungoverned.org> wrote: > Is RAT still incubating? If so, we will probably stay on the other release > until then. There is a stable release from apache: http://repo1.maven.org/maven2/org/apache/rat/apache-rat-plugin/0.6/ We don't need to change unless it's been broken or we need feature from newer release. > In the meantime, I explicitly mention the version, so it should work now. Thanks for the quick fix. -Guo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
Is RAT still incubating? If so, we will probably stay on the other release until then. In the meantime, I explicitly mention the version, so it should work now. -> richard On 12/2/09 5:12, Guo Du wrote: > On Tue, Dec 1, 2009 at 6:54 PM, Guo Du<mrduguo@gmail.com> wrote: > >> The 1.0-alpha-3 is latest version of rat-maven-plugin which resolved >> automatically. IN Nick's case, it was resolved to >> 1.0-alpha-4-SNAPSHOT. >> > We probably should always use fixed artifact version for > plugin/dependencies instead of automatically resolve. Nick's problem > won't happen if we have fixed version associated with rat plugin. The > auto resolve are the main source to make maven build unreliable. We > may make sure current latest version works on our trunk code base, but > no confidence to tell it still works for next coming version. > > This practice was used in jackrabbit project as well: > http://svn.apache.org/repos/asf/jackrabbit/parent/trunk/pom.xml > > Just a suggestion, it will take time to do it :) > > -Guo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
On Tue, Dec 1, 2009 at 6:54 PM, Guo Du <mrduguo@gmail.com> wrote: > The 1.0-alpha-3 is latest version of rat-maven-plugin which resolved > automatically. IN Nick's case, it was resolved to > 1.0-alpha-4-SNAPSHOT. We probably should always use fixed artifact version for plugin/dependencies instead of automatically resolve. Nick's problem won't happen if we have fixed version associated with rat plugin. The auto resolve are the main source to make maven build unreliable. We may make sure current latest version works on our trunk code base, but no confidence to tell it still works for next coming version. This practice was used in jackrabbit project as well: http://svn.apache.org/repos/asf/jackrabbit/parent/trunk/pom.xml Just a suggestion, it will take time to do it :) -Guo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org
This is ok I do it the same way:
XStream stream=new XStream();
stream.setClassLoader(Activator.class.getClassLoader());
My problem was that the class I serialize contains references to interfaces
which are visible from my bundle. But the implementation classes are
invisible. This isn't a problem for serialization but for deserialization.
So even DynamicImport doesn't work. So I would need to make the impl classes
public visible. Which I'm not able in all cases and what is in my opinion a
dirty fix.
Bye,
Andy
2009/12/2 Angelo vd Sijpt <angelovds@gmail.com>
> Maybe I'm going down the wrong path here, but if your bundle B uses XStream
> too, you can make use of that.
> XStream will by default use (I believe) the system classloader, and not the
> classloader of bundle B. You can make it use the correct one by passing
> your
> own classloader:
>
> new XStream(null, new XppDriver(), BundleBClass.class.getClassLoader());
>
> You should make sure BundleBClass is some class that is loaded by the
> classloader of bundle B, since that has access to the imported classes from
> bundle A.
>
> Angelo
>
> On Tue, Dec 1, 2009 at 7:44 PM, Ziegenlippe <ziegenlippe@googlemail.com
> >wrote:
>
> > Hello,
> >
> > I cannot find a satisfying solution to a simple looking problem for quite
> a
> > while.
> >
> > The condensation of the problem:
> > Bundle A
> > the producer stores objects as xml files (e.g. with XStream)
> > it exports the /bundle.a/ package which contains the interface /Item/
> it
> > contains a private implementation package /bundle.a.impl/ which contains
> the
> > item implementation class /ItemImpl/
> >
> > Bundle B
> > the consumer needs to load and process /Item/ instances
> > therefor it imports package /bundle.a/ which contains the /Item/
> interface
> >
> > Problem: loading Item instances in bundle B leads always to
> > ClassNotFoundExceptions
> >
> > Even working with the last resort /DynamicImport-Package: * / does not
> > solve the problem since it imports only exported packages.
> >
> > From some hints in the internet I got the feeling that this issue is not
> > really solved for OSGI. Is there any solution known? How deal others with
> > that issue e.g. ActiveMq which claims to be OSGI compliant.
> > Or am I just on the wrong way?
> >
> > Thank you in advance,
> > Andy
> >
> >
>
The Hazelcast solution is quite ok and not to much effort. I like it.
Do the guys from Hazelcast know about it? They have an issue exactly for
that problem (http://code.google.com/p/hazelcast/issues/detail?id=161).
Thank you Kris.
Bye,
Andy
2009/12/1 Kris Pruden <kpruden@gmail.com>
> On Dec 1, 2009, at 11:16 AM, Ziegenlippe wrote:
>
> Nice. Does this mean I have to take care about serialization by my own? I
>> use great libs XStream and Hazelcast. Both of them are doing a good
>> serialization job. But I see without bundle-id+version there is no way.
>> Thanks for the answer,
>>
>
> Not necessarily. Some libraries support the injection of custom hooks at
> various stages of the serialization/deserialization process.
>
> As an example, I was able to create OSGi-aware versions of
> Object{Output,Input}Stream by overriding the annotateClass() and
> resolveClass() methods, respectively.
>
> I'm not familiar with XStream, but it wouldn't surprise me if it offered
> some way to influence the class loading process..
>
> As for Hazelcast, I actually went down that path and got it to work by
> registering custom serializers which used the OSGi-aware object streams I
> talked about above.
>
> Here's the activator I used:
>
> package com.hazelcast.osgi;
>
> import org.osgi.framework.BundleActivator;
> import org.osgi.framework.BundleContext;
> import org.osgi.framework.ServiceReference;
> import org.osgi.service.packageadmin.PackageAdmin;
>
> import com.hazelcast.core.Hazelcast;
> import com.hazelcast.nio.Serializer;
>
> public class Activator implements BundleActivator {
> public void start(BundleContext context) throws Exception {
> ServiceReference ref =
> context.getServiceReference(PackageAdmin.class.getName());
> PackageAdmin pkgAdmin = (PackageAdmin) context.getService(ref);
> Serializer.registerTypeSerializer(new OsgiObjectSerializer());
> Serializer.registerTypeSerializer(new OsgiDataSerializer(pkgAdmin));
> }
>
> public void stop(BundleContext context) throws Exception {
> Serializer.registerTypeSerializer(new
> Serializer.ObjectSerializer());
> Serializer.registerTypeSerializer(new Serializer.DataSerializer());
> Hazelcast.shutdown();
> }
> }
>
> The implementations of OsgiObjectSerializer and OsgiDataSerializer are
> pretty similar to the versions that come with Hazelcast; they simply inject
> a bundle name into the stream during serialization, and during
> deserialization use that name to lookup the bundle to use to load the
> class..
>
> Kris
>
>
> Andy
>>
>>
>> Kris Pruden schrieb:
>>
>>> I had a similar problem. The solution boils down to delegating to the
>>> "owning" bundle to load the class. To do this you need of course to know
>>> the name of the bundle. In my case I was able to solve this problem with a
>>> couple helper methods that wrap the PackageAdmin service provided by OSGi:
>>>
>>> public String getBundleName(Class<?> cls) {
>>> Bundle bundle = pkgAdmin.getBundle(cls);
>>> if (bundle != null) {
>>> return bundle.getSymbolicName();
>>> } else {
>>> return null;
>>> }
>>> }
>>>
>>> public Class<?> loadClass(String className, String bundleName) throws
>>> ClassNotFoundException {
>>> Bundle[] bundles = pkgAdmin.getBundles(bundleName, null);
>>> if (bundles == null || bundles.length == 0) {
>>> return null;
>>> }
>>> return bundles[0].loadClass(className);
>>> }
>>>
>>> When serializing the object, you can use getBundleName to get the name of
>>> the bundle which "owns" the class being serialized. This name needs to be
>>> included in the xml data you store. Then on deserialization, loadClass
>>> looks up the bundle by the name specified, then uses that bundle to load the
>>> class.
>>>
>>> This code assumes that there will be only one version of the bundle with
>>> a given name present, but it would be fairly straightforward to extend this
>>> to look at bundle versions if needed...
>>>
>>> HTH...
>>>
>>> Kris
>>>
>>> On Dec 1, 2009, at 10:44 AM, Ziegenlippe wrote:
>>>
>>> Hello,
>>>>
>>>> I cannot find a satisfying solution to a simple looking problem for
>>>> quite a while.
>>>>
>>>> The condensation of the problem:
>>>> Bundle A
>>>> the producer stores objects as xml files (e.g. with XStream)
>>>> it exports the /bundle.a/ package which contains the interface /Item/
>>>> it contains a private implementation package /bundle.a.impl/ which contains
>>>> the item implementation class /ItemImpl/
>>>>
>>>> Bundle B
>>>> the consumer needs to load and process /Item/ instances
>>>> therefor it imports package /bundle.a/ which contains the /Item/
>>>> interface
>>>>
>>>> Problem: loading Item instances in bundle B leads always to
>>>> ClassNotFoundExceptions
>>>>
>>>> Even working with the last resort /DynamicImport-Package: * / does not
>>>> solve the problem since it imports only exported packages.
>>>>
>>>> From some hints in the internet I got the feeling that this issue is not
>>>> really solved for OSGI. Is there any solution known? How deal others with
>>>> that issue e.g. ActiveMq which claims to be OSGI compliant.
>>>> Or am I just on the wrong way?
>>>>
>>>> Thank you in advance,
>>>> Andy
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Maybe I'm going down the wrong path here, but if your bundle B uses XStream too, you can make use of that. XStream will by default use (I believe) the system classloader, and not the classloader of bundle B. You can make it use the correct one by passing your own classloader: new XStream(null, new XppDriver(), BundleBClass.class.getClassLoader()); You should make sure BundleBClass is some class that is loaded by the classloader of bundle B, since that has access to the imported classes from bundle A. Angelo On Tue, Dec 1, 2009 at 7:44 PM, Ziegenlippe <ziegenlippe@googlemail.com>wrote: > Hello, > > I cannot find a satisfying solution to a simple looking problem for quite a > while. > > The condensation of the problem: > Bundle A > the producer stores objects as xml files (e.g. with XStream) > it exports the /bundle.a/ package which contains the interface /Item/ it > contains a private implementation package /bundle.a.impl/ which contains the > item implementation class /ItemImpl/ > > Bundle B > the consumer needs to load and process /Item/ instances > therefor it imports package /bundle.a/ which contains the /Item/ interface > > Problem: loading Item instances in bundle B leads always to > ClassNotFoundExceptions > > Even working with the last resort /DynamicImport-Package: * / does not > solve the problem since it imports only exported packages. > > From some hints in the internet I got the feeling that this issue is not > really solved for OSGI. Is there any solution known? How deal others with > that issue e.g. ActiveMq which claims to be OSGI compliant. > Or am I just on the wrong way? > > Thank you in advance, > Andy > >
On Dec 1, 2009, at 1:16 PM, Mike Haney wrote:
> Kris - that's an interesting solution. I'm not familiar enough with
> the
> inner workings of serialization, but I wonder if it would be
> possible to do
> this on a global level and package it into a bundle to provide this
> support
> across the entire OSGi runtime? That would be a decent partial
> solution to
> the problem. It still doesn't help the problem with bundles
> dynamically
> coming and going, but should be sufficient for many use cases, for
> example
> storing data to the HTTP session between request (a la Wicket).
I thought about that, but in the Object{Input,Ouput}Stream cases at
least, for this solution to work you must use a different class. In
other words, You must explicitly use OsgiObjectOutputStream and its
counterpart for this to work. I haven't figured out a way to make the
included-with-java versions to work. I suppose one could resort to a
boot agent that simply replaces the implementations of these classes
with OSGi-aware versions might work.
I think the more general case is harder. Any logic that explicitly
loads classes (as all serialization mechanisms must ultimately do)
pretty much has to be OSGi-aware, or support the injection of OSGi-
aware hooks. Luckily, most well-designed libraries seem to support
this (interestingly, the java.io object streams are *not* well-
designed in this regard). So, while it may never be possible to
provide a library-independent solution to this problem, it should be
possible with some work to make a given library work with OSGi in such
a way that at least the clients of that library don't need to do any
extra work.
Hopefully as OSGi catches on more of these libraries will natively
support it...
Kris
> On Tue, Dec 1, 2009 at 3:11 PM, Kris Pruden <kpruden@gmail.com> wrote:
>
>> On Dec 1, 2009, at 11:16 AM, Ziegenlippe wrote:
>>
>> Nice. Does this mean I have to take care about serialization by my
>> own? I
>>> use great libs XStream and Hazelcast. Both of them are doing a good
>>> serialization job. But I see without bundle-id+version there is no
>>> way.
>>> Thanks for the answer,
>>>
>>
>> Not necessarily. Some libraries support the injection of custom
>> hooks at
>> various stages of the serialization/deserialization process.
>>
>> As an example, I was able to create OSGi-aware versions of
>> Object{Output,Input}Stream by overriding the annotateClass() and
>> resolveClass() methods, respectively.
>>
>> I'm not familiar with XStream, but it wouldn't surprise me if it
>> offered
>> some way to influence the class loading process..
>>
>> As for Hazelcast, I actually went down that path and got it to work
>> by
>> registering custom serializers which used the OSGi-aware object
>> streams I
>> talked about above.
>>
>> Here's the activator I used:
>>
>> package com.hazelcast.osgi;
>>
>> import org.osgi.framework.BundleActivator;
>> import org.osgi.framework.BundleContext;
>> import org.osgi.framework.ServiceReference;
>> import org.osgi.service.packageadmin.PackageAdmin;
>>
>> import com.hazelcast.core.Hazelcast;
>> import com.hazelcast.nio.Serializer;
>>
>> public class Activator implements BundleActivator {
>> public void start(BundleContext context) throws Exception {
>> ServiceReference ref =
>> context.getServiceReference(PackageAdmin.class.getName());
>> PackageAdmin pkgAdmin = (PackageAdmin) context.getService(ref);
>> Serializer.registerTypeSerializer(new OsgiObjectSerializer());
>> Serializer.registerTypeSerializer(new
>> OsgiDataSerializer(pkgAdmin));
>> }
>>
>> public void stop(BundleContext context) throws Exception {
>> Serializer.registerTypeSerializer(new
>> Serializer.ObjectSerializer());
>> Serializer.registerTypeSerializer(new
>> Serializer.DataSerializer());
>> Hazelcast.shutdown();
>> }
>> }
>>
>> The implementations of OsgiObjectSerializer and OsgiDataSerializer
>> are
>> pretty similar to the versions that come with Hazelcast; they
>> simply inject
>> a bundle name into the stream during serialization, and during
>> deserialization use that name to lookup the bundle to use to load the
>> class..
>>
>> Kris
>>
>>
>> Andy
>>>
>>>
>>> Kris Pruden schrieb:
>>>
>>>> I had a similar problem. The solution boils down to delegating
>>>> to the
>>>> "owning" bundle to load the class. To do this you need of course
>>>> to know
>>>> the name of the bundle. In my case I was able to solve this
>>>> problem with a
>>>> couple helper methods that wrap the PackageAdmin service provided
>>>> by OSGi:
>>>>
>>>> public String getBundleName(Class<?> cls) {
>>>> Bundle bundle = pkgAdmin.getBundle(cls);
>>>> if (bundle != null) {
>>>> return bundle.getSymbolicName();
>>>> } else {
>>>> return null;
>>>> }
>>>> }
>>>>
>>>> public Class<?> loadClass(String className, String bundleName)
>>>> throws
>>>> ClassNotFoundException {
>>>> Bundle[] bundles = pkgAdmin.getBundles(bundleName, null);
>>>> if (bundles == null || bundles.length == 0) {
>>>> return null;
>>>> }
>>>> return bundles[0].loadClass(className);
>>>> }
>>>>
>>>> When serializing the object, you can use getBundleName to get the
>>>> name of
>>>> the bundle which "owns" the class being serialized. This name
>>>> needs to be
>>>> included in the xml data you store. Then on deserialization,
>>>> loadClass
>>>> looks up the bundle by the name specified, then uses that bundle
>>>> to load the
>>>> class.
>>>>
>>>> This code assumes that there will be only one version of the
>>>> bundle with
>>>> a given name present, but it would be fairly straightforward to
>>>> extend this
>>>> to look at bundle versions if needed...
>>>>
>>>> HTH...
>>>>
>>>> Kris
>>>>
>>>> On Dec 1, 2009, at 10:44 AM, Ziegenlippe wrote:
>>>>
>>>> Hello,
>>>>>
>>>>> I cannot find a satisfying solution to a simple looking problem
>>>>> for
>>>>> quite a while.
>>>>>
>>>>> The condensation of the problem:
>>>>> Bundle A
>>>>> the producer stores objects as xml files (e.g. with XStream)
>>>>> it exports the /bundle.a/ package which contains the interface /
>>>>> Item/
>>>>> it contains a private implementation package /bundle.a.impl/
>>>>> which contains
>>>>> the item implementation class /ItemImpl/
>>>>>
>>>>> Bundle B
>>>>> the consumer needs to load and process /Item/ instances
>>>>> therefor it imports package /bundle.a/ which contains the /Item/
>>>>> interface
>>>>>
>>>>> Problem: loading Item instances in bundle B leads always to
>>>>> ClassNotFoundExceptions
>>>>>
>>>>> Even working with the last resort /DynamicImport-Package: * /
>>>>> does not
>>>>> solve the problem since it imports only exported packages.
>>>>>
>>>>> From some hints in the internet I got the feeling that this
>>>>> issue is not
>>>>> really solved for OSGI. Is there any solution known? How deal
>>>>> others with
>>>>> that issue e.g. ActiveMq which claims to be OSGI compliant.
>>>>> Or am I just on the wrong way?
>>>>>
>>>>> Thank you in advance,
>>>>> Andy
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Kris - that's an interesting solution. I'm not familiar enough with the
inner workings of serialization, but I wonder if it would be possible to do
this on a global level and package it into a bundle to provide this support
across the entire OSGi runtime? That would be a decent partial solution to
the problem. It still doesn't help the problem with bundles dynamically
coming and going, but should be sufficient for many use cases, for example
storing data to the HTTP session between request (a la Wicket).
On Tue, Dec 1, 2009 at 3:11 PM, Kris Pruden <kpruden@gmail.com> wrote:
> On Dec 1, 2009, at 11:16 AM, Ziegenlippe wrote:
>
> Nice. Does this mean I have to take care about serialization by my own? I
>> use great libs XStream and Hazelcast. Both of them are doing a good
>> serialization job. But I see without bundle-id+version there is no way.
>> Thanks for the answer,
>>
>
> Not necessarily. Some libraries support the injection of custom hooks at
> various stages of the serialization/deserialization process.
>
> As an example, I was able to create OSGi-aware versions of
> Object{Output,Input}Stream by overriding the annotateClass() and
> resolveClass() methods, respectively.
>
> I'm not familiar with XStream, but it wouldn't surprise me if it offered
> some way to influence the class loading process..
>
> As for Hazelcast, I actually went down that path and got it to work by
> registering custom serializers which used the OSGi-aware object streams I
> talked about above.
>
> Here's the activator I used:
>
> package com.hazelcast.osgi;
>
> import org.osgi.framework.BundleActivator;
> import org.osgi.framework.BundleContext;
> import org.osgi.framework.ServiceReference;
> import org.osgi.service.packageadmin.PackageAdmin;
>
> import com.hazelcast.core.Hazelcast;
> import com.hazelcast.nio.Serializer;
>
> public class Activator implements BundleActivator {
> public void start(BundleContext context) throws Exception {
> ServiceReference ref =
> context.getServiceReference(PackageAdmin.class.getName());
> PackageAdmin pkgAdmin = (PackageAdmin) context.getService(ref);
> Serializer.registerTypeSerializer(new OsgiObjectSerializer());
> Serializer.registerTypeSerializer(new OsgiDataSerializer(pkgAdmin));
> }
>
> public void stop(BundleContext context) throws Exception {
> Serializer.registerTypeSerializer(new
> Serializer.ObjectSerializer());
> Serializer.registerTypeSerializer(new Serializer.DataSerializer());
> Hazelcast.shutdown();
> }
> }
>
> The implementations of OsgiObjectSerializer and OsgiDataSerializer are
> pretty similar to the versions that come with Hazelcast; they simply inject
> a bundle name into the stream during serialization, and during
> deserialization use that name to lookup the bundle to use to load the
> class..
>
> Kris
>
>
> Andy
>>
>>
>> Kris Pruden schrieb:
>>
>>> I had a similar problem. The solution boils down to delegating to the
>>> "owning" bundle to load the class. To do this you need of course to know
>>> the name of the bundle. In my case I was able to solve this problem with a
>>> couple helper methods that wrap the PackageAdmin service provided by OSGi:
>>>
>>> public String getBundleName(Class<?> cls) {
>>> Bundle bundle = pkgAdmin.getBundle(cls);
>>> if (bundle != null) {
>>> return bundle.getSymbolicName();
>>> } else {
>>> return null;
>>> }
>>> }
>>>
>>> public Class<?> loadClass(String className, String bundleName) throws
>>> ClassNotFoundException {
>>> Bundle[] bundles = pkgAdmin.getBundles(bundleName, null);
>>> if (bundles == null || bundles.length == 0) {
>>> return null;
>>> }
>>> return bundles[0].loadClass(className);
>>> }
>>>
>>> When serializing the object, you can use getBundleName to get the name of
>>> the bundle which "owns" the class being serialized. This name needs to be
>>> included in the xml data you store. Then on deserialization, loadClass
>>> looks up the bundle by the name specified, then uses that bundle to load the
>>> class.
>>>
>>> This code assumes that there will be only one version of the bundle with
>>> a given name present, but it would be fairly straightforward to extend this
>>> to look at bundle versions if needed...
>>>
>>> HTH...
>>>
>>> Kris
>>>
>>> On Dec 1, 2009, at 10:44 AM, Ziegenlippe wrote:
>>>
>>> Hello,
>>>>
>>>> I cannot find a satisfying solution to a simple looking problem for
>>>> quite a while.
>>>>
>>>> The condensation of the problem:
>>>> Bundle A
>>>> the producer stores objects as xml files (e.g. with XStream)
>>>> it exports the /bundle.a/ package which contains the interface /Item/
>>>> it contains a private implementation package /bundle.a.impl/ which contains
>>>> the item implementation class /ItemImpl/
>>>>
>>>> Bundle B
>>>> the consumer needs to load and process /Item/ instances
>>>> therefor it imports package /bundle.a/ which contains the /Item/
>>>> interface
>>>>
>>>> Problem: loading Item instances in bundle B leads always to
>>>> ClassNotFoundExceptions
>>>>
>>>> Even working with the last resort /DynamicImport-Package: * / does not
>>>> solve the problem since it imports only exported packages.
>>>>
>>>> From some hints in the internet I got the feeling that this issue is not
>>>> really solved for OSGI. Is there any solution known? How deal others with
>>>> that issue e.g. ActiveMq which claims to be OSGI compliant.
>>>> Or am I just on the wrong way?
>>>>
>>>> Thank you in advance,
>>>> Andy
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>