Brad Cox wrote:
Thanks! One step forward. The log messages weren't appearing because I
must be doing something wrong with ipojos, so I reenabled the osgi
activator logic to see if I could get oriented.
I'm getting my log msgs now on refresh (what does that do?), but most
die like this
java.lang.ClassFormatError: Illegal field modifiers in class
com/gestalt/soakit/transform/log/LogTransformService: 0x2
Hmm. I have no idea about that. See below too...
This happens as the activator tries to create an instance
public class LogTransformServiceActivator implements BundleActivator
{
public void start(BundleContext context) throws Exception
{
System.out.println("LogTransformServiceActivator.start()");
Properties props = new Properties();
LogTransformServiceImpl factory = new
LogTransformServiceImpl(context, props);
context.registerService(ComponentService.class.getName(),
factory, props);
}
public void stop(BundleContext context) throws Exception
{
System.out.println("LogTransformServiceActivator.stop()");
}
}
This seems to be a garden variety class loader error, but I just can't
find it. Maybe something wrong in metadata.xml?
<ipojo>
<component
classname="com.gestalt.soakit.transform.log.LogTransformService">
<provides/>
</component>
<instance component="com.gestalt.soakit.transform.log.LogTransform"/>
</ipojo>
I am a little confused, it seems there are lots of types involved here.
In your activator you seem to be creating a LogTransformServiceImpl, but
you are registering it as a ComponentService. In your iPOJO descriptor
it appears you have the service interface as the component
implementation class (i.e., LogTransformService instead of
LogTransformServiceImpl) and then you are trying to create an instance
of "LogTransform", which is something else altogether.
I would guess your iPOJO descriptor should look something like this:
<ipojo>
<component
classname="com.gestalt.soakit.transform.log.LogTransformServiceImpl">
<provides/>
</component>
<instance
component="com.gestalt.soakit.transform.log.LogTransformServiceImpl"/>
</ipojo>
I don't think this will fix the class format exception, though.
-> richard
Richard S. Hall wrote:
Brad Cox wrote:
The saga continues. I gave up on jdom and converted everything to
xom. Got all components converted to ipojo bundles (enclosing
dependencies), I think successfully (finally!).
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.2.1)
[ 7] [Active ] [ 1] Apache Felix Shell Service (1.0.2)
[ 8] [Active ] [ 1] Apache Felix Shell TUI (1.0.2)
[ 9] [Active ] [ 1] Apache Felix Bundle Repository (1.2.0)
[ 10] [Active ] [ 1] iPOJO (1.0.0)
[ 11] [Active ] [ 1] soakit.core (1.0.0.SNAPSHOT)
[ 12] [Active ] [ 1] soakit.port.file (1.0.0.SNAPSHOT)
[ 13] [Active ] [ 1] soakit.port.http (1.0.0.SNAPSHOT)
[ 14] [Active ] [ 1] soakit.port.jms (1.0.0.SNAPSHOT)
[ 15] [Active ] [ 1] soakit.transform.identity (1.0.0.SNAPSHOT)
[ 16] [Active ] [ 1] soakit.transform.log (1.0.0.SNAPSHOT)
[ 17] [Active ] [ 1] soakit.transform.pep (1.0.0.SNAPSHOT)
[ 18] [Active ] [ 1] soakit.transform.xsl (1.0.0.SNAPSHOT)
Problem is, that's all I see; in particular, no sign of logging
messages from any of these files. I'd expect to see at least the
service constructor logs.
Is felix redirecting the logs, or is this constructor not getting
called?
The level of logging output is dependent on how you have your logger
configured. Felix' log level is used for logging messages from Felix,
not bundles.
public CompositeServiceImpl(BundleContext context, Properties
properties)
{
System.err.println("new CompositeServiceImpl(c, p)");
log.info("new CompositeServiceImpl(..,..)");
this.context = context;
this.properties = properties;
componentTracker = new ComponentTracker(context);
componentTracker.open();
System.err.println("new CompositeServiceImpl(c, p) OK");
}
Most of all, could someone provide steps for debugging a felix
console session like this one from eclipse? The obvious approach,
launching felix (via pax runner) inside eclipse stopped working;
mysterious error during startup that I really don't understand.
I am not a power user of Eclipse, but the general approach I use for
both Eclipse and NetBeans is to launch Felix something like this:
java -Xdebug
-Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -jar
bin/felix.jar
Then I can attach the debugger to it on port 8001. Works well enough
for me.
-> richard
PS: Just tried installing all this under springsource-dm. I get to
the same point; nothing being logged and no idea how to debug it.
Launching it with startup.jar -debug -something (don't recall what)
gives a bus error.
Brad Cox wrote:
Surely such a simple problem can't be so difficult. Can someone help?
I need to use org.jdom in an OSGI application. But it is not (to my
knowledge) available as a bundle, just a jar. So I've been trying
to wrap the jar as a bundle; soakit.jdom.
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
