slf4j Osgi Load Issues
|
View:
New views
17 Messages
—
Rating Filter:
Alert me
|
 |
slf4j Osgi Load Issues
by Roger Kitain
::
Rate this Message:
One of the changes that Weld had done (recently) is move away from
commons logging to slf4j. We may now need to add slf4j osgi bundles in GlassFish V3 . These bundles are available at: http://repo2.maven.org/maven2/org/slf4j/slf4j-api/ http://repo2.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.9-RC0/ I did try to install these bundles under glassfish/modules, but it barfed with the following error: WARNING: Failed to install file:/Users/rogerk/V3/glassfishv3/glassfish/modules/slf4j-api-1.5.9-RC0.jar org.osgi.framework.BundleException: Could not create bundle object. at org.apache.felix.framework.Felix.installBundle(Felix.java:2434) at org.apache.felix.framework.Felix.installBundle(Felix.java:2277) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130) at org.jvnet.hk2.osgimain.Main.install(Main.java:334) at org.jvnet.hk2.osgimain.Main.traverse(Main.java:268) at org.jvnet.hk2.osgimain.Main.start(Main.java:127) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NumberFormatException: For input string: "9-RC0" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:456) at java.lang.Integer.parseInt(Integer.java:497) at org.osgi.framework.Version.<init>(Version.java:133) at org.osgi.framework.Version.parseVersion(Version.java:218) at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:77) at org.apache.felix.framework.ModuleImpl.<init>(ModuleImpl.java:203) at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1115) at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:79) at org.apache.felix.framework.Felix.installBundle(Felix.java:2372) ... 11 more The MANIFEST information for the api bundle is: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_05 Bundle-Description: The slf4j API Bundle-Version: 1.5.9-RC0 Implementation-Version: 1.5.9-RC0 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.5.9-RC0, org.slf4j.spi;version=1.5 .9-RC0, org.slf4j.helpers;version=1.5.9-RC0 Import-Package: org.slf4j.impl;version=1.5.9-RC0 Is 1.5.9-RC0 an invalid version in the eyes of felix osgi? -roger --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j Osgi Load Issues
by Richard S. Hall
::
Rate this Message:
On 10/28/09 12:21, Roger Kitain wrote:
> One of the changes that Weld had done (recently) is move away from > commons logging to slf4j. > We may now need to add slf4j osgi bundles in GlassFish V3 . > These bundles are available at: > http://repo2.maven.org/maven2/org/slf4j/slf4j-api/ > http://repo2.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.9-RC0/ > > I did try to install these bundles under glassfish/modules, but it > barfed with the following error: > > WARNING: Failed to install > file:/Users/rogerk/V3/glassfishv3/glassfish/modules/slf4j-api-1.5.9-RC0.jar > > org.osgi.framework.BundleException: Could not create bundle object. > at org.apache.felix.framework.Felix.installBundle(Felix.java:2434) > at org.apache.felix.framework.Felix.installBundle(Felix.java:2277) > at > org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130) > > at org.jvnet.hk2.osgimain.Main.install(Main.java:334) > at org.jvnet.hk2.osgimain.Main.traverse(Main.java:268) > at org.jvnet.hk2.osgimain.Main.start(Main.java:127) > at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) > > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:637) > Caused by: java.lang.NumberFormatException: For input string: "9-RC0" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) > > at java.lang.Integer.parseInt(Integer.java:456) > at java.lang.Integer.parseInt(Integer.java:497) > at org.osgi.framework.Version.<init>(Version.java:133) > at org.osgi.framework.Version.parseVersion(Version.java:218) > at > org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:77) > > at org.apache.felix.framework.ModuleImpl.<init>(ModuleImpl.java:203) > at > org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1115) > at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:79) > at org.apache.felix.framework.Felix.installBundle(Felix.java:2372) > ... 11 more > > The MANIFEST information for the api bundle is: > > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: ceki > Build-Jdk: 1.6.0_05 > Bundle-Description: The slf4j API > Bundle-Version: 1.5.9-RC0 > Implementation-Version: 1.5.9-RC0 > Implementation-Title: slf4j-api > Bundle-ManifestVersion: 2 > Bundle-SymbolicName: slf4j.api > Bundle-Name: slf4j-api > Bundle-Vendor: SLF4J.ORG > Bundle-RequiredExecutionEnvironment: J2SE-1.3 > Export-Package: org.slf4j;version=1.5.9-RC0, org.slf4j.spi;version=1.5 > .9-RC0, org.slf4j.helpers;version=1.5.9-RC0 > Import-Package: org.slf4j.impl;version=1.5.9-RC0 > > Is 1.5.9-RC0 an invalid version in the eyes of felix osgi? Yes. It should be 1.5.9.RC0... -> richard > > -roger > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: slf4j Osgi Load Issues
by Roger Kitain
::
Rate this Message:
1.5.9.RC0
Ed Burns wrote: >>>>>> On Wed, 28 Oct 2009 12:42:43 -0400, "Richard S. Hall" <heavy@...> said: >>>>>> > > RH> On 10/28/09 12:21, Roger Kitain wrote: > RK> One of the changes that Weld had done (recently) is move away from > RK> commons logging to slf4j. > RK> We may now need to add slf4j osgi bundles in GlassFish V3 . > RK> These bundles are available at: > RK> http://repo2.maven.org/maven2/org/slf4j/slf4j-api/ > RK> http://repo2.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.9-RC0/ > RK> > RK> I did try to install these bundles under glassfish/modules, but it > RK> barfed with the following error: > > RK> Is 1.5.9-RC0 an invalid version in the eyes of felix osgi? > > RH> Yes. It should be 1.5.9.RC0... > > Ok, now I already have source build working for slf4j because Bean > Validator depends on it, HOWEVER, the slf4j artifacts are manually > included into the bean-validator.jar OSGi module. > > If we have another top level module that depends on slf4j, it makes > sense for both of those modules to depend on the source level one > and make it a separate jar. > > Roger, can you please reply to this mail and tell me the exact slf4j-api > and slf4j-jdk14 versions weld requires? > > Ed > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: slf4j as Glassfish OSGi module
by Jane Young-Lau
::
Rate this Message:
I'm fine with this approach in creating one bundle containing all the slf4j artifacts. So, this is what's going to happen: 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM [1] 2. Use the same steps from JBoss' in building the artifacts producing the same maven coordinates in the local Maven repository 3. Create a pom.xml in [1]/slf4j/1.5.9.RC1/slf4j-all that references the artifacts from step 2 to create one slf4j-all bundle. Name this artifact slf4j-all with the version 1.5.9.RC1 and the groupId: org.glassfish.external 4. We will publish the one slf4j bundle to our maven repository 5. Provide a README describing the build. This should include steps like checking out a particular version from external repo, setting env and then issuing some commands. Jerome/Sahoo, let us know if you're okay with this approach. Ed, so BV will have a dependency on slf4j artifact and downloaded to v3 workspace from hk2? Does Snjezana need to add this artifact in the packager module or will this be added via transitive dependency? Thanks, Jane Ed Burns wrote: On Thu, 29 Oct 2009 12:09:03 -0400, Roger Kitain Roger.Kitain@... said:RK> However, it looks like weld will be using the following related artifacts: RK> http://repository.jboss.org/maven2//org/slf4j/slf4j-ext/1.5.9.RC1/ RK> http://repository.jboss.org/maven2//org/slf4j/slf4j-api/1.5.9.RC1/ RK> http://repository.jboss.org/maven2//org/slf4j/slf4j-jdk14/1.5.9.RC1/ RK> http://repository.jboss.org/maven2//ch/qos/cal10n/cal10n-api/0.7.2/ Here is what I suggest we do. Currently in the SVN repo at [1] we have directories for slf4j-api and slf4j-jdk14. Within each of these directories is the "source build" code for those modules. My build system for the bean-validator module, also at [1], traverses into those slf4j directories, builds their jars, and includes them in the final bean-validator.jar OSGi module. This was done to reduce the number of jars we have in the modules directory. Now that Weld also depends on slf4j, it makes sense to have a separate top-level OSGi module for slf4j. Here is my proposal to make this happen. * make a new directory at [1]/slf4j. * Move the existing slf4j-api and slf4j-jdk14 directories under there * make a new directory [1]/slf4j/slf4j-ext * Use an approach similar to what I do with bean-validator that bundles slf4j-api, slf4j-jdk14 and slf4j-ext into a single glassfish OSGi module slf4j.jar. * Once this slf4j.jar module is working and published to the java.net maven2 repo, we can make bean-validator and Weld depend on it. ACTION: Jerome, Jane, Roger please give you opinion on this plan. Is there a better way? Thanks, Ed [1] https://svn.dev.java.net/glassfish-svn/trunk/external/modules |
|
|
|
|
|
Re: slf4j as Glassfish OSGi module
by Sahoo
::
Rate this Message:
Jane,
I agree with those steps except #3. Can we have this *slf4j-all* module outside of slf4j/1.5.9.RC1. e.g., v3/glassfish/packager/external or something like that, so that a) We don't have to create it every time we add new version of slf4j in our scm. b) We don't mix an artifact with groupId org.glassfish with that of the external project. I also think org.glassfish.external is *not* an appropriate groupId. org.glassfish is more appropriate. Any additional qualifier should be part of artifactId; the group name should remain same for all artifacts produced by this team. Thanks, Sahoo Jane Young wrote: > Hi Ed, > > I'm fine with this approach in creating one bundle containing all the > slf4j artifacts. > > So, this is what's going to happen: > > 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM [1] > 2. Use the same steps from JBoss' in building the artifacts producing > the same maven coordinates in the local Maven repository > 3. Create a pom.xml in [1]/slf4j/1.5.9.RC1/slf4j-all that references > the artifacts from step 2 to create one slf4j-all bundle. Name this > artifact slf4j-all with the version 1.5.9.RC1 and the groupId: > org.glassfish.external > 4. We will publish the one slf4j bundle to our maven repository > 5. Provide a README describing the build. This should include steps > like checking out a particular version from external repo, setting env > and then issuing some commands. > > Jerome/Sahoo, let us know if you're okay with this approach. > > Ed, so BV will have a dependency on slf4j artifact and downloaded to > v3 workspace from hk2? Does Snjezana need to add this artifact in the > packager module or will this be added via transitive dependency? > > Thanks, > Jane > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Jane Young-Lau
::
Rate this Message:
Hi Sahoo,
Thank you for responding. I see your point and agree that we move slf4j-all outside of sl4j/1.5.9.RC1. So the complete steps are as follow: 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM (https://glassfish-svn.dev.java.net/svn/glassfish-svn/trunk/external/modules) 2. Use the same steps from JBoss' in building the artifacts producing the same maven coordinates 3. Provide a README describing the build. This should include steps like checking out a particular version from external repo, setting env and then issuing some commands. 4. Publish these artifacts in the GlassFish Maven repository (let's publish this in http://download.java.net/maven/glassfish - Please let me know when you get to this step) 5. In v3/packager/external, create a submodule slf4-all referencing the dependencies of slf4j and bundling the artifacts in one jar. Note that slf4j-all will have the groupId of "org.glassfish" and with the version "3.0-b##". 6. In Roger's weld-integration, he will need to define the dependency on slf4-all. Note since this artifact is built in the same project so no need add in dependencyManagment. However, the slf4j artifacts built in step2 will need be defined since it is needed in building slf4j-all. 7. Snjezana will include slf4j-all in packager. Jane Sahoo wrote: > Jane, > > I agree with those steps except #3. Can we have this *slf4j-all* > module outside of slf4j/1.5.9.RC1. e.g., > v3/glassfish/packager/external or something like that, so that > a) We don't have to create it every time we add new version of slf4j > in our scm. > b) We don't mix an artifact with groupId org.glassfish with that of > the external project. > > I also think org.glassfish.external is *not* an appropriate groupId. > org.glassfish is more appropriate. Any additional qualifier should be > part of artifactId; the group name should remain same for all > artifacts produced by this team. > > Thanks, > Sahoo > > Jane Young wrote: >> Hi Ed, >> >> I'm fine with this approach in creating one bundle containing all the >> slf4j artifacts. >> So, this is what's going to happen: >> >> 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM [1] >> 2. Use the same steps from JBoss' in building the artifacts >> producing the same maven coordinates in the local Maven repository >> 3. Create a pom.xml in [1]/slf4j/1.5.9.RC1/slf4j-all that >> references the artifacts from step 2 to create one slf4j-all bundle. >> Name this artifact slf4j-all with the version 1.5.9.RC1 and the >> groupId: org.glassfish.external >> 4. We will publish the one slf4j bundle to our maven repository >> 5. Provide a README describing the build. This should include steps >> like checking out a particular version from external repo, setting >> env and then issuing some commands. >> >> Jerome/Sahoo, let us know if you're okay with this approach. >> >> Ed, so BV will have a dependency on slf4j artifact and downloaded >> to v3 workspace from hk2? Does Snjezana need to add this artifact in >> the packager module or will this be added via transitive dependency? >> >> Thanks, >> Jane >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: slf4j as Glassfish OSGi module
by Sahoo
::
Rate this Message:
Does sljf4j not use Service lookup to locate log implementations? Can
you please tell us how it discovers log implementations and why bundling those two artifacts together affects the discovery process? Yes, we know slf4j is in central repo, but we have a requirement in GlassFish project to build external code in our own environment, hence we are promoting our own binaries. Sahoo Ceki Gulcu wrote: > Hello all, > > > Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a > single module will prevent slf4j from being able to use any logging > framework other that j.u.l. within Glassfish, which partially defeats > the purpose of SLF4J as a logging abstraction. Is keeping the slf4j > artifacts split an option? > > btw. 1.5.9.RC1 is already available in the central maven repository. > > Cheers, > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Ceki Gulcu
::
Rate this Message:
Have a look at the SLF4J manual at http://slf4j.org/manual.html, in particular the section entitled "Binding with a logging framework at deployment time" which explains how discovery is done. Sahoo wrote: > Does sljf4j not use Service lookup to locate log implementations? Can > you please tell us how it discovers log implementations and why bundling > those two artifacts together affects the discovery process? Yes, we know > slf4j is in central repo, but we have a requirement in GlassFish project > to build external code in our own environment, hence we are promoting > our own binaries. > > Sahoo > > Ceki Gulcu wrote: >> Hello all, >> >> >> Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a >> single module will prevent slf4j from being able to use any logging >> framework other that j.u.l. within Glassfish, which partially defeats >> the purpose of SLF4J as a logging abstraction. Is keeping the slf4j >> artifacts split an option? >> >> btw. 1.5.9.RC1 is already available in the central maven repository. >> >> Cheers, >> -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Sahoo
::
Rate this Message:
Thanks for pointing it out. Now I see why it is not appropriate to
bundle them together. It is still not very clear how the discovery takes place. Does it use reflection to find out which binding is available? It also does not specify if the binding has to be made visible to api jar? Can you clarify? If yes, we have a problem, since we can't share one slf4j api jar among multiple isolated apps without forcing each of them to use the same binding. Sahoo Ceki Gulcu wrote: > > Have a look at the SLF4J manual at http://slf4j.org/manual.html, in > particular the section entitled "Binding with a logging framework at > deployment time" which explains how discovery is done. > > > > Sahoo wrote: >> Does sljf4j not use Service lookup to locate log implementations? Can >> you please tell us how it discovers log implementations and why >> bundling those two artifacts together affects the discovery process? >> Yes, we know slf4j is in central repo, but we have a requirement in >> GlassFish project to build external code in our own environment, >> hence we are promoting our own binaries. >> >> Sahoo >> >> Ceki Gulcu wrote: >>> Hello all, >>> >>> >>> Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a >>> single module will prevent slf4j from being able to use any logging >>> framework other that j.u.l. within Glassfish, which partially defeats >>> the purpose of SLF4J as a logging abstraction. Is keeping the slf4j >>> artifacts split an option? >>> >>> btw. 1.5.9.RC1 is already available in the central maven repository. >>> >>> Cheers, >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Ceki Gulcu
::
Rate this Message:
The "discovery" is in the binding artifact. If you place slf4j-jdk14.jar on the class path, this means that SLF4J will delegate to j.u.l. If slf4j-log4j12.jar is on the class path, SLF4J will delegate to log4j, and so on. "Discovery", if you can call it that, is done by the JVM's most basic class loading mechanism (the one you learn about on your first day of Java). If that is still unclear, then I suggest you look at LoggerFactory [1] and the StaticLoggerBinder class found in any of the bindings, for example [2] for the j.u.l. binding and [3] for the log4j binding. SLF4J's discovery is really as dumb as it gets. I don't think you could make it any dumber which incidentally is the purpose of the exercise (dumb in this case implies robustness). As for the second part of your question, the instant the LoggerFactory class binds to a logger framework, it is bound until the LoggerFactory class is removed from memory. If the LoggerFactory class is shared between several components, each component will use the same underlying logging framework. This behavior is radically different than commons-logging. However, in practice, users will rarely, if ever, want to have their applications log into different logging frameworks. If (and it's an important if) Glassfish exports LoggerFactory to its hosted applications on account of its loading SLF4J into memory, then you will have all hosted apps sharing the same LoggerFactory instances. Jetty, which uses SLF4J internally, solves this issue by not exporting SLF4J classes to hosted applications. I suggest you go this route as well, i.e. isolate SLF4J and have users ship their own slf4j-api.jar and binding artifact within their application. Would that be possible? [1] http://slf4j.org/xref/org/slf4j/LoggerFactory.html [2] http://tinyurl.com/jdk14-binding [3] http://tinyurl.com/log4j12-binding Sahoo wrote: > Thanks for pointing it out. Now I see why it is not appropriate to > bundle them together. It is still not very clear how the discovery takes > place. Does it use reflection to find out which binding is available? It > also does not specify if the binding has to be made visible to api jar? > Can you clarify? If yes, we have a problem, since we can't share one > slf4j api jar among multiple isolated apps without forcing each of them > to use the same binding. > > Sahoo > > Ceki Gulcu wrote: >> >> Have a look at the SLF4J manual at http://slf4j.org/manual.html, in >> particular the section entitled "Binding with a logging framework at >> deployment time" which explains how discovery is done. >> >> >> >> Sahoo wrote: >>> Does sljf4j not use Service lookup to locate log implementations? Can >>> you please tell us how it discovers log implementations and why >>> bundling those two artifacts together affects the discovery process? >>> Yes, we know slf4j is in central repo, but we have a requirement in >>> GlassFish project to build external code in our own environment, >>> hence we are promoting our own binaries. >>> >>> Sahoo >>> >>> Ceki Gulcu wrote: >>>> Hello all, >>>> >>>> >>>> Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a >>>> single module will prevent slf4j from being able to use any logging >>>> framework other that j.u.l. within Glassfish, which partially defeats >>>> the purpose of SLF4J as a logging abstraction. Is keeping the slf4j >>>> artifacts split an option? >>>> >>>> btw. 1.5.9.RC1 is already available in the central maven repository. >>>> >>>> Cheers, >>>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Snjezana Sevo-Zenzerovic
::
Rate this Message:
FWIW, step 7 is rather trivial so I would appreciate if it can be done
at the same time as step 6. All that needs to be done is to also add slf4-all dependency to the dependency section of packager/glassfish-jcdi/pom.xml.... Thanks, Snjezana Jane Young wrote: > Hi Sahoo, > > Thank you for responding. I see your point and agree that we move > slf4j-all outside of sl4j/1.5.9.RC1. > > So the complete steps are as follow: > 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM > (https://glassfish-svn.dev.java.net/svn/glassfish-svn/trunk/external/modules) > > 2. Use the same steps from JBoss' in building the artifacts producing > the same maven coordinates > 3. Provide a README describing the build. This should include steps > like checking out a particular version from external repo, setting env > and then issuing some commands. > 4. Publish these artifacts in the GlassFish Maven repository (let's > publish this in http://download.java.net/maven/glassfish - Please let > me know when you get to this step) > 5. In v3/packager/external, create a submodule slf4-all referencing > the dependencies of slf4j and bundling the artifacts in one jar. Note > that slf4j-all will have the groupId of "org.glassfish" and with the > version "3.0-b##". > 6. In Roger's weld-integration, he will need to define the dependency > on slf4-all. Note since this artifact is built in the same project > so no need add in dependencyManagment. However, the slf4j artifacts > built in step2 will need be defined since it is needed in building > slf4j-all. > 7. Snjezana will include slf4j-all in packager. > > Jane > > > > Sahoo wrote: >> Jane, >> >> I agree with those steps except #3. Can we have this *slf4j-all* >> module outside of slf4j/1.5.9.RC1. e.g., >> v3/glassfish/packager/external or something like that, so that >> a) We don't have to create it every time we add new version of slf4j >> in our scm. >> b) We don't mix an artifact with groupId org.glassfish with that of >> the external project. >> >> I also think org.glassfish.external is *not* an appropriate groupId. >> org.glassfish is more appropriate. Any additional qualifier should be >> part of artifactId; the group name should remain same for all >> artifacts produced by this team. >> >> Thanks, >> Sahoo >> >> Jane Young wrote: >>> Hi Ed, >>> >>> I'm fine with this approach in creating one bundle containing all >>> the slf4j artifacts. >>> So, this is what's going to happen: >>> >>> 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM [1] >>> 2. Use the same steps from JBoss' in building the artifacts >>> producing the same maven coordinates in the local Maven repository >>> 3. Create a pom.xml in [1]/slf4j/1.5.9.RC1/slf4j-all that >>> references the artifacts from step 2 to create one slf4j-all >>> bundle. Name this artifact slf4j-all with the version 1.5.9.RC1 and >>> the groupId: org.glassfish.external >>> 4. We will publish the one slf4j bundle to our maven repository >>> 5. Provide a README describing the build. This should include >>> steps like checking out a particular version from external repo, >>> setting env and then issuing some commands. >>> >>> Jerome/Sahoo, let us know if you're okay with this approach. >>> >>> Ed, so BV will have a dependency on slf4j artifact and downloaded >>> to v3 workspace from hk2? Does Snjezana need to add this artifact >>> in the packager module or will this be added via transitive dependency? >>> >>> Thanks, >>> Jane >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: slf4j as Glassfish OSGi module
by Jane Young-Lau
::
Rate this Message:
Ceki/Sahoo,
Integrating weld in GlassFish requires the following slf4j and cal10n artifacts: http://repo2.maven.org/maven2/org/slf4j/slf4j-api/1.5.9.RC1/ http://repo2.maven.org/maven2/org/slf4j/slf4j-ext/1.5.9.RC1/ http://repo2.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.9.RC1/ http://repo2.maven.org/maven2/ch/qos/cal10n/cal10n-api/0.7.2/ If we can't combine the artifacts into one, then we'll need repackage all 4 of them to separate OSGi bundles? Ceki, your suggestion is to have hosted app bundle it's own slf4j-api.jar and binding artifacts. Does that mean we can bundle the other slf4j artifacts and cal10n as one artifact and package them as an OSGi module. Please let us know how to proceed so we can integrate weld and slf4j in GlassFish v3. Thanks, Jane Ceki Gulcu wrote: > > The "discovery" is in the binding artifact. If you place > slf4j-jdk14.jar on the class path, this means that SLF4J will delegate > to j.u.l. If slf4j-log4j12.jar is on the class path, SLF4J will > delegate to log4j, and so on. "Discovery", if you can call it that, is > done by the JVM's most basic class loading mechanism (the one you > learn about on your first day of Java). If that is still unclear, then > I suggest you look at LoggerFactory [1] and the StaticLoggerBinder > class found in any of the bindings, for example [2] for the > j.u.l. binding and [3] for the log4j binding. SLF4J's discovery is > really as dumb as it gets. I don't think you could make it any dumber > which incidentally is the purpose of the exercise (dumb in this case > implies robustness). > > As for the second part of your question, the instant the LoggerFactory > class binds to a logger framework, it is bound until the LoggerFactory > class is removed from memory. If the LoggerFactory class is shared > between several components, each component will use the same > underlying logging framework. This behavior is radically different > than commons-logging. However, in practice, users will rarely, if > ever, want to have their applications log into different logging > frameworks. > > If (and it's an important if) Glassfish exports LoggerFactory to its > hosted applications on account of its loading SLF4J into memory, then > you will have all hosted apps sharing the same LoggerFactory > instances. Jetty, which uses SLF4J internally, solves this issue by > not exporting SLF4J classes to hosted applications. I suggest you go > this route as well, i.e. isolate SLF4J and have users ship their own > slf4j-api.jar and binding artifact within their application. Would > that be possible? > > [1] http://slf4j.org/xref/org/slf4j/LoggerFactory.html > [2] http://tinyurl.com/jdk14-binding > [3] http://tinyurl.com/log4j12-binding > > Sahoo wrote: >> Thanks for pointing it out. Now I see why it is not appropriate to >> bundle them together. It is still not very clear how the discovery >> takes place. Does it use reflection to find out which binding is >> available? It also does not specify if the binding has to be made >> visible to api jar? Can you clarify? If yes, we have a problem, since >> we can't share one slf4j api jar among multiple isolated apps without >> forcing each of them to use the same binding. >> >> Sahoo >> >> Ceki Gulcu wrote: >>> >>> Have a look at the SLF4J manual at http://slf4j.org/manual.html, in >>> particular the section entitled "Binding with a logging framework at >>> deployment time" which explains how discovery is done. >>> >>> >>> >>> Sahoo wrote: >>>> Does sljf4j not use Service lookup to locate log implementations? >>>> Can you please tell us how it discovers log implementations and why >>>> bundling those two artifacts together affects the discovery >>>> process? Yes, we know slf4j is in central repo, but we have a >>>> requirement in GlassFish project to build external code in our own >>>> environment, hence we are promoting our own binaries. >>>> >>>> Sahoo >>>> >>>> Ceki Gulcu wrote: >>>>> Hello all, >>>>> >>>>> >>>>> Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a >>>>> single module will prevent slf4j from being able to use any logging >>>>> framework other that j.u.l. within Glassfish, which partially defeats >>>>> the purpose of SLF4J as a logging abstraction. Is keeping the slf4j >>>>> artifacts split an option? >>>>> >>>>> btw. 1.5.9.RC1 is already available in the central maven repository. >>>>> >>>>> Cheers, >>>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
