directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Upgrading the OSGi
Date Wed, 26 Apr 2006 22:44:59 GMT
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
> 


Mime
View raw message