On Tue, 2006-04-25 at 18:01 -0400, Enrique Rodriguez wrote:
> 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.
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.
>
> > 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.
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.
>
> > 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.
Cool.
Will the new M2 plugin support scr and the Service-Component manifest
header?
>
> Enrique
>
