Update org.apache.karaf.services.coordinator in subsystem feature

[Philipp Marx]

Hi,

I have noticed that the subsystem feature [1] contains
the org.apache.karaf.services.coordinator/4.x which references
org.eclipse.equinox.coordinator
[2] which is dated back to 2012. In the transaction and jpa feature the
newer up-to-date felix version [3] is being used.

The version at [2] is a little buggy from what I have seen. I experienced a
lot of concurrency issues when using it as well as an issue related to the
embedding of the jar [4]. Should this reference be updated to the felix
version or is there any particular reason for subsystems to use the equinox
version?

Cheers,
Philipp

[1]
https://github.com/apache/karaf/blob/master/assemblies/features/enterprise/src/main/feature/feature.xml
[2]
http://mvnrepository.com/artifact/org.eclipse.equinox/org.eclipse.equinox.coordinator/1.1.0.v20120522-1841
[3]
http://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.coordinator/1.0.2
[4] https://issues.apache.org/jira/browse/KARAF-4611

Access to XSD files from other bundles

[cniehues]

I created a BPMN2 file with the corresponding eclipse plugin which results in
a XML containing the following schemalocation:
/xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL
BPMN20.xsd"/

When the XML gets processed by the parser in karaf 4.0.5 it results in
following error:
/"Failed to read schema document 'BPMN20.xsd', because 1) could not find the
document; 2) the document could not be read; 3) the root element of the
document is not ."/

The bundle containing the BPMN20.xsd (jbpm-bpmn2) is active and I also tried
to add a dependency to jbpm-bpmn2 or an import for org.jbpm.bpmn2 but still
get the error. Even if I add the XSD files directly to my bundle the XML
isn't able to find the file.

So maybe I am missing some fundamental knowledge about resource
accessibility on karaf. I hope you can give me a hint.

Greetings
Christian



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Access-to-XSD-files-from-other-bundles-tp4047164.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

OK - thanks Achim,

/Bengt

2016-07-06 22:08 GMT+02:00 Achim Nierbeck :

> Hi Bengt,
>
> I'll try to find out if one of the bundles in that feature depends on
> log4j2 ... but I'm not aware of such a dependency.
>
> Your suspicion about dynamic loading of DLLs is correct in case of the
> location of the dll is inside of a bundle and does have dependencies to
> another dll. If it's a dll loaded via the root classloader that shouldn't
> be of an issue.
>
> regards, Achim
>
>
> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav :
>
>> Another theory: Looking at the stack trace this seems to be triggered by
>> a configuration update. Could the problem be that Pax-logging is trying to
>> load the DLL again and failing since it is already loaded? Perhaps the
>> initial load works but subsequent configuration updates does not?
>>
>> I tried to verify this...
>>
>> After successful start of Karaf (after step 9 in my previous post), I
>> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
>> and DEBUG). This causes no error.
>>
>> But after having installed feature pax-jetty (after step 10 in my
>> previous post), every change in org.ops4j.pas.logging.cfg causes the same
>> error to appear (the stack trace included in my previous post).
>>
>> It's as if installing the pax-jetty feature takes gives control of
>> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
>> idea how this could happen.
>>
>> Anyone else has an idea?
>>
>> /Bengt
>>
>>
>>
>>
>>
>>
>>
>> /Bengt
>>
>> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav :
>>
>>> A theory: Could one of the bundles installed by feature pax-jetty be
>>> using log4j 2.x directly without using Pax-logging? If so, would it too try
>>> to read the log4j configuration file? I guess it would fail to load the DLL
>>> since it is probably not compatible with log4j 2.x.
>>>
>>> Could this happen? If so, how can I find out which bundle?
>>>
>>> /Bengt
>>>
>>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav :
>>>
 Back to the Karaf mailing list

 I can actually get this problem on a standard vanilla Karaf 4.0.5. It
 seems to be triggered when installing the feature pax-jetty.

 *1. Install standard Karaf 4.0.5*

 *2. Replace org.ops4j.pax.logging.cfg with the following:*

 log4j.rootLogger=INFO, stdout

 # CONSOLE appender
 log4j.appender.stdout=org.apache.log4j.ConsoleAppender
 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
 log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
 %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
 log4j.appender.stdout.threshold=ERROR

 # Windows event log
 log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
 log4j.appender.nteventlog.source=Test source
 log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
 log4j.appender.nteventlog.layout.ConversionPattern=Time:
 %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
 log4j.appender.nteventlog.threshold=DEBUG

 *3. Start Karaf: "bin\karaf clean"*

 This should work.

 *4. Exit Karaf*

 *5. Change the root looger line to:*

 log4j.rootLogger=INFO, stdout, nteventlog

 *6. Start Karaf again*

 I get the following error:

 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
| ?? | [org.osgi.service.log.LogService,
 org.knopflerfish.service.log.LogService,
 org.ops4j.pax.logging.PaxLoggingService,
 org.osgi.service.cm.ManagedService, id=12,
 bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
 problem updating configuration org.ops4j.pax.logging
 java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
 java.library.path
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
 at java.lang.Runtime.loadLibrary0(Runtime.java:870)
 at java.lang.System.loadLibrary(System.java:1122)
 at
 org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
 at
 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at
 java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at java.lang.Class.newInstance(Class.java:442)
 at
 org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
 at
 org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
 at
 org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
 at