Re: configurationPid array may cause the Scheduler to throw a ClassCastException

[Jean-Baptiste Onofre]

FYI, I created https://issues.apache.org/jira/browse/KARAF-7113 
 about that.

Regards
JB

> Le 18 avr. 2021 à 22:14, Paul Spencer  a écrit :
> 
> Karaf 4.2.11 with Scheduler feature installed
> 
> 
> I am seeing the following error for Components implementing Runnable without 
> Scheduler configuration and multiple ConfigurationPID. 
> 
> 16:44:46.313 ERROR [pipe-start 195] Bundle org.apache.karaf.scheduler.core 
> [182] EventDispatcher: Error during dispatch. (java.lang.ClassCastException: 
> java.util.ArrayList cannot be cast to java.lang.String)
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.getServiceIdentifier(WhiteboardHandler.java:87)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.register(WhiteboardHandler.java:101)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.access$100(WhiteboardHandler.java:36)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler$1.addingService(WhiteboardHandler.java:65)
>  ~[?:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>  ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>  ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) 
> ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) 
> ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
>  ~[osgi.core-6.0.0.jar:?]
> 
> @Component {configurationPid = {"foo","bar"})
> public class Foo implements Runnable {
> ...
> }
> 
> It appears the Scheduler assumes all runnable components may have valid 
> Scheduler configuration in the @Component annotation or OSGi configuration 
> files. In my case, the Scheduler is failing to set a Service Identifier when 
> there is no scheduler.name configuration and the component's configurationPid 
> is an array.
> 
> Is this a bug?
> 
> 
> 
> Paul Spencer
> 

Re: configurationPid array may cause the Scheduler to throw a ClassCastException

[Jean-Baptiste Onofre]

Hi Paul,

Yes, it looks like a bug. The scheduler should ignore service which doesn’t 
have scheduler service property.

I will create a Jira about that and I will fix it.

Sorry for the inconvenience.

Regards
JB

> Le 18 avr. 2021 à 22:14, Paul Spencer  a écrit :
> 
> Karaf 4.2.11 with Scheduler feature installed
> 
> 
> I am seeing the following error for Components implementing Runnable without 
> Scheduler configuration and multiple ConfigurationPID. 
> 
> 16:44:46.313 ERROR [pipe-start 195] Bundle org.apache.karaf.scheduler.core 
> [182] EventDispatcher: Error during dispatch. (java.lang.ClassCastException: 
> java.util.ArrayList cannot be cast to java.lang.String)
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
> java.lang.String
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.getServiceIdentifier(WhiteboardHandler.java:87)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.register(WhiteboardHandler.java:101)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler.access$100(WhiteboardHandler.java:36)
>  ~[?:?]
>   at 
> org.apache.karaf.scheduler.core.WhiteboardHandler$1.addingService(WhiteboardHandler.java:65)
>  ~[?:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>  ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>  ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) 
> ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) 
> ~[osgi.core-6.0.0.jar:?]
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
>  ~[osgi.core-6.0.0.jar:?]
> 
> @Component {configurationPid = {"foo","bar"})
> public class Foo implements Runnable {
> ...
> }
> 
> It appears the Scheduler assumes all runnable components may have valid 
> Scheduler configuration in the @Component annotation or OSGi configuration 
> files. In my case, the Scheduler is failing to set a Service Identifier when 
> there is no scheduler.name configuration and the component's configurationPid 
> is an array.
> 
> Is this a bug?
> 
> 
> 
> Paul Spencer
> 

configurationPid array may cause the Scheduler to throw a ClassCastException

[Paul Spencer]

Karaf 4.2.11 with Scheduler feature installed


I am seeing the following error for Components implementing Runnable without 
Scheduler configuration and multiple ConfigurationPID. 

16:44:46.313 ERROR [pipe-start 195] Bundle org.apache.karaf.scheduler.core 
[182] EventDispatcher: Error during dispatch. (java.lang.ClassCastException: 
java.util.ArrayList cannot be cast to java.lang.String)
java.lang.ClassCastException: java.util.ArrayList cannot be cast to 
java.lang.String
at 
org.apache.karaf.scheduler.core.WhiteboardHandler.getServiceIdentifier(WhiteboardHandler.java:87)
 ~[?:?]
at 
org.apache.karaf.scheduler.core.WhiteboardHandler.register(WhiteboardHandler.java:101)
 ~[?:?]
