Hi Matthias, It's all my fault to make the logging behavior strange.
The Pax Logging bundle seems like a router to route JCL, Log4j and other logging systems to behave consistently. Whatever using any logging system, all configuration along with Pax Logging will affect. But this must keep any other bundle to start after Pax Logging bundle. But I forget this, so make Pax Ldap Server bundle fall back to the default logger and logging configuration. In my own configuration file, the following lines are important (pay attention to the start level): file:../bundles/system/pax-logging-api-1.4....@*200* file:../bundles/system/pax-logging-service-1.4....@*210* file:../bundles/system/pax-ldapserver-apacheds-0.3.0-snapshot....@*700* On Wed, Jan 27, 2010 at 3:34 AM, Matthias Küspert <[email protected]>wrote: > You're welcome. > > Pax LDAP Server internally uses Apache commons-logging. IIRC Apache DS > uses the same. What logging implementations are you using in your > application? > > If there is another one involved his may be a question for the pax > logging gurus ... Niclas, Alin ... anyone listening?? > > Feel free to open a bug in Jira > (http://issues.ops4j.org/browse/PAXLDAP) or ask on this list in a new > thread. > > However, as Pax LDAP Server is designed an plain OSGi bundle, it > should propably use the OSGi LogService via a ServiceTracker. > > It's on my list - I've just been too lazy until now ... but hey we're > 'open participation' ... anyone can get an account and commit a patch > ;-) > > Cheers, > Matthias > > On Tue, Jan 26, 2010 at 10:03 AM, Rui Tang <[email protected]> wrote: > > Hi Matthias, > > > > I've resolved the DEBUG logging problem. > > > > I should add start levels to ensure that the ldap server bundle starts > > exactly after the pax logging bundle. Then only INFO messages will be > > printed. > > > > Finally, everything works as expected! > > > > Thanks for your help! > > > > On Mon, Jan 25, 2010 at 4:45 PM, Matthias Küspert < > [email protected]> > > wrote: > >> > >> Good to hear that it's working again :-) > >> > >> 1. yes, but you then have to set a .dn configuration too, e.g.: > >> > >> org.ops4j.pax.ldapserver.apacheds.partitions = demo > >> org.ops4j.pax.ldapserver.apacheds.partition.dn.demo = dc=demo,dc=org > >> > >> note: there can also be multiple partition definitions, e.g.: > >> > >> org.ops4j.pax.ldapserver.apacheds.partitions = demo1,demo2 > >> org.ops4j.pax.ldapserver.apacheds.partition.dn.demo1 = dc=demo1,dc=org > >> org.ops4j.pax.ldapserver.apacheds.partition.dn.demo2 = dc=demo2,dc=org > >> > >> 2. Not sure what you mean: I see no DEBUG messages when I startup the > >> server with the org.ops4j.pax.logging.cfg from the /configuration > >> directory. > >> > >> HTH, > >> Matthias > >> > >> On Mon, Jan 25, 2010 at 4:54 AM, Rui Tang <[email protected]> wrote: > >> > Hi Matthias, > >> > > >> > Everything works great! Thank you! > >> > > >> > I have some other questions: > >> > > >> > 1. Can I change this parameter > >> > "org.ops4j.pax.ldapserver.apacheds.partitions > >> > = ops4j" to my own one instead of ops4j? > >> > 2. How to disable the DEBUG log message? I use Pax ConfMan to manage > my > >> > log > >> > configuration. And my own part application can follow this config, but > >> > the > >> > ldap server bundle cannot. I've tried to change the statement like > this > >> > "org.apache.commons.logging; version="1.0.4"; resolution:=optional; > >> > provider=paxlogging; mandatory:=provider" in osgi.bnd, but nothing > >> > worked. > >> > > >> > > >> > On Sun, Jan 24, 2010 at 11:47 PM, Matthias Küspert > >> > <[email protected]> wrote: > >> >> > >> >> Solved Ldif loading too. > >> >> > >> >> Please check the newest 0.3.0-SNAPSHOT - it should behave correctly. > >> >> > >> >> Matthias > >> >> > >> >> On Sun, Jan 24, 2010 at 11:38 AM, Matthias Küspert > >> >> <[email protected]> wrote: > >> >> > Ok, I sorted out the depencies and fixed the server startup. Now it > >> >> > reads the port- and partition configuration correctly. > >> >> > > >> >> > However, the loading of .ldif files on startup is still missing. > I'm > >> >> > still looking for an example on how to do that. > >> >> > > >> >> > At least you get a server up and running :-) > >> >> > > >> >> > Cheers, > >> >> > Matthias > >> >> > > >> >> > On Sat, Jan 23, 2010 at 5:25 PM, Rui Tang <[email protected]> > >> >> > wrote: > >> >> >> I've tried this new revision. > >> >> >> > >> >> >> But I found some other problems: > >> >> >> > >> >> >> 1. The build process failed. > >> >> >> 1.1 In project pax-ldapserver-apacheds, its pom.xml has > dependency > >> >> >> with > >> >> >> pax logging, required version is 1.3.0, but in apache maven > >> >> >> repository, > >> >> >> there's only 1.4 available, so please check it out. > >> >> >> 1.2 After fixing this, the build process can finish. I tested > the > >> >> >> packaged > >> >> >> jar, throws Import-Package not found exception. First is junit > >> >> >> library, > >> >> >> so I > >> >> >> add resolution:=optional to the osgi.bnd file to all junit > packages. > >> >> >> > >> >> >> 2. sun.reflect package is also needed in Import-Packages, So I add > >> >> >> sun.reflect package to --systemPakcages of Pax Runner > >> >> >> configurations, > >> >> >> then > >> >> >> my application can start correctly. > >> >> >> > >> >> >> 3. Then I try to use Apache Directory Studio to connect to the > >> >> >> server > >> >> >> via > >> >> >> port 8099, but failed. Form the log, I can see ApacheDS start OK > >> >> >> statements. > >> >> >> > >> >> >> 4. My env is like following. I use Pax Confman to manage all > >> >> >> configurations. > >> >> >> The folder structure is: > >> >> >> > >> >> >> bin > >> >> >> etc/configuraions/services/*.proerties (including pax logging and > >> >> >> ldapserver > >> >> >> config file) > >> >> >> etc/ldap/test.ldif > >> >> >> > >> >> >> I start my app from bin folder, please see the config and log > files > >> >> >> attached. > >> >> >> > >> >> >> Another problem is that the log printed by the ldapserver does not > >> >> >> follow > >> >> >> the instruction of the pax logging configuration. You can tell > this > >> >> >> from the > >> >> >> different log format. > >> >> >> > >> >> >> Finally, of course, the new version can work with MINA 2.0. > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Sat, Jan 23, 2010 at 8:03 PM, Matthias Küspert > >> >> >> <[email protected]> > >> >> >> wrote: > >> >> >>> > >> >> >>> Just commited the update to DS 1.5.5 ... please test again with > the > >> >> >>> latest 0.3.0-SNAPSHOT version and let me know if this solves your > >> >> >>> problem. > >> >> >>> > >> >> >>> Cheers, > >> >> >>> Matthias > >> >> >>> > >> >> >>> On Sat, Jan 23, 2010 at 10:37 AM, Matthias Küspert > >> >> >>> <[email protected]> wrote: > >> >> >>> > I suspect this is because the 0.3.0-SNAPSHOT is still using > >> >> >>> > ApacheDS > >> >> >>> > 1.5.4 - Mina 2.0.0 support was added in 1.5.5 - see [1] > >> >> >>> > > >> >> >>> > I already started some work on switching to DS 1.5.5 - I'll try > >> >> >>> > to > >> >> >>> > commit that stuff soon. > >> >> >>> > > >> >> >>> > HTH, > >> >> >>> > Matthias > >> >> >>> > > >> >> >>> > [1] > >> >> >>> > > >> >> >>> > > http://directory.apache.org/2009/08/19/apache-ds-155-released.html > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > On Fri, Jan 22, 2010 at 5:11 PM, Rui Tang <tangrui.cn@ > gmail.com> > >> >> >>> > wrote: > >> >> >>> >> Hi there, > >> >> >>> >> > >> >> >>> >> If I try to run Pax LDAP Server 0.3.0 individually, I can get > >> >> >>> >> everything > >> >> >>> >> work fine. > >> >> >>> >> > >> >> >>> >> But because my project have already used Mina 2.0.0-M5, so > when > >> >> >>> >> I > >> >> >>> >> start > >> >> >>> >> Pax > >> >> >>> >> LDAP Server together with Mina 2.0.0 then following exception > >> >> >>> >> was > >> >> >>> >> thrown: > >> >> >>> >> > >> >> >>> >> [ManagedService Update Queue] ERROR org.eclipse.equinox.cm - > >> >> >>> >> org/apache/mina/tra > >> >> >>> >> nsport/socket/nio/SocketAcceptor > >> >> >>> >> java.lang.NoClassDefFoundError: > >> >> >>> >> org/apache/mina/transport/socket/nio/SocketAccep > >> >> >>> >> tor > >> >> >>> >> at java.lang.ClassLoader.defineClass1(Native Method) > >> >> >>> >> at > >> >> >>> >> java.lang.ClassLoader.defineClass(ClassLoader.java:616) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass( > >> >> >>> >> DefaultClassLoader.java:183) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(Clas > >> >> >>> >> spathManager.java:576) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(Cl > >> >> >>> >> asspathManager.java:546) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassIm > >> >> >>> >> pl(ClasspathManager.java:477) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_L > >> >> >>> >> ockClassLoader(ClasspathManager.java:465) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(C > >> >> >>> >> lasspathManager.java:445) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalCla > >> >> >>> >> ss(DefaultClassLoader.java:211) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLo > >> >> >>> >> ader.java:381) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(Bundl > >> >> >>> >> eLoader.java:457) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader. > >> >> >>> >> java:410) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader. > >> >> >>> >> java:398) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(De > >> >> >>> >> faultClassLoader.java:105) > >> >> >>> >> at > java.lang.ClassLoader.loadClass(ClassLoader.java:248) > >> >> >>> >> at > >> >> >>> >> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.ops4j.pax.ldapserver.apacheds.internal.Server.startServer(Server. > >> >> >>> >> java:147) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.ops4j.pax.ldapserver.apacheds.internal.Server.updated(Server.java > >> >> >>> >> :204) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.equinox.internal.cm.ManagedServiceTracker$1.run(ManagedSe > >> >> >>> >> rviceTracker.java:181) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.equinox.internal.cm.SerializedTaskQueue$1.run(SerializedT > >> >> >>> >> askQueue.java:36) > >> >> >>> >> Caused by: java.lang.ClassNotFoundException: > >> >> >>> >> org.apache.mina.transport.socket.ni > >> >> >>> >> o.SocketAcceptor > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(Bundl > >> >> >>> >> eLoader.java:448) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader. > >> >> >>> >> java:410) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader. > >> >> >>> >> java:398) > >> >> >>> >> at > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(De > >> >> >>> >> faultClassLoader.java:105) > >> >> >>> >> at > java.lang.ClassLoader.loadClass(ClassLoader.java:248) > >> >> >>> >> at > >> >> >>> >> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316) > >> >> >>> >> ... 20 more > >> >> >>> >> > >> >> >>> >> I've found that the SocketAcceptor class has been renamed to > >> >> >>> >> NioSocketAcceptor in version 2.0.0. > >> >> >>> >> > >> >> >>> >> Is this a bug? And how can I fix it? > >> >> >>> >> > >> >> >>> >> Thank you! > >> >> >>> >> > >> >> >>> >> -- > >> >> >>> >> 唐睿 > >> >> >>> >> > >> >> >>> >> _______________________________________________ > >> >> >>> >> general mailing list > >> >> >>> >> [email protected] > >> >> >>> >> http://lists.ops4j.org/mailman/listinfo/general > >> >> >>> >> > >> >> >>> >> > >> >> >>> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> 唐睿 > >> >> >> > >> >> > > >> > > >> > > >> > > >> > -- > >> > 唐睿 > >> > > > > > > > > > -- > > 唐睿 > > > -- 唐睿
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
