|
Home > Archive > Apache Directory Project > April 2006 > Upgrading the OSGi
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Upgrading the OSGi
|
|
| John E. Conlon 2006-04-20, 6:56 pm |
| Have been experimenting with an updated version of the OSGi
org.apache.configuration.Activator located in the
trunks/apacheds/osgi/apacheds directory.
Have updated it by encapsulating it within a M2 OSGi plugin and have
replaced the hard coding of the directory configuration with a
springframework based server.xml file.
The issue I am having problems with is the loading of ldif using the
ldifDirectory property in the server.xml file.
<property name="ldifDirectory">
<value>src/test/resources/nonspecific.ldif</value>
</property>
Have tested that the MutableServerStartupConfiguration LdifDirectory
property is being set by the Spring IOC and that the file it references
exists, but it still doesn't load ldif nor does it log any error
messages.
Note: The file is good as I can load the file 'manually' with a
LdifFileLoader.
Being a newbee on embedding the server any ideas or hints on how to
approach the problem would be very appreciated.
kind regards,
John Conlon
| |
| Enrique Rodriguez 2006-04-20, 6:56 pm |
| John E. Conlon wrote:
....
> Have updated it by encapsulating it within a M2 OSGi plugin and have
> replaced the hard coding of the directory configuration with a
> springframework based server.xml file.
OK, makes sense. You may have noticed I'm working to upgrade this stuff
to M2 at the moment, too, so it is subject to change. Unfortunately, a
lot has changed, in particular the MINA interfaces and everything moving
from Oscar to Felix and Maven to M2, so there is a bit of work.
> The issue I am having problems with is the loading of ldif using the
> ldifDirectory property in the server.xml file.
>
> <property name="ldifDirectory">
> <value>src/test/resources/nonspecific.ldif</value>
> </property>
We could use some code samples, more server.xml, or even logging output
to try to help diagnose this.
....
> Being a newbee on embedding the server any ideas or hints on how to
> approach the problem would be very appreciated.
The way I would approach this is to get the "loader" OSGi bundle
working. You are combining starting the store as a service, adding
entries to it, and a bunch of Spring stuff not meant for OSGi-land,
which, IMO, should be separate. To this end I created the LdifLoader as
an Oscar console Command. Once the JNDI provider bundle is started then
the LdifLoader command can use the registered JNDI interface from the
OSGi backplane. This needs an update to Felix. Then, at the Felix
console you can call:
-> load <path/to/file> <context>
For example:
-> load /home/user/my.ldif dc=example,dc=com
One benefit here is that you can use 'load' more than just once at startup.
Enrique
| |
| John E. Conlon 2006-04-20, 6:56 pm |
| On Tue, 2006-04-18 at 17:34 -0400, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> ...
>
> OK, makes sense. You may have noticed I'm working to upgrade this stuff
> to M2 at the moment, too, so it is subject to change.
Yes I see the updates.
> Unfortunately, a
> lot has changed, in particular the MINA interfaces and everything moving
> from Oscar to Felix and Maven to M2, so there is a bit of work.
>
>
> We could use some code samples, more server.xml, or even logging output
> to try to help diagnose this.
I will send you the bundle for review (out of band) after I clean it up some.
> ...
>
> The way I would approach this is to get the "loader" OSGi bundle
> working.
> You are combining starting the store as a service, adding
> entries to it, and a bunch of Spring stuff not meant for OSGi-land,
> which, IMO, should be separate.
Agree. Have up to now only worked with the directory as a service so
was not approaching it with an OSGi backplane mindset. Thanks for the
correction.
Do we want to use Spring at all in this IntialContextFactory bundle?
Another question I have is related to how the underlying
InitialContextFactory implementation CoreContextFactory handles a null
Hashtable object. Here is how I create the implementation that will be
registered as a service.:
....
factory = getInitialContextFactory(configuration);
....
Dictionary parameters = new Hashtable();
registration = bundleContext.registerService
( InitialContextFactory.class.getName(),
factory,
parameters );
....
}
//
private InitialContextFactory getInitialContextFactory(String
configuration)
throws NamingException {
Hashtable env = new Hashtable( getStartEnvironment(configuration) );
CoreContextFactory coreContextFactory = new CoreContextFactory();
coreContextFactory.getInitialContext( env );
return coreContextFactory;
}
While testing if I do a
try {
context = factory.getInitialContext(null);
} catch (Exception e) {
e.printStackTrace();
fail(e.toString());
}
It throws a:
java.lang.NullPointerException
at
org.apache.directory.server.core.configuration.Configuration.toConfiguration(Configuration.java:58)
at
org.apache.directory.server.core.jndi.AbstractContextFactory. getInitialContext(AbstractContextFactory
.java:83)
at org.apache.ldap.server.ActivatorTest.testNullEnvironment
(ActivatorTest.java:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
According to the javax.naming.spi.InitialContextFactory interface
javadoc an implementation should be able to take a null env parameter.
I think an OSGi InitialContextFactory Service should return a valid
(default) Context if a null env is given. What if I wrapped
CoreContextFactory and replaced nulls with an env using a simple
Configuration like:
env.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.ldap.server.jndi.CoreContextFactory");
env.put(Context.PROVIDER_URL, "");
WDYT?
> To this end I created the LdifLoader as
> an Oscar console Command. Once the JNDI provider bundle is started then
> the LdifLoader command can use the registered JNDI interface from the
> OSGi backplane. This needs an update to Felix. Then, at the Felix
> console you can call:
>
> -> load <path/to/file> <context>
>
> For example:
>
> -> load /home/user/my.ldif dc=example,dc=com
>
> One benefit here is that you can use 'load' more than just once at startup.
Yes I looked at the Loader bundle. I can work on that one next.
John
| |
| John E. Conlon 2006-04-24, 7:56 am |
| On Wed, 2006-04-19 at 15:41 -0500, John E. Conlon wrote:
> On Tue, 2006-04-18 at 17:34 -0400, Enrique Rodriguez wrote:
> Yes I see the updates.
>
> I will send you the bundle for review (out of band) after I clean it up some.
>
> Agree. Have up to now only worked with the directory as a service so
> was not approaching it with an OSGi backplane mindset. Thanks for the
> correction.
>
> Do we want to use Spring at all in this IntialContextFactory bundle?
Simplified the Backend Store by removing the Springframework and going
with an approach similar to what you did in the previous release.
> Another question I have is related to how the underlying
> InitialContextFactory implementation CoreContextFactory handles a null
> Hashtable object. Here is how I create the implementation that will be
> registered as a service.:
>
> ...
> factory = getInitialContextFactory(configuration);
> ...
> Dictionary parameters = new Hashtable();
> registration = bundleContext.registerService
> ( InitialContextFactory.class.getName(),
> factory,
> parameters );
> ...
> }
> //
> private InitialContextFactory getInitialContextFactory(String
> configuration)
> throws NamingException {
> Hashtable env = new Hashtable( getStartEnvironment(configuration) );
> CoreContextFactory coreContextFactory = new CoreContextFactory();
> coreContextFactory.getInitialContext( env );
> return coreContextFactory;
> }
>
>
> While testing if I do a
>
> try {
> context = factory.getInitialContext(null);
> } catch (Exception e) {
> e.printStackTrace();
> fail(e.toString());
> }
>
> It throws a:
>
>
> java.lang.NullPointerException
> at
> org.apache.directory.server.core.configuration.Configuration.toConfiguration(Configuration.java:58)
> at
> org.apache.directory.server.core.jndi.AbstractContextFactory. getInitialContext(AbstractContextFactory
.java:83)
> at org.apache.ldap.server.ActivatorTest.testNullEnvironment
> (ActivatorTest.java:247)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
>
>
> According to the javax.naming.spi.InitialContextFactory interface
> javadoc an implementation should be able to take a null env parameter.
>
> I think an OSGi InitialContextFactory Service should return a valid
> (default) Context if a null env is given. What if I wrapped
> CoreContextFactory and replaced nulls with an env using a simple
> Configuration like:
>
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.ldap.server.jndi.CoreContextFactory");
> env.put(Context.PROVIDER_URL, "");
>
> WDYT?
>
>
> Yes I looked at the Loader bundle. I can work on that one next.
Starting to work with the loader.
Besides felix ui commands for loading ldif into the backend store, I
will add commands to dump or list the contents of the backend store.
John
| |
| Enrique Rodriguez 2006-04-24, 7:56 am |
| John E. Conlon wrote:
> On Tue, 2006-04-18 at 17:34 -0400, Enrique Rodriguez wrote:
> Yes I see the updates.
I just updated the Directory build to use M2 and the latest Directory
and MINA artifacts and Felix.
If you 'svn up' you should be able to run a 'mvn install' in the parent
POM and another 'mvn install' in the 'osgi' directory. There is a
parent POM for just the OSGi bundles, that is not wired into the topmost
Directory POM yet. Keep in mind that with Felix "strict modularity"
you'll need to add the following to your system packages:
org.osgi.framework.system.packages=
....
javax.naming, \
javax.naming.spi, \
javax.naming.directory, \
javax.naming.ldap, \
javax.security.auth.kerberos
There's more to test and clean-up, but with any luck you'll see:
------------------------------------------------------------------------
[INFO] Reactor Summary:
------------------------------------------------------------------------
[INFO] ApacheDS JNDI Backing Store ........................... SUCCESS
[INFO] ApacheDS Change Password Protocol Bundle .............. SUCCESS
[INFO] ApacheDS DNS Protocol Bundle .......................... SUCCESS
[INFO] ApacheDS JMX Logger Bundle ............................ SUCCESS
[INFO] ApacheDS Kerberos Protocol Bundle ..................... SUCCESS
[INFO] ApacheDS LDAP Protocol Bundle ......................... SUCCESS
[INFO] ApacheDS LDIF Loader Console Command .................. SUCCESS
[INFO] ApacheDS MINA Library Bundle .......................... SUCCESS
[INFO] ApacheDS NTP Protocol Bundle .......................... SUCCESS
[INFO] ApacheDS OSGi Bundle Build ............................ SUCCESS
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
------------------------------------------------------------------------
You then need to assemble everything manually in Felix. At a minimum
you'll want org.osgi.core, MINA, Service Binder, and the JNDI Backing
Store. Then on top of those you can add any of the protocols. You can
ignore SCR, nothing uses it and I was just trying it out:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (0.8.0.SNAPSHOT)
[ 1] [Active ] [ 1] ShellService (0.8.0.SNAPSHOT)
[ 2] [Active ] [ 1] ShellTUI (0.8.0.SNAPSHOT)
[ 3] [Active ] [ 1] BundleRepository (0.8.0.SNAPSHOT)
[ 4] [Active ] [ 1] Service Component Runtime (0.8.0.SNAPSHOT)
[ 5] [Active ] [ 1] osgi.core (0.8.0.SNAPSHOT)
[ 6] [Active ] [ 1] osgi.compendium (0.8.0.SNAPSHOT)
[ 8] [Active ] [ 1] ApacheDS MINA Bundle (1.1.0.SNAPSHOT)
[ 9] [Installed ] [ 1] Apache NTP Server Bundle (1.1.0.SNAPSHOT)
[ 10] [Active ] [ 1] Service Binder (0.8.0.SNAPSHOT)
[ 11] [Installed ] [ 1] Apache DNS Server Bundle (1.1.0.SNAPSHOT)
[ 12] [Active ] [ 1] ApacheDS JNDI Backing Store Bundle
(1.1.0.SNAPSHOT)
[ 13] [Active ] [ 1] Apache Kerberos Server Bundle (1.1.0.SNAPSHOT)
[ 14] [Active ] [ 1] Apache Change Password Server Bundle
(1.1.0.SNAPSHOT)
Let me know how it goes.
I'll have to get back to you on the rest of your email.
Enrique
| |
| John E. Conlon 2006-04-27, 6:46 am |
| Attempted to manually start up enough bundles to use an ldap admin tool
to browse the backend store, but encountered a few problems in the
attempt.
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (0.8.0.SNAPSHOT)
[ 1] [Active ] [ 1] osgi.compendium (0.8.0.SNAPSHOT)
[ 2] [Active ] [ 1] ShellService (0.8.0.SNAPSHOT)
[ 3] [Active ] [ 1] ShellTUI (0.8.0.SNAPSHOT)
[ 4] [Active ] [ 1] BundleRepository (0.8.0.SNAPSHOT)
[ 5] [Active ] [ 1] osgi.core (0.8.0.SNAPSHOT)
[ 6] [Active ] [ 1] Service Binder (0.8.0.SNAPSHOT)
[ 7] [Active ] [ 1] ApacheDS JNDI Backing Store Bundle
(1.1.0.SNAPSHOT)
[ 8] [Active ] [ 1] ApacheDS MINA Bundle (1.1.0.SNAPSHOT)
[ 9] [Installed ] [ 1] ApacheDS LDAP Protocol Bundle
(1.1.0.SNAPSHOT)
1. The first problem (annoyance is more appropriate) encountered was a
minor one - a warning message indicating a missing log4j.properties
file. What directory is the logging package expecting to find one?
2. The second problem occurred when the LDAP bundle couldn't find the
org.apache.mina.protocol package:
ERROR: Error starting file:/home/jconlon/projects/svns/directory-
sitedocs/trunks/apacheds/osgi/ldap/target/apacheds-protocol-osgi-
ldap-1.1.0-SNAPSHOT.jar (org.osgi.framework.BundleException: Unresolved
package in bundle 9: org.apache.mina.protocol)
org.osgi.framework.BundleException: Unresolved package in bundle 9:
org.apache.mina.protocol
I would have thought that the org.apache.mina.protocol package would be
exported by the MINA Bundle, but that class is neither contained in the
bundle nor is it exported by it. ??
3. The third problem I noticed while snooping around the MINA bundle -
it appears to have an error in the export declaration where it exports
the package org.apache.mina.protocol.handler yet it does not contain a
jar for of it.
kind regards,
John
| |
| Enrique Rodriguez 2006-04-27, 6:46 am |
| John E. Conlon wrote:
> Attempted to manually start up enough bundles to use an ldap admin tool
> to browse the backend store, but encountered a few problems in the
> attempt.
Sorry you had to do this manually. I made a 'main' module that will
assemble ApacheDS deps with the Felix runtime and startup with an
ApacheDS Felix "profile." I just committed this on rev 396981. Note
that it only does MINA and SLF4J for now, but it demonstrates the
technique. Other bundles will come quicker now, once I deal with the
import/export statements. See below.
> 1. The first problem (annoyance is more appropriate) encountered was a
> minor one - a warning message indicating a missing log4j.properties
> file. What directory is the logging package expecting to find one?
ApacheDS startup convention is to specify this on the command line:
java -Dlog4j.configuration=file://$(pwd)/log4j.properties
This is typically done for you in an apacheds.sh, which I just committed
on rev 396989.
> 2. The second problem occurred when the LDAP bundle couldn't find the
> org.apache.mina.protocol package:
>
> ERROR: ...
>
> I would have thought that the org.apache.mina.protocol package would be
> exported by the MINA Bundle, but that class is neither contained in the
> bundle nor is it exported by it. ??
>
> 3. The third problem I noticed while snooping around the MINA bundle -
> it appears to have an error in the export declaration where it exports
> the package org.apache.mina.protocol.handler yet it does not contain a
> jar for of it.
As for #2 and #3, there were a ton of old packages names still in the
POM's for the M1 project.xml's that I thought I could reuse but too much
got refactored in ApacheDS. Rather than pick away at them I took a step
back and started a full mangen analysis and I'll start with a clean
slate. I committed the mangen analysis file. I now have to go through
and update the manifests for each bundle. Let me get on that.
Note that we should see manifest generation appear in the M2 plugin
later this week, w.r.t import/export statement generation and Activator
detection, so other projects using OSGi won't have to go through this.
Enrique
| |
| John E. Conlon 2006-04-27, 6:46 am |
| On Tue, 2006-04-25 at 18:01 -0400, Enrique Rodriguez wrote:
> John E. Conlon wrote:
>
> Sorry you had to do this manually.
That's ok it was good practice.
> I made a 'main' module that will
> assemble ApacheDS deps with the Felix runtime and startup with an
> ApacheDS Felix "profile." I just committed this on rev 396981.
Yes I see it. Very nice.
But, why the new org.apache.directory.server.Main class? Couldn't you
have reused Felix's main?<BR>
> Note
> that it only does MINA and SLF4J for now, but it demonstrates the
> technique. Other bundles will come quicker now, once I deal with the
> import/export statements. See below.
Right.
>
>
> ApacheDS startup convention is to specify this on the command line:
>
> Java -Dlog4j.configuration=file://$(pwd)/log4j.properties
>
> This is typically done for you in an apacheds.sh, which I just committed
> on rev 396989.
The reason I asked was in the past I couldn't get to System properties
from bundles without putting a mapping in the config.properties like
this:
log4j.configuration=${log4j.configuration}
I noticed you did not do this and it now works with out it.
Should the log4j.properties file go in the conf directory with the other
the properties files?
Regarding logging, I needed to create a similar logging bundle to yours
because some of my other bundles had transitive dependencies on commons-
logging as well, so I added jcl104-over-slf4j. While at it, I added an
Activator that reset the configuration at start time. Now no need to
restart the framework after changing the log4j.properties file, just
stop and start the log bundle.
>
>
> As for #2 and #3, there were a ton of old packages names still in the
> POM's for the M1 project.xml's that I thought I could reuse but too much
> got refactored in ApacheDS. Rather than pick away at them I took a step
> back and started a full mangen analysis and I'll start with a clean
> slate. I committed the mangen analysis file. I now have to go through
> and update the manifests for each bundle. Let me get on that.
>
> Note that we should see manifest generation appear in the M2 plugin
> later this week, w.r.t import/export statement generation and Activator
> detection, so other projects using OSGi won't have to go through this.
Cool.
Will the new M2 plugin support scr and the Service-Component manifest
header?
>
> Enrique
>
| |
| Enrique Rodriguez 2006-04-27, 6:46 am |
| On 4/26/06, John E. Conlon <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote:
> On Tue, 2006-04-25 at 18:01 -0400, Enrique Rodriguez wrote:
....
>
> Yes I see it. Very nice.
>
> But, why the new org.apache.directory.server.Main class? Couldn't you
> have reused Felix's main?
Hmm, good point. I copied it as a start and, in retrospect, it ended
up unchanged. I'll update to copy in the Felix main jar and test.
....
> Should the log4j.properties file go in the conf directory with the other
> the properties files?
Sure. That would be consistent with Felix convention.
> Regarding logging, I needed to create a similar logging bundle to yours
> because some of my other bundles had transitive dependencies on commons-
> logging as well, so I added jcl104-over-slf4j. While at it, I added an
> Activator that reset the configuration at start time. Now no need to
> restart the framework after changing the log4j.properties file, just
> stop and start the log bundle.
That's a nice feature. I did my POM wrapper to get things working. I
don't plan on making any logging breakthroughs. At some point we can
check out how any logging bundles out there turn out.
> Will the new M2 plugin support scr and the Service-Component manifest
> header?
It will take less than 10 minutes to add this support to the plugin.=20
I can get around to it when ever we update Service Binder to SCR. Or
sooner if there is demand.
Enrique
| |
| Enrique Rodriguez 2006-04-27, 6:46 am |
| Enrique Rodriguez wrote:[vbcol=seagreen]
> On 4/26/06, John E. Conlon <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote:
> ...
I revised the ApacheDS OSGi Main to use the straight-up Felix Main.
[vbcol=seagreen]
> ...
I moved the log4j.properties to resources and copy it to the conf dir now.
....[vbcol=seagreen]
I added basic support for the Service-Component manifest header to the
Felix M2 Plugin.
Enrique
| |
| John E. Conlon 2006-04-27, 1:11 pm |
| On Wed, 2006-04-26 at 19:41 -0400, Enrique Rodriguez wrote:
> On 4/26/06, John E. Conlon <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote:
> ...
>
> Hmm, good point. I copied it as a start and, in retrospect, it ended
> up unchanged. I'll update to copy in the Felix main jar and test.
>
> ...
>
> Sure. That would be consistent with Felix convention.
>
>
> That's a nice feature. I did my POM wrapper to get things working. I
> don't plan on making any logging breakthroughs. At some point we can
> check out how any logging bundles out there turn out.
Too many choices for logging - Commons-Logging vs slf4j vs OSGi
logService it is as bad as choosing an American Health Care plan.
For what it's worth, below is a copy of the logging bundle Activator.
--------------------------------------------
import java.io.FileNotFoundException;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.log4j.LogManager;
import org.apache.log4j.PropertyConfigurator;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Activator implements BundleActivator {
private static final String LOG_PROPERTIES_LOCATION =
"log4j.configuration";
private Logger log = null;
public void start(BundleContext bundleContext) throws Exception {
try {
resetLog4j(bundleContext);
} catch (Exception e) {
//e.printStackTrace();
}
log = LoggerFactory.getLogger(Activator.class);
log.debug("Reset log configuration.");
}
public void stop(BundleContext arg0) throws Exception {}
/**
* @return url of the log4j.properties configuration file
*
* @throws MalformedURLException
*
*/
private URL getLoggingProperty(BundleContext bundleContext)
throws MalformedURLException {
final String logPropertiesLocation = bundleContext
.getProperty(LOG_PROPERTIES_LOCATION);
return new URL(logPropertiesLocation);
}
/**
* Reset the log4j configuration.
* @param bundleContext
* @throws MalformedURLException
* @throws FileNotFoundException
*/
private void resetLog4j(BundleContext bundleContext)
throws MalformedURLException,
FileNotFoundException {
LogManager.resetConfiguration();
URL log4jprops = getLoggingProperty(bundleContext);
if (log4jprops != null) {
PropertyConfigurator.configure(log4jprops);
} else {
throw new FileNotFoundException(bundleContext
.getProperty(LOG_PROPERTIES_LOCATION)
+ " could not be found. "
+ "Please specify add the file and restart the "
+ bundleContext.getBundle().getLocation() + " bundle.");
}
}
}
| |
| Ceki Gülcü 2006-04-27, 1:11 pm |
|
I recently read part of the OSGI spec to become familiar with it. Is there=
=20
any support you would like to see included directly in SLF4J that could=20
make life easier for you?
Cheers,
At 05:16 PM 4/27/2006, you wrote:
>On Wed, 2006-04-26 at 19:41 -0400, Enrique Rodriguez wrote:
other[vbcol=seagreen]
yours[vbcol=seagreen]
commons-[vbcol=seagreen]
an[vbcol=seagreen]
>
>Too many choices for logging - Commons-Logging vs slf4j vs OSGi
>logService it is as bad as choosing an American Health Care plan.
>
>For what it's worth, below is a copy of the logging bundle Activator.
>
>--------------------------------------------
>import java.io.FileNotFoundException;
>import java.net.MalformedURLException;
>import java.net.URL;
>
>import org.apache.log4j.LogManager;
>import org.apache.log4j.PropertyConfigurator;
>import org.osgi.framework.BundleActivator;
>import org.osgi.framework.BundleContext;
>import org.slf4j.Logger;
>import org.slf4j.LoggerFactory;
>
>public class Activator implements BundleActivator {
> private static final String LOG_PROPERTIES_LOCATION =3D
> "log4j.configuration";
>
> private Logger log =3D null;
>
> public void start(BundleContext bundleContext) throws Exception {
> try {
> resetLog4j(bundleContext);
> } catch (Exception e) {
> //e.printStackTrace();
> }
> log =3D LoggerFactory.getLogger(Activator.class);
> log.debug("Reset log configuration.");
> }
>
> public void stop(BundleContext arg0) throws Exception {}
>
> /**
> * @return url of the log4j.properties configuration file
> *
> * @throws MalformedURLException
> *
> */
> private URL getLoggingProperty(BundleContext bundleContext)
> throws MalformedURLException {
> final String logPropertiesLocation =3D bundleContext
> .getProperty(LOG_PROPERTIES_LOCATION);
> return new URL(logPropertiesLocation);
> }
>
> /**
> * Reset the log4j configuration.
> * @param bundleContext
> * @throws MalformedURLException
> * @throws FileNotFoundException
> */
> private void resetLog4j(BundleContext bundleContext)
> throws MalformedURLException,
> FileNotFoundException {
>
> LogManager.resetConfiguration();
> URL log4jprops =3D getLoggingProperty(bundleContext);
>
> if (log4jprops !=3D null) {
> PropertyConfigurator.configure(log4jprops);
> } else {
> throw new FileNotFoundException(bundleContext
> .getProperty(LOG_PROPERTIES_LOCATION)
> + " could not be found. "
> + "Please specify add the file and restart the "
> + bundleContext.getBundle().getLocation() + " bundle.");
> }
> }
>
>}
--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/
| |
| John E. Conlon 2006-04-27, 1:11 pm |
| On Wed, 2006-04-26 at 22:25 -0400, Enrique Rodriguez wrote:
> Enrique Rodriguez wrote:
>
> I revised the ApacheDS OSGi Main to use the straight-up Felix Main.
>
>
> I moved the log4j.properties to resources and copy it to the conf dir now.
>
> ...
>
> I added basic support for the Service-Component manifest header to the
> Felix M2 Plugin.
Great news. At this point I am still educating myself on the Declarative
Services and how it interacts with Configuration Management. Your
additions to the plugin, the apacheds osgi upgrades, and
Humberto's SCR submission should give me something to test with.
thanks again,
John
| |
| Enrique Rodriguez 2006-04-27, 1:11 pm |
| John E. Conlon wrote:
> On Wed, 2006-04-26 at 19:41 -0400, Enrique Rodriguez wrote:
....
....[vbcol=seagreen]
> For what it's worth, below is a copy of the logging bundle Activator.
Can you do me a favor and add that code to an attachment in JIRA? I can
then accept it for inclusion without any problems and you start to build
karma. I don't want to start a logging bundle, but having resettable
log levels would be handy.
Enrique
| |
| John E. Conlon 2006-04-27, 1:11 pm |
| On Thu, 2006-04-27 at 17:21 +0200, Ceki Gülcü wrote:
> I recently read part of the OSGI spec to become familiar with it. Is there
> any support you would like to see included directly in SLF4J that could
> make life easier for you?
There are some issues that just started showing up with the latest
builds of felix that are related to SLF4J
(actually NLOG4J).
My logging bundle includes both
<artifactId>jcl104-over-slf4j</artifactId
<version>1.0</version>
<artifactId>nlog4j</artifactId>
<version>1.2.24</version>
When felix starts the bundle I now am getting the following errors when
it trys to log to the console.
DEBUG: WIRE: [7.0] 7.0 -> org.osgi.framework -> 0
DEBUG: WIRE: [7.0] 7.0 -> org.apache.log4j -> 7.0
DEBUG: WIRE: [7.0] 7.0 -> org.slf4j -> 7.0
DEBUG: WIRE: [7.0] 7.0 -> org.apache.commons.logging -> 7.0
ERROR: ****
****
Package 'org.apache.log4j' is imported by bundle 7 from bundle 7, but
the export ed package from bundle 7 does not contain the requested class
'org.apache.log4j. PatternLayoutBeanInfo'. Please verify that the class
name is correct in the impo rting bundle 7 and/or that the exported
package is correctly bundled in 7.
****
****
ERROR: ****
****
Package 'org.apache.log4j' is imported by bundle 7 from bundle 7, but
the export ed package from bundle 7 does not contain the requested class
'org.apache.log4j. LayoutBeanInfo'. Please verify that the class name is
correct in the importing b undle 7 and/or that the exported package is
correctly bundled in 7.
****
****
Errors look to be related to the log4j.properties file. Everything
works, though.
kind regards,
John
> Cheers,
>
> At 05:16 PM 4/27/2006, you wrote:
>
| |
| Enrique Rodriguez 2006-04-27, 1:11 pm |
| John E. Conlon wrote:
> On Wed, 2006-04-26 at 22:25 -0400, Enrique Rodriguez wrote:
....[vbcol=seagreen]
>
> Great news. At this point I am still educating myself on the Declarative
> Services and how it interacts with Configuration Management. Your
> additions to the plugin, the apacheds osgi upgrades, and
> Humberto's SCR submission should give me something to test with.
Humberto pretty much ported Service Binder forward to SCR. If you want
to pick up on SCR and there aren't many examples out there yet you can
take a look at Service Binder examples. I say this more for the list.
Enrique
| |
| Enrique Rodriguez 2006-04-27, 1:11 pm |
| Ceki Gülcü wrote:
>
> I recently read part of the OSGI spec to become familiar with it. Is
> there any support you would like to see included directly in SLF4J that
> could make life easier for you?
Thanks for offering. We don't want to host a logging bundle effort
here. So, some basic features we need:
o Best thing you could do is bundlize existing jars. The manifest
header entries needed for OSGi won't affect anybody. At a minimum you'd
add export statements. Adding an Activator like John's would add a
compile time dep on OSGi framework API.
o Logging bundle retrievable from M2 repos.
o Basic export statements in manifest header for logging packages,
namely org.slf4j and org.apache.log4j.
o A way to reset logging levels without stopping the whole server.
When John submits his logging Activator via JIRA you could take that
over. Resetting logging levels by stop/starting the logging bundle is a
fine way.
Enrique
|
|
|
|
|