at 
org.apache.karaf.scheduler.core.WhiteboardHandler.access$100(WhiteboardHandler.java:36)
 ~[?:?]
at 
org.apache.karaf.scheduler.core.WhiteboardHandler$1.addingService(WhiteboardHandler.java:65)
 ~[?:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
 ~[osgi.core-6.0.0.jar:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
 ~[osgi.core-6.0.0.jar:?]
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) 
~[osgi.core-6.0.0.jar:?]
at 
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) 
~[osgi.core-6.0.0.jar:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
 ~[osgi.core-6.0.0.jar:?]

@Component {configurationPid = {"foo","bar"})
public class Foo implements Runnable {
...
}

It appears the Scheduler assumes all runnable components may have valid 
Scheduler configuration in the @Component annotation or OSGi configuration 
files. In my case, the Scheduler is failing to set a Service Identifier when 
there is no scheduler.name configuration and the component's configurationPid 
is an array.

Is this a bug?



Paul Spencer

Re: How karaf handles Ctrl+D ?

[Jean-Baptiste Onofre]

Hi,

Yes, that’s it. Sorry, I was off earlier today ;)

Regards
JB

> Le 18 avr. 2021 à 11:58, Васил Зорев  a écrit :
> 
> Found it i think, it's exactly the place that throws the eofexception in the 
> jline reader:
> 
> if (this.buf.length() == 0 && this.getLastBinding().charAt(0) == 
> originalAttributes.getControlChar(ControlChar.VEOF)) {
> throw new EndOfFileException();
> }
> 
> Thank you again :)
> 
> На нд, 18.04.2021 г. в 12:41 ч. Васил Зорев  > написа:
> Hi JB,
> 
> Thank you for your response, and sorry for the many emails from my side this 
> weekend.. :)
> 
> I found this place 
> org.apache.karaf.shell.impl.console.JLineTerminal#handle(org.jline.terminal.Terminal.Signal)
> And it already handles Ctrl+C, but seems not to be called for Ctrl+D. Is this 
> handled in a different way? Please take your time, I don't mean to flood you 
> specifically with such questions.
> 
> Regards,
> Vassil
> 
> На нд, 18.04.2021 г. в 10:23 ч. JB Onofré  > написа:
> Hi
> 
> It’s managed at terminal level. 
> 
> With local console/terminal ctrl-d is trapped and stop Karaf (like halt 
> command). 
> 
> With ssh terminal ctrl-d just close the ssh client but of course not Karaf 
> runtime itself. 
> 
> It’s on the terminal impl (and console session). 
> 
> Regards 
> JB
> 
> > Le 17 avr. 2021 à 11:19, Васил Зорев  > > a écrit :
> > 
> > 
> > Hello,
> > 
> > I'm trying to figure out (out of interest) how Karaf responds to a ctrl+D 
> > keypress on the console. So far I found that there is some jline reader 
> > which, in case of ctrl+D input throws an 
> > org.jline.reader.EndOfFileException . Then the karaf console responds to 
> > this (in the case of a "local" console, that's another question at all but 
> > lets ignore it for now) by stopping the framework.
> > 
> > Could you elaborate a bit what this jline reader is, what are its key 
> > bindings and how this is integrated in karaf. Or please point me at some 
> > source/documentation, then I could investigate further :)
> > 
> > Thank you,
> > Regards,
> > Vassil
> 

Re: Error running test org.apache.karaf.itests.BundleTest#listCommand

[Васил Зорев]

Sorry, i guess this belongs more to the dev mailing list. I'll try to post
it there.

На нд, 18.04.2021 г. в 12:22 ч. Васил Зорев 
написа:

> Hello,
>
> I tried to run some of the unit tests in the itests project to check an
> issue, but most of them failed. The most common error is that pax exam
> couldn't start the container as it failed to replace
> the etc\org.ops4j.pax.logging.cfg file.
>
> Caused by: java.nio.file.FileSystemException:
> C:\Users\vasil\IdeaProjects\karaf\itests\test\target\exam\95aa38e2-a6a1-405e-8072-afe35347a34e\etc\org.ops4j.pax.logging.cfg:
> The process cannot access the file because it is being used by another
> process.
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
> ... (full log attached)
>
> I have checked out karaf sources version 4.2.12-SNAPSHOT from some time
> ago (probably a few months).
>
> Please find attached the intellij test log.
> It failed the same way when I executed the test as part of the maven build.
>
> I added a breakpoint at the place where the FileSystemException is thrown
> and examined the open file handles of this file in Sysinternals Process
> Explorer. Seems there are two open file handles for it, both by the same
> java process that is executing the test (screenshots attached).
>
> Please let me know if this is a known issue on my end if i can already
> resolve it, is it version dependent or something else? Also I can provide
> further details if needed.
>
> Regards,
> Vassil
>
>

Re: How karaf handles Ctrl+D ?

[Васил Зорев]

Found it i think, it's exactly the place that throws the eofexception in
the jline reader:

if (this.buf.length() == 0 && this.getLastBinding().charAt(0) ==
originalAttributes.getControlChar(ControlChar.VEOF)) {
throw new EndOfFileException();
}


Thank you again :)

На нд, 18.04.2021 г. в 12:41 ч. Васил Зорев 
написа:

> Hi JB,
>
> Thank you for your response, and sorry for the many emails from my side
> this weekend.. :)
>
> I found this
> place 
> org.apache.karaf.shell.impl.console.JLineTerminal#handle(org.jline.terminal.Terminal.Signal)
> And it already handles Ctrl+C, but seems not to be called for Ctrl+D. Is
> this handled in a different way? Please take your time, I don't mean to
> flood you specifically with such questions.
>
> Regards,
> Vassil
>
> На нд, 18.04.2021 г. в 10:23 ч. JB Onofré  написа:
>
>> Hi
>>
>> It’s managed at terminal level.
>>
>> With local console/terminal ctrl-d is trapped and stop Karaf (like halt
>> command).
>>
>> With ssh terminal ctrl-d just close the ssh client but of course not
>> Karaf runtime itself.
>>
>> It’s on the terminal impl (and console session).
>>
>> Regards
>> JB
>>
>> > Le 17 avr. 2021 à 11:19, Васил Зорев  a
>> écrit :
>> >
>> > 
>> > Hello,
>> >
>> > I'm trying to figure out (out of interest) how Karaf responds to a
>> ctrl+D keypress on the console. So far I found that there is some jline
>> reader which, in case of ctrl+D input throws an
>> org.jline.reader.EndOfFileException . Then the karaf console responds to
>> this (in the case of a "local" console, that's another question at all but
>> lets ignore it for now) by stopping the framework.
>> >
>> > Could you elaborate a bit what this jline reader is, what are its key
>> bindings and how this is integrated in karaf. Or please point me at some
>> source/documentation, then I could investigate further :)
>> >
>> > Thank you,
>> > Regards,
>> > Vassil
>>
>>

Re: How karaf handles Ctrl+D ?

[Васил Зорев]

Hi JB,

Thank you for your response, and sorry for the many emails from my side
this weekend.. :)

I found this
place 
org.apache.karaf.shell.impl.console.JLineTerminal#handle(org.jline.terminal.Terminal.Signal)
And it already handles Ctrl+C, but seems not to be called for Ctrl+D. Is
this handled in a different way? Please take your time, I don't mean to
flood you specifically with such questions.

Regards,
Vassil

На нд, 18.04.2021 г. в 10:23 ч. JB Onofré  написа:

> Hi
>
> It’s managed at terminal level.
>
> With local console/terminal ctrl-d is trapped and stop Karaf (like halt
> command).
>
> With ssh terminal ctrl-d just close the ssh client but of course not Karaf
> runtime itself.
>
> It’s on the terminal impl (and console session).
>
> Regards
> JB
>
> > Le 17 avr. 2021 à 11:19, Васил Зорев  a écrit
> :
> >
> > 
> > Hello,
> >
> > I'm trying to figure out (out of interest) how Karaf responds to a
> ctrl+D keypress on the console. So far I found that there is some jline
> reader which, in case of ctrl+D input throws an
> org.jline.reader.EndOfFileException . Then the karaf console responds to
> this (in the case of a "local" console, that's another question at all but
> lets ignore it for now) by stopping the framework.
> >
> > Could you elaborate a bit what this jline reader is, what are its key
> bindings and how this is integrated in karaf. Or please point me at some
> source/documentation, then I could investigate further :)
> >
> > Thank you,
> > Regards,
> > Vassil
>
>

Error running test org.apache.karaf.itests.BundleTest#listCommand

[Васил Зорев]

Hello,

I tried to run some of the unit tests in the itests project to check an
issue, but most of them failed. The most common error is that pax exam
couldn't start the container as it failed to replace
the etc\org.ops4j.pax.logging.cfg file.

Caused by: java.nio.file.FileSystemException:
C:\Users\vasil\IdeaProjects\karaf\itests\test\target\exam\95aa38e2-a6a1-405e-8072-afe35347a34e\etc\org.ops4j.pax.logging.cfg:
The process cannot access the file because it is being used by another
process.
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
... (full log attached)

I have checked out karaf sources version 4.2.12-SNAPSHOT from some time ago
(probably a few months).

Please find attached the intellij test log.
It failed the same way when I executed the test as part of the maven build.

I added a breakpoint at the place where the FileSystemException is thrown
and examined the open file handles of this file in Sysinternals Process
Explorer. Seems there are two open file handles for it, both by the same
java process that is executing the test (screenshots attached).

Please let me know if this is a known issue on my end if i can already
resolve it, is it version dependent or something else? Also I can provide
further details if needed.

Regards,
Vassil
"C:\Program Files\Java\jdk-9.0.4\bin\java.exe" -ea 
-Dorg.ops4j.pax.logging.DefaultServiceLog.level=INFO 
-Dspring31.version=3.1.4.RELEASE -Dspring32.version=3.2.18.RELEASE_1 
-Dspring40.version=4.0.9.RELEASE_1 -Dspring41.version=4.1.9.RELEASE_1 
-Dspring42.version=4.2.9.RELEASE_1 -Dspring43.version=4.3.30.RELEASE_1 
-Dspring50.version=5.0.20.RELEASE_1 -Dspring51.version=5.1.20.RELEASE_1 
-Dspring52.version=5.2.13.RELEASE_1 -Dspring53.version=5.3.4_1 
-Dspring.security31.version=3.1.4.RELEASE 
-Dspring.security42.version=4.2.4.RELEASE_1 
-Dspring.security51.version=5.1.5.RELEASE_1 
-Dspring.security53.version=5.3.1.RELEASE_1 -Dspring.security54.version=5.4.2_1 
-Dactivemq.version=5.15.11 
-Dpax.exam.configuration=file:src/test/resources/controlled-exam.properties 
--add-opens java.base/java.security=ALL-UNNAMED --add-opens 
java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
--add-opens java.base/java.util=ALL-UNNAMED --add-opens 
java.naming/javax.naming.spi=ALL-UNNAMED --add-opens 
java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED 
-Didea.test.cyclic.buffer.size=1048576 "-javaagent:C:\Program 
Files\JetBrains\IntelliJ IDEA Community Edition 
2020.3.2\lib\idea_rt.jar=59774:C:\Program Files\JetBrains\IntelliJ IDEA 
Community Edition 2020.3.2\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program 
Files\JetBrains\IntelliJ IDEA Community Edition 
2020.3.2\lib\idea_rt.jar;C:\Program Files\JetBrains\IntelliJ IDEA Community 
Edition 2020.3.2\plugins\junit\lib\junit5-rt.jar;C:\Program 
Files\JetBrains\IntelliJ IDEA Community Edition 

Re: How karaf handles Ctrl+D ?

[JB Onofré]

Hi

It’s managed at terminal level. 

With local console/terminal ctrl-d is trapped and stop Karaf (like halt 
command). 

With ssh terminal ctrl-d just close the ssh client but of course not Karaf 
runtime itself. 

It’s on the terminal impl (and console session). 

Regards 
JB

> Le 17 avr. 2021 à 11:19, Васил Зорев  a écrit :
> 
> 
> Hello,
> 
> I'm trying to figure out (out of interest) how Karaf responds to a ctrl+D 
> keypress on the console. So far I found that there is some jline reader 
> which, in case of ctrl+D input throws an org.jline.reader.EndOfFileException 
> . Then the karaf console responds to this (in the case of a "local" console, 
> that's another question at all but lets ignore it for now) by stopping the 
> framework.
> 
> Could you elaborate a bit what this jline reader is, what are its key 
> bindings and how this is integrated in karaf. Or please point me at some 
> source/documentation, then I could investigate further :)
> 
> Thank you,
> Regards,
> Vassil