[jira] [Commented] (KARAF-7799) Allow merging org.apache.karaf.features.xml definitions
[
https://issues.apache.org/jira/browse/KARAF-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806738#comment-17806738
]
Grzegorz Grzybek commented on KARAF-7799:
-
When building custom Karaf distro with KARs and karaf-maven-plugin:
* the KAR may provide {{etc/org.apache.karaf.features.xml}} definition
* karaf-maven-plugin may define {{}} option to specify
custom {{org.apache.karaf.features.xml}}
* but we can't have both.
The build log shows for example:
{noformat}
[INFO] Found existing features processor configuration:
etc/org.apache.karaf.features.xml
[WARNING] Explicitly configured
../../src/main/resources/org.apache.karaf.features.xml will be used for
features processor configuration.
{noformat}
It'd be nice if we can merge two definitions.
I have a PR that simply results in this:
{noformat}
[INFO] Found existing features processor configuration:
etc/org.apache.karaf.features.xml
[INFO] Found additional features processor configuration:
../../src/main/resources/org.apache.karaf.features.xml
{noformat}
> Allow merging org.apache.karaf.features.xml definitions
> ---
>
> Key: KARAF-7799
> URL: https://issues.apache.org/jira/browse/KARAF-7799
> Project: Karaf
> Issue Type: Improvement
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.5.0, 4.4.6
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (KARAF-7799) Allow merging org.apache.karaf.features.xml definitions
[ https://issues.apache.org/jira/browse/KARAF-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned KARAF-7799: --- Assignee: Grzegorz Grzybek > Allow merging org.apache.karaf.features.xml definitions > --- > > Key: KARAF-7799 > URL: https://issues.apache.org/jira/browse/KARAF-7799 > Project: Karaf > Issue Type: Improvement >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.5.0, 4.4.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KARAF-7799) Allow merging org.apache.karaf.features.xml definitions
Grzegorz Grzybek created KARAF-7799: --- Summary: Allow merging org.apache.karaf.features.xml definitions Key: KARAF-7799 URL: https://issues.apache.org/jira/browse/KARAF-7799 Project: Karaf Issue Type: Improvement Reporter: Grzegorz Grzybek Fix For: 4.5.0, 4.4.6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KARAF-688) Ability to retrieve a available list of a specific maven artifact's versions via ( with given groupId and artifactId )
[
https://issues.apache.org/jira/browse/KARAF-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786320#comment-17786320
]
Grzegorz Grzybek commented on KARAF-688:
I've just closed https://github.com/ops4j/org.ops4j.pax.url/issues/287
explaining that you don't need an extension to {{mvn:}} URL syntax - what you
need is direct interaction with [Maven Resolver
API|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/RepositorySystem.html].
> Ability to retrieve a available list of a specific maven artifact's versions
> via ( with given groupId and artifactId )
> ---
>
> Key: KARAF-688
> URL: https://issues.apache.org/jira/browse/KARAF-688
> Project: Karaf
> Issue Type: New Feature
> Components: karaf
>Affects Versions: 2.2.1
> Environment: windows/linix,java 6
>Reporter: Dan Tran
>Assignee: Andreas Pieber
>Priority: Major
> Attachments: KARAF-688-2.diff, KARAF-688.diff
>
>
> Details discussion is here
> http://karaf.922171.n3.nabble.com/Ability-to-retrieve-a-available-list-of-a-specific-maven-artifact-s-versions-via-with-given-groupId--td2989285.html
> Basically I have a karaf base agent which I'd like to get the agent to
> periodically polling maven repos to check for available upgrade version. This
> requested feature is crucial for my work
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KARAF-688) Ability to retrieve a available list of a specific maven artifact's versions via ( with given groupId and artifactId )
[ https://issues.apache.org/jira/browse/KARAF-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved KARAF-688. Resolution: Invalid > Ability to retrieve a available list of a specific maven artifact's versions > via ( with given groupId and artifactId ) > --- > > Key: KARAF-688 > URL: https://issues.apache.org/jira/browse/KARAF-688 > Project: Karaf > Issue Type: New Feature > Components: karaf >Affects Versions: 2.2.1 > Environment: windows/linix,java 6 >Reporter: Dan Tran >Assignee: Andreas Pieber >Priority: Major > Attachments: KARAF-688-2.diff, KARAF-688.diff > > > Details discussion is here > http://karaf.922171.n3.nabble.com/Ability-to-retrieve-a-available-list-of-a-specific-maven-artifact-s-versions-via-with-given-groupId--td2989285.html > Basically I have a karaf base agent which I'd like to get the agent to > periodically polling maven repos to check for available upgrade version. This > requested feature is crucial for my work -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KARAF-7779) Problem installing feature with fragment bundle for existing host bundle
[
https://issues.apache.org/jira/browse/KARAF-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7779:
Fix Version/s: 4.5.0
> Problem installing feature with fragment bundle for existing host bundle
>
>
> Key: KARAF-7779
> URL: https://issues.apache.org/jira/browse/KARAF-7779
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.4
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.5.0, 4.4.5
>
>
> In my custom Karaf distro with custom KAR which uses Pax Web and fragment
> bundles (for javax-el-api), I had this problem:
> {noformat}
> java.lang.IllegalStateException: Resource has no uri
> at
> org.apache.karaf.features.internal.service.Deployer.getBundleInputStream(Deployer.java:1631)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:904)
> ...
> {noformat}
> After quite complex investigation I was able to prepare a Karaf test case and
> the problem can be described like this:
> * we install a feature which contains fragment bundle which can be attached
> to already existing bundle
> * Karaf resolver/deployer treats already installed bundles as BundleRevisions
> (without {{osgi.content}} namespaced capabilities. {{url}} is part of Bundle
> capabilities only
> * during resolver procedure, I had this:
> {noformat}
> {org.apache.felix.framework.BundleRevisionImpl@7703}
> "org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)" ->
> {java.util.ArrayList@11407} size = 3
> key: org.apache.felix.framework.BundleRevisionImpl =
> {org.apache.felix.framework.BundleRevisionImpl@7703}
> "org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)"
> value: java.util.ArrayList = {java.util.ArrayList@11407} size = 3
> 0 = {org.apache.felix.resolver.WireImpl@11791}
> "[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.6.0)(!(version>=2.0.0)))
> -> [org.apache.felix.framework [0](R 0)]"
> 1 = {org.apache.felix.resolver.WireImpl@11792}
> "[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)] osgi.ee;
> (&(osgi.ee=JavaSE)(version=1.7)) -> [org.apache.felix.framework [0](R 0)]"
> 2 = {org.apache.felix.resolver.WireImpl@9972}
> "[org.jboss.fuse.modules.fuse-el2-compatibility/7.12.1.fuse-7_12_1-9-redhat-1]
> osgi.identity; osgi.identity="root#pax-web-jsp-8.0.23";
> type=karaf.subsystem; version="[0,0.0.0]"; resolution:=mandatory ->
> [root#pax-web-jsp-8.0.23]"
> {noformat}
> which means that the fragment added a wire to the host bundle. The wire ties
> the BundleRevision resource to feature's subsystem, effectively marking
> already existing BundleRevision as a resource to install.
> The problem is that there's no {{osgi.content; url=xxx}} capability inside
> existing BundleRevision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KARAF-7779) Problem installing feature with fragment bundle for existing host bundle
Grzegorz Grzybek created KARAF-7779:
---
Summary: Problem installing feature with fragment bundle for
existing host bundle
Key: KARAF-7779
URL: https://issues.apache.org/jira/browse/KARAF-7779
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.4.4
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
Fix For: 4.4.5
In my custom Karaf distro with custom KAR which uses Pax Web and fragment
bundles (for javax-el-api), I had this problem:
{noformat}
java.lang.IllegalStateException: Resource has no uri
at
org.apache.karaf.features.internal.service.Deployer.getBundleInputStream(Deployer.java:1631)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:904)
...
{noformat}
After quite complex investigation I was able to prepare a Karaf test case and
the problem can be described like this:
* we install a feature which contains fragment bundle which can be attached to
already existing bundle
* Karaf resolver/deployer treats already installed bundles as BundleRevisions
(without {{osgi.content}} namespaced capabilities. {{url}} is part of Bundle
capabilities only
* during resolver procedure, I had this:
{noformat}
{org.apache.felix.framework.BundleRevisionImpl@7703}
"org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)" ->
{java.util.ArrayList@11407} size = 3
key: org.apache.felix.framework.BundleRevisionImpl =
{org.apache.felix.framework.BundleRevisionImpl@7703}
"org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)"
value: java.util.ArrayList = {java.util.ArrayList@11407} size = 3
0 = {org.apache.felix.resolver.WireImpl@11791}
"[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.6.0)(!(version>=2.0.0)))
-> [org.apache.felix.framework [0](R 0)]"
1 = {org.apache.felix.resolver.WireImpl@11792}
"[org.apache.servicemix.specs.javax-el-api-3.0.0 [39](R 39.0)] osgi.ee;
(&(osgi.ee=JavaSE)(version=1.7)) -> [org.apache.felix.framework [0](R 0)]"
2 = {org.apache.felix.resolver.WireImpl@9972}
"[org.jboss.fuse.modules.fuse-el2-compatibility/7.12.1.fuse-7_12_1-9-redhat-1]
osgi.identity; osgi.identity="root#pax-web-jsp-8.0.23"; type=karaf.subsystem;
version="[0,0.0.0]"; resolution:=mandatory -> [root#pax-web-jsp-8.0.23]"
{noformat}
which means that the fragment added a wire to the host bundle. The wire ties
the BundleRevision resource to feature's subsystem, effectively marking already
existing BundleRevision as a resource to install.
The problem is that there's no {{osgi.content; url=xxx}} capability inside
existing BundleRevision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved KARAF-7773.
-
Resolution: Fixed
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.5
>
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780485#comment-17780485
]
Grzegorz Grzybek commented on KARAF-7773:
-
PR for 4.4.x: https://github.com/apache/karaf/pull/1787
PR for 4.5.x: https://github.com/apache/karaf/pull/1788
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.5
>
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7773:
Fix Version/s: 4.4.5
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.5
>
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780333#comment-17780333
]
Grzegorz Grzybek commented on KARAF-7773:
-
I have a reproducer and a fix. See
https://github.com/ops4j/org.ops4j.pax.web/issues/1913
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1635#comment-1635
]
Grzegorz Grzybek commented on KARAF-7773:
-
It was a great journey for me to rewrite Pax Web 7 into Pax Web 8 - I only
stand on the shoulders of giants here ;).
And I'm sorry I released 8.0.23 / 9.0.12 without touching this issue, but I
promise I'll look at it in more details (providing explanations here) soon!
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1608#comment-1608
]
Grzegorz Grzybek commented on KARAF-7773:
-
Reusing the instance of PaxWebStandardContextHandler is by design. But I get
the picture now. I can't check this today, but soon I'll verify this scenario
with WAB having one listener and not being removed when touched/updated.
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1608#comment-1608
]
Grzegorz Grzybek edited comment on KARAF-7773 at 10/20/23 7:41 AM:
---
Reusing the instance of PaxWebStandardContextHandler is by design. But I get
the picture now. I can't check this today, but soon I'll verify this scenario
with WAB having one listener and not being removed when touched/updated.
And thanks [~amichai] for your investigation - really appreciated!
was (Author: gzres):
Reusing the instance of PaxWebStandardContextHandler is by design. But I get
the picture now. I can't check this today, but soon I'll verify this scenario
with WAB having one listener and not being removed when touched/updated.
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1344#comment-1344
]
Grzegorz Grzybek commented on KARAF-7773:
-
grepping by {{ServletContextInitializer}} I can see only:
{noformat}
2023-10-19T16:11:38,378 | INFO | paxweb-config-1-thread-1 (deploy /) |
com.example.web.core.ServletContextInitializer /
com.example.web.core.ServletContextInitializer | 78 - com.example.web.core -
0.1.0.SNAPSHOT | context initialized
2023-10-19T16:12:05,125 | INFO | paxweb-config-1-thread-1 (undeploy /) |
com.example.web.core.ServletContextInitializer /
com.example.web.core.ServletContextInitializer | 78 - com.example.web.core -
0.1.0.SNAPSHOT | context destroyed
2023-10-19T16:12:05,126 | INFO | paxweb-config-1-thread-1 (undeploy /) |
com.example.web.core.ServletContextInitializer /
com.example.web.core.ServletContextInitializer | 78 - com.example.web.core -
0.1.0.SNAPSHOT | context initialized
2023-10-19T16:12:05,130 | DEBUG | paxweb-config-1-thread-1 |
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper /
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper | 447 -
org.ops4j.pax.web.pax-web-jetty - 8.0.15 | Delaying removal of event listener
EventListenerModel{id=EventListenerModel-14,listener='com.example.web.core.ServletContextInitializer@4f2c7d5b',contexts=[{WAB,OCM-11,/,/}]}
2023-10-19T16:12:05,143 | INFO | paxweb-config-1-thread-1 (change controller)
| com.example.web.core.ServletContextInitializer /
com.example.web.core.ServletContextInitializer | 78 - com.example.web.core -
0.1.0.SNAPSHOT | context destroyed
{noformat}
Still I can't see when it was added in the first place...
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log, paxweb.trace2.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KARAF-7774) ServletContext.getServletContextName() returns wrong value
[
https://issues.apache.org/jira/browse/KARAF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved KARAF-7774.
-
Resolution: Fixed
> ServletContext.getServletContextName() returns wrong value
> --
>
> Key: KARAF-7774
> URL: https://issues.apache.org/jira/browse/KARAF-7774
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> The ServletContext.getServletContextName() interface javadoc says:
> {noformat}
> Returns the name of this web application corresponding to this ServletContext
> as specified in the deployment descriptor for this web application by the
> display-name element.
> {noformat}
> In my app, I drop into karaf's deploy folder a WAB bundle with a web.xml
> containing only display-name (human-readable string) and listener-class with
> a ServletContextListener implementation class name. The listener's
> contextInitialized method is invoked, but
> event.getServletContext().getServletContextName() returns what appears to be
> the context path (e.g. "/") instead of the display name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7774) ServletContext.getServletContextName() returns wrong value
[
https://issues.apache.org/jira/browse/KARAF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1259#comment-1259
]
Grzegorz Grzybek commented on KARAF-7774:
-
Fixed here in Pax Web:
https://github.com/ops4j/org.ops4j.pax.web/commit/33ee5d9162ecc8c6af734a46c176661fc595252b
> ServletContext.getServletContextName() returns wrong value
> --
>
> Key: KARAF-7774
> URL: https://issues.apache.org/jira/browse/KARAF-7774
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> The ServletContext.getServletContextName() interface javadoc says:
> {noformat}
> Returns the name of this web application corresponding to this ServletContext
> as specified in the deployment descriptor for this web application by the
> display-name element.
> {noformat}
> In my app, I drop into karaf's deploy folder a WAB bundle with a web.xml
> containing only display-name (human-readable string) and listener-class with
> a ServletContextListener implementation class name. The listener's
> contextInitialized method is invoked, but
> event.getServletContext().getServletContextName() returns what appears to be
> the context path (e.g. "/") instead of the display name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1258#comment-1258
]
Grzegorz Grzybek edited comment on KARAF-7773 at 10/19/23 1:05 PM:
---
In {{etc/org.ops4j.pax.logging.cfg}}, can you change:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %-32c{1} | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
to:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %c / %C | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
and enable TRACE logging for {{org.ops4j.pax.web}}?
was (Author: gzres):
In {{etc/org.ops4j.pax.logging.cfg}}, can you change:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %-32c{1} | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
to:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %c / %C | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
?
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1258#comment-1258
]
Grzegorz Grzybek commented on KARAF-7773:
-
In {{etc/org.ops4j.pax.logging.cfg}}, can you change:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %-32c{1} | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
to:
{noformat}
log4j2.pattern = %d{ISO8601} | %-5p | %-16t | %c / %C | %X{bundle.id} -
%X{bundle.name} - %X{bundle.version} | %encode{%.-500m}{CRLF}%n
{noformat}
?
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1255#comment-1255
]
Grzegorz Grzybek commented on KARAF-7773:
-
FIrst observation:
{noformat}
2023-10-19T15:12:01,085 | DEBUG | paxweb-config-1-thread-1 (deploy /) |
HttpServiceEnabled | 450 - org.ops4j.pax.web.pax-web-runtime -
8.0.15 | Passing registration of
EventListenerModel{id=EventListenerModel-20,listener='org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer$ContextDestroyListener@3e747eea',contexts=[{WAB,OCM-11,/,/}]}
to configuration thread
2023-10-19T15:12:01,085 | DEBUG | paxweb-config-1-thread-1 (deploy /) |
WebElementEventDispatcher| 450 - org.ops4j.pax.web.pax-web-runtime -
8.0.15 | Sending web element event DEPLOYING
(org.eclipse.jetty.websocket.javax.websocket.server/9.4.48.v20220622):
org.ops4j.pax.web.service.spi.model.events.EventListenerEventData@e82a33e for
bundle org.eclipse.jetty.websocket.javax.websocket.server
...
2023-10-19T15:12:01,118 | INFO | paxweb-config-1-thread-1 (deploy /) | /
| 398 - org.eclipse.jetty.util - 9.4.50.v20221201 |
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: loaded (conf ok)
{noformat}
you see - Pax Web detected
{{org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer$ContextDestroyListener}}
from {{org.eclipse.jetty.websocket.javax.websocket.server/9.4.48.v20220622}}
while Pax Web 8.0.15 uses Jetty {{9.4.50.v20221201}} - do you have two Jetty
versions installed?
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log, paxweb.trace.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1161#comment-1161
]
Grzegorz Grzybek commented on KARAF-7773:
-
Can you add logs from the time when the WAB is deployed (dropped into
{{deploy/}})? If the logs were at TRACE level it'd be even more helpful.
You said that the listener comes from the WAB, but I see this:
WAB seems to be a bundle with SN=com.example.web.admin.
{noformat}
2023-10-19T08:53:01,655 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerController| 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Receiving Batch{"Undeployment of Web Application "/" for bundle
com.example.web.admin/0.1.0.SNAPSHOT", size=13}
{noformat}
{{ServletContextInitializer}} and {{BaseWebsocketServer}} seems to come from a
bundle with SN=com.example.web.core
{noformat}
2023-10-19T08:53:01,656 | INFO | paxweb-config-1-thread-1 (undeploy /) |
ServletContextInitializer| 82 - com.example.web.core - 0.1.0.SNAPSHOT |
context destroyed
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
BaseWebsocketServer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
context destroyed
{noformat}
am I right?
> WAB ServletContextListener.contextInitialized invoked multiple times during
> re-deploy (and with wrong context)
> --
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
> Attachments: paxweb.log
>
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) WAB ServletContextListener.contextInitialized invoked multiple times during re-deploy (and with wrong context)
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1095#comment-1095
]
Grzegorz Grzybek commented on KARAF-7773:
-
A little analysis (and sorry for a little mislead - if you enable TRACE you'll
get a lot more information. DEBUG just gives you a bit more ;))
Undeployment - I guess you touched the WAB in {{deploy/}}:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
ContextHandler | 409 - org.eclipse.jetty.util -
9.4.50.v20221201 | Stopped
o.o.p.w.s.j.i.PaxWebServletContextHandler@16870d95{Example Admin,/,null,STOPPED}
{noformat}
This is important and related to Whiteboard dynamism - every physical
"ServletContext" may be "managed" by the highest-ranked "OSGi Servlet Context"
and associated "OSGi Context Model". So if you undeploy one, another one takes
the charge. Here, OCM-1 "took over" - this is the default Whiteboard
ServletContextModel:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Changing default OSGi context model for
o.o.p.w.s.j.i.PaxWebServletContextHandler@16870d95{Example Admin,/,null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
OsgiServletContext | 462 - org.ops4j.pax.web.pax-web-spi - 8.0.15
| Registering
OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
as OSGi service for "/" context path
{noformat}
Web elements are removed from "/" because it's being redeployed - OCM-77
stopped being the OSGi Context for "/" which will be replaced by OCM-1. OCM-1
comes from WB (Whiteboard), while OCM-77 was WAB.
{noformat}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
PaxWebServletHandler | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Stopping servlet holder
jsp==org.ops4j.pax.web.jsp.JspServlet@19c47{jsp=null,order=3,inst=false,async=false,src=EMBEDDED:null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet
ServletModel{id=ServletModel-79,name='jsp',urlPatterns=[*.jspx,
*.jsp],servletClass=class
org.ops4j.pax.web.jsp.JspServlet,contexts=[{WAB,OCM-77,/,/}]}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet jsp from context /
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
PaxWebServletHandler | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Stopping servlet holder
default==org.ops4j.pax.web.service.jetty.internal.web.JettyResourceServlet@5c13d641{jsp=null,order=1,inst=false,async=false,src=EMBEDDED:null,STOPPED}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet
ServletModel{id=ServletModel-78,name='default',urlPatterns=[/],contexts=[{WAB,OCM-77,/,/}]}
2023-10-19T08:53:01,657 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removing servlet default from context /
{noformat}
Now "/" servlet context is restarted - this time with OCM-1 being the
highest-ranked:
{noformat}
2023-10-19T08:53:01,657 | INFO | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Starting Jetty context "/" with default Osgi Context
OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}
{noformat}
This is what I was talking about - your filter added by listener is removed:
{noformat}
2023-10-19T08:53:01,658 | DEBUG | paxweb-config-1-thread-1 (undeploy /) |
JettyServerWrapper | 458 - org.ops4j.pax.web.pax-web-jetty -
8.0.15 | Removed 1 dynamically registered servlets/filters/listeners from
context /
{noformat}
The two listeners are called again - BaseWebSocketServer and
ServletContextInitializer from your com.example.web.core bundle
{noformat}
2023-10-19T08:53:01,658 | INFO | paxweb-config-1-thread-1 (undeploy /) |
BaseWebsocketServer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
context initialized
2023-10-19T08:53:01,658 | ERROR | paxweb-config-1-thread-1 (undeploy /) |
BaseWebsocketServer | 82 - com.example.web.core - 0.1.0.SNAPSHOT |
error registering websocket endpoint
2023-10-19T08:53:01,658 | INFO | paxweb-config-1-thread-1 (undeploy /) |
ServletContextInitializer| 82 - com.example.web.core -
[jira] [Assigned] (KARAF-7773) Servlet Filter init invoked (for 2nd time) during undeploy with wrong context
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned KARAF-7773:
---
Assignee: Grzegorz Grzybek
> Servlet Filter init invoked (for 2nd time) during undeploy with wrong context
> -
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (KARAF-7774) ServletContext.getServletContextName() returns wrong value
[
https://issues.apache.org/jira/browse/KARAF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned KARAF-7774:
---
Assignee: Grzegorz Grzybek
> ServletContext.getServletContextName() returns wrong value
> --
>
> Key: KARAF-7774
> URL: https://issues.apache.org/jira/browse/KARAF-7774
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> The ServletContext.getServletContextName() interface javadoc says:
> {noformat}
> Returns the name of this web application corresponding to this ServletContext
> as specified in the deployment descriptor for this web application by the
> display-name element.
> {noformat}
> In my app, I drop into karaf's deploy folder a WAB bundle with a web.xml
> containing only display-name (human-readable string) and listener-class with
> a ServletContextListener implementation class name. The listener's
> contextInitialized method is invoked, but
> event.getServletContext().getServletContextName() returns what appears to be
> the context path (e.g. "/") instead of the display name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) Servlet Filter init invoked (for 2nd time) during undeploy with wrong context
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776776#comment-17776776
]
Grzegorz Grzybek commented on KARAF-7773:
-
[WhiteboardAndHttpServiceTest.java|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/whiteboard/WhiteboardAndHttpServiceTest.java]
shows how complex it is to interact between HttpService and Whiteboard.
[AbstractWabWhiteboardConflictIntegrationTest.java|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/war/AbstractWabWhiteboardConflictIntegrationTest.java]
shows the mixture of WAB + Whiteboard.
[AbstractWabHttpServiceConflictIntegrationTest.java|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/war/AbstractWabHttpServiceConflictIntegrationTest.java]
shows the mixture of WAB + HttpService.
> Servlet Filter init invoked (for 2nd time) during undeploy with wrong context
> -
>
> Key: KARAF-7773
> URL: https://issues.apache.org/jira/browse/KARAF-7773
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Priority: Major
>
> When touching a WAB bundle with a context listener as described belower, the
> undeploy/deploy cycle, instead of just invoking destroy on the old context
> and initialize on the new one, seems to destroy the old one, re-initialize
> the old one (with the wrong "whiteboard extender" context), destroy it again,
> initialize the new one (with correct context), and initialize the old one
> once more (but without the filter init).
> I'll describe my full scenario, even though it's possible the issue can be
> reproduced with a simpler setup:
> I have an application consisting of multiple bundles in the karaf deploy
> folder. One of them is a WAB. It's web.xml only contains display-name and
> listener-class with a ServletContextListener. The listener contextInitialized
> implementation instantiates a custom Filter, whose class is imported from a
> different app bundle:
> {code:java}
> Filter filter = new MyFilter();
> context.addFilter("MyFilter", filter)
> .addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST,
> DispatcherType.FORWARD), true, "/*");
> {code}
> The filter's init method is invoked successfully and all is good.
> Then, I update/touch the WAB bundle in the deploy folder.
> This causes a thread named "paxweb-config-3-thread-1 (undeploy /)" to call
> the listener's contextDestroyed method as expected, but then it also
> immediately calls the contextInitialized method again (still from the
> undeploy thread, and still the same old listener instance), this time with
> the servlet context of the pax-web-extender-whiteboard rather than the WAB
> bundle. It creates another filter instance, whose init method gets invoked
> with the pax-web-extender-whiteboard context as well (my init implementation
> throws an exception at this point when the context is wrong, resources aren't
> found etc.).
> Then a thread named "paxweb-config-3-thread-1 (deploy /)" (notice undeploy
> changed to deploy) calls contextDestroyed, still with the extender context.
> Finally, a new listener instance is craeted, contextInitialized is invoked
> again, this time with the correct WAB context, followed by the filter's init
> method. In addition, the old listener instance (which should be dead by now)
> contextInitialized also gets invoked again, but not followed by the filter
> init (maybe because it previously threw an exception on it? just guessing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7773) Servlet Filter init invoked (for 2nd time) during undeploy with wrong context
[
https://issues.apache.org/jira/browse/KARAF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776774#comment-17776774
]
Grzegorz Grzybek commented on KARAF-7773:
-
[Whiteboard Specification
warns|https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.http.whiteboard.html#d0e89744]:
{quote}
To deal with the dynamicity of the Whiteboard service lifecycle, it is
recommended to implement a servlet filter as Prototype Service Factory service.
This will ensure that one single servlet filter instance only receives one init
and one destroy call. Otherwise a single servlet filter instance can receive
multiple such calls. This is similar to the behavior recommended for Servlet
Whiteboard services.
{quote}
So please set DEBUG level to {{org.ops4j.pax.web}} logger and you'll see a lot
of information about deployment/undeployment of elements and contexts - trust
me, I spent >3 years implementing it and I'm 94% sure I got it right ;)
See for example [this test's
comment|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/whiteboard/WhiteboardBasicTest.java#L178-L214]:
{code:java}
// Filters are a bit problematic. When new filter is registered, it has to be
added to server's internal
// structures in correct order (web.xml order in JavaEE and service rank order
in OSGi Whiteboard).
// If simply new filter is registered, ONLY if this filter should be added
last, we can attempt optimized
// registration. Otherwise, we have to recreate the filter list, which SHOULD
lead to destroy() + init()
// of these filters again.
// Additionally, in Undertow we can't simply remove existing filters without
recreating entire "context"
// (ServletContext) created in DeploymentManagerImpl.deploy() and put into
DeploymentImpl. So even when
// adding single servlet, we have to recreate everything which usually leads to
destroy() + init() for
// each servlet of the context
// In Tomcat and Jetty, we can freely and independently operate on servlets and
filters and nothing in any
// specification prevents us from doing so
//
// - In Jetty, reinitialization is done in
org.eclipse.jetty.servlet.ServletHandler.updateMappings() called
//from org.eclipse.jetty.servlet.ServletHandler.setFilterMappings()
/*
* 2020-06-01 (no destroy() for filters in Jetty, Undertow is less flexible (!)
than Jetty and Tomcat)
* Jetty:
* [reg(s1), s1.init(), reg(f1), f1.init(), reg(f2),
f1.init(), f2.init(),unreg(f2),
f1.init(),unreg(s1), s1.destroy(),
unreg(f1) ]
* Tomcat:
* [reg(s1), s1.init(), reg(f1), f1.init(), reg(f2),
f1.destroy(), f1.init(), f2.init(),unreg(f2), f1.destroy(),
f2.destroy(), f1.init(),unreg(s1), s1.destroy(),
unreg(f1), f1.destroy()]
* Undertow:
* [reg(s1), s1.init(), reg(f1), s1.destroy(), f1.init(), reg(f2),
f1.destroy(), f1.init(), f2.init(), s1.init(), unreg(f2), s1.destroy(),
f1.destroy(), f2.destroy(), f1.init(), s1.init(), unreg(s1), s1.destroy(),
f1.destroy(), f1.init(), unreg(f1), f1.destroy()]
*/
/*
* 2020-06-02 (Jetty filters are destroyed, optimization for filter addition)
* Jetty:
* - non optimized: [reg(s1), s1.init(), reg(f1), f1.init(),
reg(f2), f1.destroy(), f1.init(), f2.init(),unreg(f2),
f1.destroy(), f2.destroy(), f1.init(),unreg(s1),
s1.destroy(), unreg(f1), f1.destroy()]
* - optimized: [reg(s1), s1.init(), reg(f1), f1.init(),
reg(f2), f2.init(),unreg(f2),
f1.destroy(), f2.destroy(), f1.init(),unreg(s1),
s1.destroy(), unreg(f1), f1.destroy()]
* Tomcat:
* - non optimized: [reg(s1), s1.init(), reg(f1), f1.init(),
reg(f2), f1.destroy(), f1.init(), f2.init(),unreg(f2),
f1.destroy(), f2.destroy(), f1.init(),unreg(s1),
s1.destroy(), unreg(f1), f1.destroy()]
* - no optimization possible
* Undertow:
* - non optimized: [reg(s1), s1.init(), reg(f1), s1.destroy(), f1.init(),
reg(f2), f1.destroy(), f1.init(), f2.init(), s1.init(), unreg(f2),
s1.destroy(), f1.destroy(), f2.destroy(), f1.init(), s1.init(), unreg(s1),
s1.destroy(), f1.destroy(), f1.init(), unreg(f1), f1.destroy()]
* - optimized: [reg(s1), s1.init(), reg(f1), f1.init(),
reg(f2), f2.init(),unreg(f2),
s1.destroy(), f1.destroy(), f2.destroy(), f1.init(), s1.init(), unreg(s1),
s1.destroy(), f1.destroy(), f1.init(), unreg(f1), f1.destroy()]
*/
{code}
> Servlet Filter init invoked (for 2nd time) during undeploy with
[jira] [Commented] (KARAF-7774) ServletContext.getServletContextName() returns wrong value
[
https://issues.apache.org/jira/browse/KARAF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776767#comment-17776767
]
Grzegorz Grzybek commented on KARAF-7774:
-
Mind that in [Whiteboard
Specification|https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.http.whiteboard.html#d0e88397]
we have:
{quote}
140.2.6 Behavior of the Servlet Context
getServletContextName() - The name of the {{ServletContextHelper}} provided via
the {{osgi.http.whiteboard.context.name}} service property.
{quote}
So Pax Web [implements it
with|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-spi/src/main/java/org/ops4j/pax/web/service/spi/servlet/OsgiServletContext.java#L801]:
{code:java}
@Override
public String getServletContextName() {
return osgiContextModel.getName();
}
{code}
But you are right - it should be {{}} when in WAB. And now I [set
it to
contextpath|https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.22/pax-web-spi/src/main/java/org/ops4j/pax/web/service/spi/model/ServerModel.java#L1341-L1343]:
{code:java}
// do NOT use "default" as the name of the context, so it's NOT matched by
//
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=default)
ocm.setName(contextPath);
{code}
I should simply (one of these - I'll check tomorrow):
{noformat}
---
a/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/model/BundleWebApplication.java
+++
b/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/model/BundleWebApplication.java
@@ -1296,6 +1296,9 @@ public class BundleWebApplication {
// we simply take the allocated (and associated with our bundle
and our bundle's Web-ContextPath) context
final OsgiContextModel ocm = allocatedOsgiContextModel;
+ ocm.setName(mainWebXml.getName());
+ ocm.setName(mainWebXml.getDisplayName());
+
ocm.setWab(true);
ocm.setServiceId(0);
ocm.setServiceRank(Integer.MAX_VALUE);
{noformat}
> ServletContext.getServletContextName() returns wrong value
> --
>
> Key: KARAF-7774
> URL: https://issues.apache.org/jira/browse/KARAF-7774
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.3
>Reporter: Amichai Rothman
>Priority: Major
>
> The ServletContext.getServletContextName() interface javadoc says:
> {noformat}
> Returns the name of this web application corresponding to this ServletContext
> as specified in the deployment descriptor for this web application by the
> display-name element.
> {noformat}
> In my app, I drop into karaf's deploy folder a WAB bundle with a web.xml
> containing only display-name (human-readable string) and listener-class with
> a ServletContextListener implementation class name. The listener's
> contextInitialized method is invoked, but
> event.getServletContext().getServletContextName() returns what appears to be
> the context path (e.g. "/") instead of the display name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7769) Karaf webconsole plugins don't work since Felix WebConsole update
[
https://issues.apache.org/jira/browse/KARAF-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770970#comment-17770970
]
Grzegorz Grzybek commented on KARAF-7769:
-
It's a problem during installation:
{noformat}
Unable to resolve webconsole/4.4.4: missing requirement [webconsole/4.4.4]
osgi.implementation; osgi.implementation=osgi.http; version:Version=1.1.0
{noformat}
But when I first install e.g., {{pax-web-http-tomcat}}, {{webconsole}} installs
fine.
> Karaf webconsole plugins don't work since Felix WebConsole update
> -
>
> Key: KARAF-7769
> URL: https://issues.apache.org/jira/browse/KARAF-7769
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.4
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix WebConsole has been updated in Karaf 4.4.4, updating the servlet spec
> API required.
> This causes the Karaf WebConsole plugins (features, gogo, ...) fail to start:
> {code:java}
> 07:26:56.624 WARN [qtp1879306377-252]
> /system/console/http/res/ui/http-contexts.js
> java.lang.IllegalStateException: ServletConfig has not been initialized
> at
> javax.servlet.GenericServlet.getServletContext(GenericServlet.java:145)
> ~[!/:4.0.4]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource0(AbstractWebConsolePlugin.java:603)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin$1.run(AbstractWebConsolePlugin.java:538)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin$1.run(AbstractWebConsolePlugin.java:534)
> ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource(AbstractWebConsolePlugin.java:533)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:193)
> ~[?:?]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:497)
> ~[!/:4.0.4]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:584)
> ~[!/:4.0.4]
> at
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:612)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.doService(KarafOsgiManager.java:79)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.lambda$service$0(KarafOsgiManager.java:56)
> ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:116)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.service(KarafOsgiManager.java:55)
> ~[?:?]
> at
> org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656)
> ~[?:?]
> at
> org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100)
> ~[?:?]
> at
> org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:320)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
[jira] [Commented] (KARAF-7769) Karaf webconsole plugins don't work since Felix WebConsole update
[
https://issues.apache.org/jira/browse/KARAF-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770813#comment-17770813
]
Grzegorz Grzybek commented on KARAF-7769:
-
Pax Web has itests with Felix web console, but probably not with latest
version. I'll check it tomorrow.
> Karaf webconsole plugins don't work since Felix WebConsole update
> -
>
> Key: KARAF-7769
> URL: https://issues.apache.org/jira/browse/KARAF-7769
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.4
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix WebConsole has been updated in Karaf 4.4.4, updating the servlet spec
> API required.
> This causes the Karaf WebConsole plugins (features, gogo, ...) fail to start:
> {code:java}
> 07:26:56.624 WARN [qtp1879306377-252]
> /system/console/http/res/ui/http-contexts.js
> java.lang.IllegalStateException: ServletConfig has not been initialized
> at
> javax.servlet.GenericServlet.getServletContext(GenericServlet.java:145)
> ~[!/:4.0.4]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource0(AbstractWebConsolePlugin.java:603)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin$1.run(AbstractWebConsolePlugin.java:538)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin$1.run(AbstractWebConsolePlugin.java:534)
> ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource(AbstractWebConsolePlugin.java:533)
> ~[?:?]
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:193)
> ~[?:?]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:497)
> ~[!/:4.0.4]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:584)
> ~[!/:4.0.4]
> at
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:612)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.doService(KarafOsgiManager.java:79)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.lambda$service$0(KarafOsgiManager.java:56)
> ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:116)
> ~[?:?]
> at
> org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.service(KarafOsgiManager.java:55)
> ~[?:?]
> at
> org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450)
> ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[?:?]
> at
> org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656)
> ~[?:?]
> at
> org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100)
> ~[?:?]
> at
> org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:320)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
> ~[?:?]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
> ~[?:?]
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[!/:9.4.52.v20230823]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
> ~[!/:9.4.52.v20230823]
> at
>
[jira] [Commented] (KARAF-6074) Race condition between the FeaturesService and FeatureDeploymentListener
[
https://issues.apache.org/jira/browse/KARAF-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728290#comment-17728290
]
Grzegorz Grzybek commented on KARAF-6074:
-
PR: https://github.com/apache/karaf/pull/1720
> Race condition between the FeaturesService and FeatureDeploymentListener
>
>
> Key: KARAF-6074
> URL: https://issues.apache.org/jira/browse/KARAF-6074
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2, 4.2.4
> Environment: Karaf 4.2.2 Windows 7 and Equinox
>Reporter: J. Brébec
>Priority: Critical
>
> On the first start of a custom Karaf container (4.2.2), the logs shows a log
> of NPE in FeatureDeploymentListener.
> After some analysis of this Exception, it's look like a race condition
> between the FeaturesService and the FeatureDeploymentListener :
> # The FeaturesService starts and launch a provisioning in another thread
> # a FeatureDeploymentListener is registered, and call bundleChanged for
> every bundle installed (the startup bundles)
> # It calls FeaturesService.state.requirements and get an empty map
> # Updating the root regions in the requirements map fails with an NPE
> # Some times later, the deployment task launched at step 1 is started, and
> FeaturesService.saveState() is called : state.requirements."root region" is
> initialised
> The step 5 is executed in another thread, so it can happens before step 2
> (and it works) or after, causing this NPE
> Moreover, some methods in FeaturesService assume that
> state.requirements."root region" exists. There are probably others npe here.
>
> {code:java}
> 14:37:55.668 ERROR [activator-1-thread-2] Unable to update deployed features
> for bundle: org.eclipse.osgi - 3.12.100.v20180210-1608
> java.lang.NullPointerException: null
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:95)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:52)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:292)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-6074) Race condition between the FeaturesService and FeatureDeploymentListener
[
https://issues.apache.org/jira/browse/KARAF-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728285#comment-17728285
]
Grzegorz Grzybek commented on KARAF-6074:
-
The {{~}} is something new in Config Admin spec 1.6 (CMPN R7) and is related to
new methods in {{org.osgi.service.cm.ConfigurationAdmin}} interface:
{code:java}
org.osgi.service.cm.ConfigurationAdmin.getFactoryConfiguration(String
factoryPid, String name, String location)
{code}.
Javadoc says:
{quote}
The PID for this Configuration object is generated from the provided factory
PID and the name by starting with the factory PID appending a tilde ('~'
\u007E), and then appending the name.
{quote}
And this is exactly what
{{org.apache.felix.cm.impl.ConfigurationAdminImpl#getFactoryConfiguration(java.lang.String,
java.lang.String)}} is doing (felix.configadmin 1.9.26:
{code:java}
final String pid = factoryPid + '~' + name;
{code}
FactoryPid itself should _not_ contain a dash, although the spec doesn't say
anything (?) about it. At least I didn't find anything.
felix.fileinstall's
{{org.apache.felix.fileinstall.internal.ConfigInstaller#parsePid()}} has:
{code:java}
String pid = path.substring(0, path.lastIndexOf('.'));
int n = pid.indexOf('-');
if (n > 0)
{
String factoryPid = pid.substring(n + 1);
pid = pid.substring(0, n);
return new String[]
{
pid, factoryPid
};
}
else
{
return new String[]
{
pid, null
};
}
{code}
So for:
{code:xml}
{code}
the related configuration file should be
{{etc/org.apache.karaf.example.config-abc.cfg}} and felix.fileinstall would
create:
{code:java}
new String[] { "org.apache.karaf.example.config", "abc" }
{code}
then
{{org.apache.felix.fileinstall.internal.ConfigInstaller#getConfiguration()}}
would detect ({{pid[1] != null}}) that this new method from cm 1.6 should be
called with these parameters
{code:java}
org.osgi.service.cm.ConfigurationAdmin#getFactoryConfiguration("org.apache.karaf.example.config",
"abc", "?")
{code}
Then pid would be {{org.apache.karaf.example.config~abc}} and if the config is
new, this method would be called with these parameters:
{code:java}
org.apache.felix.cm.impl.ConfigurationManager#createFactoryConfiguration("org.apache.karaf.example.config~abc",
"org.apache.karaf.example.config", "?")
{code}
When config.xml file is dropped to {{deploy/}}, the first relevant method
called is
{{org.apache.karaf.features.internal.service.FeatureConfigInstaller#installFeatureConfigs()}}
- no configadmin or fileinstall is involved yet.
* ConfigId#pid is set to {{org.apache.karaf.example.config-abc}}
* n == 31 because of {{pid.contains("~") ? pid.indexOf('~') : pid.indexOf('-')}}
* ConfigId#isFactoryPid is set to true
* ConfigId#factoryPid is set to {{org.apache.karaf.example.config}}
* ConfigId#name stays null, because there's no {{~}} and this may be a problem
cfgFile is set to
{{/data/servers/apache-karaf-4.4.4-SNAPSHOT/etc/org.apache.karaf.example.config-abc.cfg}}
(_full_ pid)
Because {{ConfigId#name}} is null,
{{org.osgi.service.cm.ConfigurationAdmin#createFactoryConfiguration(factoryPid,
location)}} is called instead of
{{org.osgi.service.cm.ConfigurationAdmin#getFactoryConfiguration(factoryPid,
name, location)}}.
org.apache.felix.cm.impl.ConfigurationManager#createPid() returns random PID
based on factory PID. In my case:
{{org.apache.karaf.example.config.11346460-6c07-4dcb-b1e9-8b6e71bda0b9}}
in {{org.apache.felix.cm.impl.ConfigurationImpl#ConfigurationImpl()}}:
{noformat}
this.basePID: {org.apache.felix.cm.impl.helper.TargetedPID@8022}
"org.apache.karaf.example.config.11346460-6c07-4dcb-b1e9-8b6e71bda0b9"
this.factoryPID = {org.apache.felix.cm.impl.helper.TargetedPID@8023}
"org.apache.karaf.example.config"
{noformat}
{{org.apache.felix.cm.impl.ConfigurationImpl#storeNewConfiguration()}} is not
called (because it's factory pid).
Karaf's FeatureConfigInstaller continues to operate on:
{noformat}
cfg = {org.apache.felix.cm.impl.ConfigurationAdapter@8033} "Configuration
PID=org.apache.karaf.example.config.11346460-6c07-4dcb-b1e9-8b6e71bda0b9,
factoryPID=org.apache.karaf.example.config, bundleLocation=null"
configurationAdmin: org.apache.felix.cm.impl.ConfigurationAdminImpl =
{org.apache.felix.cm.impl.ConfigurationAdminImpl@7907}
delegatee: org.apache.felix.cm.impl.ConfigurationImpl =
{org.apache.felix.cm.impl.ConfigurationImpl@8021} "Configuration
PID=org.apache.karaf.example.config.11346460-6c07-4dcb-b1e9-8b6e71bda0b9,
factoryPID=org.apache.karaf.example.config, bundleLocation=null"
baseId: org.apache.felix.cm.impl.helper.TargetedPID =
{org.apache.felix.cm.impl.helper.TargetedPID@8022}
"org.apache.karaf.example.config.11346460-6c07-4dcb-b1e9-8b6e71bda0b9"
configurationManager: org.apache.felix.cm.impl.ConfigurationManager =
{org.apache.felix.cm.impl.ConfigurationManager@8017}
[jira] [Commented] (KARAF-6074) Race condition between the FeaturesService and FeatureDeploymentListener
[
https://issues.apache.org/jira/browse/KARAF-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728256#comment-17728256
]
Grzegorz Grzybek commented on KARAF-6074:
-
Continuing the discussion from
https://lists.apache.org/thread/cq4v9x0lf0k6onkghtkjc9gpjnwrj2db
cc: [~jbonofre]
> Race condition between the FeaturesService and FeatureDeploymentListener
>
>
> Key: KARAF-6074
> URL: https://issues.apache.org/jira/browse/KARAF-6074
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2, 4.2.4
> Environment: Karaf 4.2.2 Windows 7 and Equinox
>Reporter: J. Brébec
>Priority: Critical
>
> On the first start of a custom Karaf container (4.2.2), the logs shows a log
> of NPE in FeatureDeploymentListener.
> After some analysis of this Exception, it's look like a race condition
> between the FeaturesService and the FeatureDeploymentListener :
> # The FeaturesService starts and launch a provisioning in another thread
> # a FeatureDeploymentListener is registered, and call bundleChanged for
> every bundle installed (the startup bundles)
> # It calls FeaturesService.state.requirements and get an empty map
> # Updating the root regions in the requirements map fails with an NPE
> # Some times later, the deployment task launched at step 1 is started, and
> FeaturesService.saveState() is called : state.requirements."root region" is
> initialised
> The step 5 is executed in another thread, so it can happens before step 2
> (and it works) or after, causing this NPE
> Moreover, some methods in FeaturesService assume that
> state.requirements."root region" exists. There are probably others npe here.
>
> {code:java}
> 14:37:55.668 ERROR [activator-1-thread-2] Unable to update deployed features
> for bundle: org.eclipse.osgi - 3.12.100.v20180210-1608
> java.lang.NullPointerException: null
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:95)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:52)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:292)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-6501) Restoring the wiring of fragment bundles with multiple hosts
[
https://issues.apache.org/jira/browse/KARAF-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691148#comment-17691148
]
Grzegorz Grzybek commented on KARAF-6501:
-
I fixed this by ensuring that exported packages are not imported.
> Restoring the wiring of fragment bundles with multiple hosts
>
>
> Key: KARAF-6501
> URL: https://issues.apache.org/jira/browse/KARAF-6501
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.3.0, 4.2.7
>Reporter: Nelson Antunes
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0, 4.2.8
>
> Attachments: example-1.0-SNAPSHOT.kar
>
>
> The {{StoredWiringResolver}}'s bundle wiring cache assumes each requirement
> is only wired to a single capability. This isn't true for
> {{osgi.wiring.host}} requirements as fragments can attach to multiple hosts.
> It is storing only the last wiring it comes across, resulting in the loss of
> the other wirings when booting with hot caches.
> Steps to reproduce:
> *1. Start a clean karaf*
> {noformat}
> $ bin/karaf
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.7)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State │ Lvl │ Version │ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> {noformat}
> *2. Install a fragment bundle and install and start two or more bundles that
> satisfies the fragment's Fragment-Host requirement*
> You can use the attached {{example-1.0-SNAPSHOT.kar}} file. Put it in the
> {{deploy}} folder and it will install a fragment bundle and three hosts:
> {noformat}
> Starting the host 2
> Starting the host 1
> Starting the host 3
> {noformat}
> *3. Check that the bundles are correctly installed and the fragment is
> attached to all three hosts*
> {noformat}
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State│ Lvl │ Version│ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> 44 │ Resolved │ 80 │ 1.0.0.SNAPSHOT │ fragment Bundle, Hosts: 47, 46, 45
> 45 │ Active │ 80 │ 1.0.0 │ host1 Bundle, Fragments: 44
> 46 │ Active │ 80 │ 1.5.0 │ host2 Bundle, Fragments: 44
> 47 │ Active │ 80 │ 2.0.0 │ host3 Bundle, Fragments: 44
> {noformat}
> *4. However, notice that the wiring cache of the fragment bundle (44) isn't
> right*
> {noformat}
> $ cat data/cache/bundle0/wiring/44
> osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))
> 0; version=[1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0]
> osgi.wiring.host; (&(osgi.wiring.host=our-host)(bundle-version>=0.0.0))
> 45
> {noformat}
> *5. Stop karaf*
> {noformat}
> karaf@root()> ^D
> Stopping the host 3
> Stopping the host 2
> Stopping the host 1
> {noformat}
> *6. Start karaf with hot caches*
> {noformat}
> $ bin/karaf
> org.ops4j.pax.url.wrap [org.ops4j.pax.url.commons.handler.HandlerActivator]
> DEBUG : Handler for protocols [wrap] started
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.7)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> Starting the host 1
> Starting the host 2
> Starting the host 3
> {noformat}
> *7. Check that the fragment is no longer correctly attached to all three
> hosts, but just to one*
> {noformat}
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State│ Lvl │ Version│ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> 44 │ Resolved │ 80 │ 1.0.0.SNAPSHOT │ fragment Bundle, Hosts: 45
> 45 │ Active │ 80 │ 1.0.0 │ host1 Bundle, Fragments: 44
> 46 │ Active │ 80 │ 1.5.0 │ host2 Bundle
> 47 │ Active │ 80 │ 2.0.0 │ host3 Bundle
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-6501) Restoring the wiring of fragment bundles with multiple hosts
[
https://issues.apache.org/jira/browse/KARAF-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691146#comment-17691146
]
Grzegorz Grzybek commented on KARAF-6501:
-
After another refresh (to wire pax-web-tomcat host and
pax-web-tomcat-keycloak18 fragment),
{{org.apache.karaf.features.extension.StoredWiringResolver#update()}} is called
for the fragment, storing this:
{noformat}
osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))
0; version=[1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0,
9.0.0, 10.0.0, 11.0.0]
osgi.wiring.host;
(&(osgi.wiring.host=org.ops4j.pax.web.pax-web-tomcat)(bundle-version>=0.0.0))
135
{noformat}
and for the host - however for the host, only these requirements are stored:
{noformat}
wiring: java.util.Map = {java.util.HashMap@13830} size = 79
{@13912} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.enums)(version>=18.0.0)(!(version>=19.0.0)))"
-> {java.util.HashSet@13913} size = 1
{@13920} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak)(version>=18.0.0)(!(version>=19.0.0)))" ->
{java.util.HashSet@13921} size = 1
{@13928} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.adapters)(version>=18.0.0)(!(version>=19.0.0)))"
-> {java.util.HashSet@13929} size = 1
{@14016} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.representations)(version>=18.0.0)(!(version>=19.0.0)))"
-> {java.util.HashSet@14017} size = 1
{@14032} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.adapters.spi)(version>=18.0.0)(!(version>=19.0.0)))"
-> {java.util.HashSet@14033} size = 1
{@14048} "osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.common.util)(version>=18.0.0)(!(version>=19.0.0)))"
-> {java.util.HashSet@14049} size = 1
{noformat}
because self reference (for {{org.keycloak.adapters.tomcat}} package) is not
present among the wires of host+fragment...
> Restoring the wiring of fragment bundles with multiple hosts
>
>
> Key: KARAF-6501
> URL: https://issues.apache.org/jira/browse/KARAF-6501
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.3.0, 4.2.7
>Reporter: Nelson Antunes
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0, 4.2.8
>
> Attachments: example-1.0-SNAPSHOT.kar
>
>
> The {{StoredWiringResolver}}'s bundle wiring cache assumes each requirement
> is only wired to a single capability. This isn't true for
> {{osgi.wiring.host}} requirements as fragments can attach to multiple hosts.
> It is storing only the last wiring it comes across, resulting in the loss of
> the other wirings when booting with hot caches.
> Steps to reproduce:
> *1. Start a clean karaf*
> {noformat}
> $ bin/karaf
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.7)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State │ Lvl │ Version │ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> {noformat}
> *2. Install a fragment bundle and install and start two or more bundles that
> satisfies the fragment's Fragment-Host requirement*
> You can use the attached {{example-1.0-SNAPSHOT.kar}} file. Put it in the
> {{deploy}} folder and it will install a fragment bundle and three hosts:
> {noformat}
> Starting the host 2
> Starting the host 1
> Starting the host 3
> {noformat}
> *3. Check that the bundles are correctly installed and the fragment is
> attached to all three hosts*
> {noformat}
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State│ Lvl │ Version│ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> 44 │ Resolved │ 80 │ 1.0.0.SNAPSHOT │ fragment Bundle, Hosts: 47, 46, 45
> 45 │ Active │ 80 │ 1.0.0 │ host1 Bundle, Fragments: 44
> 46 │ Active │ 80 │ 1.5.0 │ host2 Bundle, Fragments: 44
> 47 │ Active │ 80 │ 2.0.0 │ host3 Bundle, Fragments: 44
> {noformat}
> *4. However, notice that the wiring cache of the fragment bundle (44) isn't
> right*
> {noformat}
> $ cat data/cache/bundle0/wiring/44
> osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))
> 0; version=[1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0]
> osgi.wiring.host; (&(osgi.wiring.host=our-host)(bundle-version>=0.0.0))
> 45
> {noformat}
> *5. Stop karaf*
> {noformat}
> karaf@root()> ^D
> Stopping the host 3
> Stopping the host 2
> Stopping the host 1
> {noformat}
> *6. Start karaf with hot caches*
> {noformat}
> $
[jira] [Commented] (KARAF-6501) Restoring the wiring of fragment bundles with multiple hosts
[
https://issues.apache.org/jira/browse/KARAF-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691143#comment-17691143
]
Grzegorz Grzybek commented on KARAF-6501:
-
The problem is that when Karaf restarts again ({{main}} thread):
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.karaf.features.extension.StoredWiringResolver.filterMatches(StoredWiringResolver.java:89)
at
org.apache.felix.framework.util.SecureAction.invokeResolverHookMatches(SecureAction.java:1630)
at
org.apache.felix.framework.StatefulResolver.findProvidersInternal(StatefulResolver.java:339)
- locked <0x60e> (a org.apache.felix.framework.StatefulResolver)
at
org.apache.felix.framework.ResolveContextImpl.findProviders(ResolveContextImpl.java:114)
at org.apache.felix.resolver.Candidates.populate(Candidates.java:208)
at
org.apache.felix.resolver.ResolverImpl.getInitialCandidates(ResolverImpl.java:542)
at
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:431)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:420)
at
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:374)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:488)
at org.apache.felix.framework.Felix.resolveBundles(Felix.java:4357)
at
org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:130)
at
org.apache.karaf.features.extension.Activator.resolveAll(Activator.java:62)
at
org.apache.karaf.features.extension.Activator.bundleChanged(Activator.java:49)
at
org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
at
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at
org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
at org.apache.felix.framework.Felix.start(Felix.java:1143)
at org.apache.karaf.main.Main.launch(Main.java:297)
at org.apache.karaf.main.Main.main(Main.java:183)
{noformat}
there's an attempt to process this requirement:
{noformat}
requirement = {org.apache.felix.framework.wiring.BundleRequirementImpl@4712}
"[org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.keycloak.adapters.tomcat)(version>=18.0.0)(!(version>=19.0.0)))"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4733} size = 0
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4732} size = 1
m_filter: org.apache.felix.framework.capabilityset.SimpleFilter =
{org.apache.felix.framework.capabilityset.SimpleFilter@4731}
"(&(osgi.wiring.package=org.keycloak.adapters.tomcat)(version>=18.0.0)(!(version>=19.0.0)))"
m_namespace: java.lang.String = {@4723} "osgi.wiring.package"
m_optional: boolean = false
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.BundleRevisionImpl@4189}
"org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)"
{noformat}
with found capability:
{noformat}
result = {org.apache.felix.framework.util.ShrinkableCollection@4715} size = 1
0 = {org.apache.felix.framework.wiring.BundleCapabilityImpl@4721}
"[org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)]
osgi.wiring.package;
{bundle-symbolic-name=org.ops4j.pax.web.pax-web-tomcat-keycloak18,
bundle-version=8.0.15, osgi.wiring.package=org.keycloak.adapters.tomcat,
version=18.0.3}"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4725} size
= 4
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4724} size =
1
m_mandatory: java.util.Set = {java.util.Collections$EmptySet@4727} size = 0
m_namespace: java.lang.String = {@4723} "osgi.wiring.package"
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.BundleRevisionImpl@4189}
"org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)"
m_uses: java.util.List = {java.util.ArrayList@4726} size = 8
{noformat}
when there's no {{org.apache.karaf.features.extension.BundleWires#wiring}} for
host bundle for this requirement:
{noformat}
(&(osgi.wiring.package=org.keycloak.adapters.tomcat)(version>=18.0.0)(!(version>=19.0.0)))
{noformat}
This comes from the fragment itself, where the same package is exported and
imported ({{org.keycloak.adapters.osgi.tomcat}}):
{noformat}
karaf@root()> headers 97
OPS4J Pax Web - Keycloak 18.x support - Tomcat (97)
---
Bnd-LastModified = 1676300516142
Build-Jdk-Spec = 1.8
Created-By = Apache Maven Bundle Plugin 5.1.8
Fragment-Host = org.ops4j.pax.web.pax-web-tomcat
[jira] [Comment Edited] (KARAF-6501) Restoring the wiring of fragment bundles with multiple hosts
[
https://issues.apache.org/jira/browse/KARAF-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691138#comment-17691138
]
Grzegorz Grzybek edited comment on KARAF-6501 at 2/20/23 11:18 AM:
---
[~jbonofre] [~nantunes] I have a problem here...
I have a bundle (pax-web-tomcat) and a fragment (pax-web-tomcat-keycloak18 -
work in progress) which adds new {{Import-Package}} headers to pax-web-tomcat.
However even if the host+fragment is fine after installation, the host-fragment
relation is gone after restart.
The fragment's requirement being resolved is:
{noformat}
requirement = {org.apache.felix.framework.wiring.BundleRequirementImpl@4233}
"[org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)]
osgi.wiring.package; (osgi.wiring.package=javax.security.cert)"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4897} size = 1
m_filter: org.apache.felix.framework.capabilityset.SimpleFilter =
{org.apache.felix.framework.capabilityset.SimpleFilter@4256}
"(osgi.wiring.package=javax.security.cert)"
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
m_optional: boolean = false
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.BundleRevisionImpl@4189}
"org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)"
{noformat}
The selected candidate in
{{org.apache.karaf.features.extension.BundleWires#filterCandidates()}} is fine:
{noformat}
candidates = {org.apache.felix.framework.util.ShrinkableCollection@4294} size
= 1
0 = {org.apache.felix.framework.wiring.BundleCapabilityImpl@4262}
"[org.apache.felix.framework [0](R 0)] osgi.wiring.package;
{bundle-symbolic-name=[Ljava.lang.String;@767e20cf, bundle-version=7.0.5,
version=0.0.0, osgi.wiring.package=javax.security.cert}"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4892} size
= 4
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_mandatory: java.util.Set = {java.util.Collections$EmptySet@4882} size = 0
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.ExtensionManager$ExtensionManagerRevision@1496}
"org.apache.felix.framework [0](R 0)"
m_uses: java.util.List = {java.util.Collections$EmptyList@4893} size = 0
{noformat}
However, the candidate is flitered out because
{{org.apache.karaf.features.extension.BundleWires#wiring}} doesn't contain a
requirement ID {{osgi.wiring.package;
(osgi.wiring.package=javax.security.cert)}}...
After refreshing pax-web-tomcat bundle the fragment is attached and this (among
others) information is added to {{$KARAF_HOME/data/cache/bundle0/wiring/135}}:
{noformat}
osgi.wiring.package; (osgi.wiring.package=javax.security.cert)
0; version=0.0.0
{noformat}
was (Author: gzres):
[~jbonofre] [~nantunes] I have a problem here...
I have a bundle (pax-web-tomcat) and a fragment (pax-web-tomcat-keycloak18 -
work in progress) which adds new {{Import-Package}} headers to pax-web-tomcat.
However even if the host+fragment is fine after installation, the host-fragment
relation is gone after restart.
The fragment's requirement being resolved is:
{noformat}
requirement = {org.apache.felix.framework.wiring.BundleRequirementImpl@4233}
"[org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)]
osgi.wiring.package; (osgi.wiring.package=javax.security.cert)"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4897} size = 1
m_filter: org.apache.felix.framework.capabilityset.SimpleFilter =
{org.apache.felix.framework.capabilityset.SimpleFilter@4256}
"(osgi.wiring.package=javax.security.cert)"
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
m_optional: boolean = false
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.BundleRevisionImpl@4189}
"org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)"
{noformat}
The selected candidate in
{{org.apache.karaf.features.extension.BundleWires#filterCandidates()}} is fine:
{noformat}
candidates = {org.apache.felix.framework.util.ShrinkableCollection@4294} size
= 1
0 = {org.apache.felix.framework.wiring.BundleCapabilityImpl@4262}
"[org.apache.felix.framework [0](R 0)] osgi.wiring.package;
{bundle-symbolic-name=[Ljava.lang.String;@767e20cf, bundle-version=7.0.5,
version=0.0.0, osgi.wiring.package=javax.security.cert}"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4892} size
= 4
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_mandatory: java.util.Set = {java.util.Collections$EmptySet@4882} size = 0
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
[jira] [Commented] (KARAF-6501) Restoring the wiring of fragment bundles with multiple hosts
[
https://issues.apache.org/jira/browse/KARAF-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691138#comment-17691138
]
Grzegorz Grzybek commented on KARAF-6501:
-
[~jbonofre] [~nantunes] I have a problem here...
I have a bundle (pax-web-tomcat) and a fragment (pax-web-tomcat-keycloak18 -
work in progress) which adds new {{Import-Package}} headers to pax-web-tomcat.
However even if the host+fragment is fine after installation, the host-fragment
relation is gone after restart.
The fragment's requirement being resolved is:
{noformat}
requirement = {org.apache.felix.framework.wiring.BundleRequirementImpl@4233}
"[org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)]
osgi.wiring.package; (osgi.wiring.package=javax.security.cert)"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4897} size = 1
m_filter: org.apache.felix.framework.capabilityset.SimpleFilter =
{org.apache.felix.framework.capabilityset.SimpleFilter@4256}
"(osgi.wiring.package=javax.security.cert)"
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
m_optional: boolean = false
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.BundleRevisionImpl@4189}
"org.ops4j.pax.web.pax-web-tomcat-keycloak18 [97](R 97.0)"
{noformat}
The selected candidate in
{{org.apache.karaf.features.extension.BundleWires#filterCandidates()}} is fine:
{noformat}
candidates = {org.apache.felix.framework.util.ShrinkableCollection@4294} size
= 1
0 = {org.apache.felix.framework.wiring.BundleCapabilityImpl@4262}
"[org.apache.felix.framework [0](R 0)] osgi.wiring.package;
{bundle-symbolic-name=[Ljava.lang.String;@767e20cf, bundle-version=7.0.5,
version=0.0.0, osgi.wiring.package=javax.security.cert}"
m_attrs: java.util.Map = {java.util.Collections$UnmodifiableMap@4892} size
= 4
m_dirs: java.util.Map = {java.util.Collections$UnmodifiableMap@4891} size = 0
m_mandatory: java.util.Set = {java.util.Collections$EmptySet@4882} size = 0
m_namespace: java.lang.String = {@4890} "osgi.wiring.package"
m_revision: org.osgi.framework.wiring.BundleRevision =
{org.apache.felix.framework.ExtensionManager$ExtensionManagerRevision@1496}
"org.apache.felix.framework [0](R 0)"
m_uses: java.util.List = {java.util.Collections$EmptyList@4893} size = 0
{noformat}
However, the candidate is flitered out because
{{org.apache.karaf.features.extension.BundleWires#wiring}} doesn't contain a
requirement ID {{osgi.wiring.package;
(osgi.wiring.package=javax.security.cert)}...
> Restoring the wiring of fragment bundles with multiple hosts
>
>
> Key: KARAF-6501
> URL: https://issues.apache.org/jira/browse/KARAF-6501
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.3.0, 4.2.7
>Reporter: Nelson Antunes
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0, 4.2.8
>
> Attachments: example-1.0-SNAPSHOT.kar
>
>
> The {{StoredWiringResolver}}'s bundle wiring cache assumes each requirement
> is only wired to a single capability. This isn't true for
> {{osgi.wiring.host}} requirements as fragments can attach to multiple hosts.
> It is storing only the last wiring it comes across, resulting in the loss of
> the other wirings when booting with hot caches.
> Steps to reproduce:
> *1. Start a clean karaf*
> {noformat}
> $ bin/karaf
> __ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.7)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State │ Lvl │ Version │ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> {noformat}
> *2. Install a fragment bundle and install and start two or more bundles that
> satisfies the fragment's Fragment-Host requirement*
> You can use the attached {{example-1.0-SNAPSHOT.kar}} file. Put it in the
> {{deploy}} folder and it will install a fragment bundle and three hosts:
> {noformat}
> Starting the host 2
> Starting the host 1
> Starting the host 3
> {noformat}
> *3. Check that the bundles are correctly installed and the fragment is
> attached to all three hosts*
> {noformat}
> karaf@root()> list
> START LEVEL 100 , List Threshold: 50
> ID │ State│ Lvl │ Version│ Name
> 22 │ Active │ 80 │ 4.2.7 │ Apache Karaf :: OSGi Services :: Event
> 44 │ Resolved │ 80 │ 1.0.0.SNAPSHOT │ fragment Bundle, Hosts: 47, 46, 45
> 45 │ Active │
[jira] [Assigned] (KARAF-6074) Race condition between the FeaturesService and FeatureDeploymentListener
[
https://issues.apache.org/jira/browse/KARAF-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned KARAF-6074:
---
Assignee: (was: Grzegorz Grzybek)
> Race condition between the FeaturesService and FeatureDeploymentListener
>
>
> Key: KARAF-6074
> URL: https://issues.apache.org/jira/browse/KARAF-6074
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2, 4.2.4
> Environment: Karaf 4.2.2 Windows 7 and Equinox
>Reporter: J. Brébec
>Priority: Critical
>
> On the first start of a custom Karaf container (4.2.2), the logs shows a log
> of NPE in FeatureDeploymentListener.
> After some analysis of this Exception, it's look like a race condition
> between the FeaturesService and the FeatureDeploymentListener :
> # The FeaturesService starts and launch a provisioning in another thread
> # a FeatureDeploymentListener is registered, and call bundleChanged for
> every bundle installed (the startup bundles)
> # It calls FeaturesService.state.requirements and get an empty map
> # Updating the root regions in the requirements map fails with an NPE
> # Some times later, the deployment task launched at step 1 is started, and
> FeaturesService.saveState() is called : state.requirements."root region" is
> initialised
> The step 5 is executed in another thread, so it can happens before step 2
> (and it works) or after, causing this NPE
> Moreover, some methods in FeaturesService assume that
> state.requirements."root region" exists. There are probably others npe here.
>
> {code:java}
> 14:37:55.668 ERROR [activator-1-thread-2] Unable to update deployed features
> for bundle: org.eclipse.osgi - 3.12.100.v20180210-1608
> java.lang.NullPointerException: null
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:95)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at
> org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:52)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:292)
> [25:org.apache.karaf.deployer.features:4.2.2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KARAF-7550) MBeanInvocationHandler should throw the cause of InvocationTargetException, not ITE itself
[
https://issues.apache.org/jira/browse/KARAF-7550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved KARAF-7550.
-
Resolution: Fixed
> MBeanInvocationHandler should throw the cause of InvocationTargetException,
> not ITE itself
> --
>
> Key: KARAF-7550
> URL: https://issues.apache.org/jira/browse/KARAF-7550
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.3.3
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.8, 4.4.2
>
>
> KARAF-7234 fixed KARAF-6654 by throwing the exception from MBean invocation
> instead of returning null.
> However, the exception thrown by
> {{org.apache.karaf.management.internal.MBeanInvocationHandler#invoke()}}
> should be the cause of {{java.lang.reflect.InvocationTargetException}}, not
> this exception itself.
> Now, jconsole gets {{UndeclaredThrowableException}} instead of the actual
> exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7550) MBeanInvocationHandler should throw the cause of InvocationTargetException, not ITE itself
[
https://issues.apache.org/jira/browse/KARAF-7550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605647#comment-17605647
]
Grzegorz Grzybek commented on KARAF-7550:
-
Fixed
[here|https://github.com/apache/karaf/commit/488d676f796ad3e3bb60818cc7d25edddf2b8576]
in main branch.
> MBeanInvocationHandler should throw the cause of InvocationTargetException,
> not ITE itself
> --
>
> Key: KARAF-7550
> URL: https://issues.apache.org/jira/browse/KARAF-7550
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.3.3
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> KARAF-7234 fixed KARAF-6654 by throwing the exception from MBean invocation
> instead of returning null.
> However, the exception thrown by
> {{org.apache.karaf.management.internal.MBeanInvocationHandler#invoke()}}
> should be the cause of {{java.lang.reflect.InvocationTargetException}}, not
> this exception itself.
> Now, jconsole gets {{UndeclaredThrowableException}} instead of the actual
> exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KARAF-7550) MBeanInvocationHandler should throw the cause of InvocationTargetException, not ITE itself
[
https://issues.apache.org/jira/browse/KARAF-7550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7550:
Fix Version/s: 4.3.8
4.4.2
> MBeanInvocationHandler should throw the cause of InvocationTargetException,
> not ITE itself
> --
>
> Key: KARAF-7550
> URL: https://issues.apache.org/jira/browse/KARAF-7550
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.3.3
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.8, 4.4.2
>
>
> KARAF-7234 fixed KARAF-6654 by throwing the exception from MBean invocation
> instead of returning null.
> However, the exception thrown by
> {{org.apache.karaf.management.internal.MBeanInvocationHandler#invoke()}}
> should be the cause of {{java.lang.reflect.InvocationTargetException}}, not
> this exception itself.
> Now, jconsole gets {{UndeclaredThrowableException}} instead of the actual
> exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KARAF-7550) MBeanInvocationHandler should throw the cause of InvocationTargetException, not ITE itself
Grzegorz Grzybek created KARAF-7550:
---
Summary: MBeanInvocationHandler should throw the cause of
InvocationTargetException, not ITE itself
Key: KARAF-7550
URL: https://issues.apache.org/jira/browse/KARAF-7550
Project: Karaf
Issue Type: Bug
Affects Versions: 4.3.3
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
KARAF-7234 fixed KARAF-6654 by throwing the exception from MBean invocation
instead of returning null.
However, the exception thrown by
{{org.apache.karaf.management.internal.MBeanInvocationHandler#invoke()}} should
be the cause of {{java.lang.reflect.InvocationTargetException}}, not this
exception itself.
Now, jconsole gets {{UndeclaredThrowableException}} instead of the actual
exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7544) Upgrade to Jetty 10 and Pax Web 9
[
https://issues.apache.org/jira/browse/KARAF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17600711#comment-17600711
]
Grzegorz Grzybek commented on KARAF-7544:
-
The work-in-progress branch is
https://github.com/grgrzybek/karaf/commits/KARAF-7544-Jetty10-PaxWeb9 for you
[~jbonofre] to check.
> Upgrade to Jetty 10 and Pax Web 9
> -
>
> Key: KARAF-7544
> URL: https://issues.apache.org/jira/browse/KARAF-7544
> Project: Karaf
> Issue Type: Story
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've prepared Pax Web branch to release Pax Web 9 with Jetty 10 upgrade
> (JDK11+). (see: https://github.com/ops4j/org.ops4j.pax.web/issues/1743)
> With few tweaks, Karaf 4.4.2-SNAPSHOT works well with the above dependencies,
> with few restrictions:
> * I've generally upgraded Servlet API jar/bundle used by Karaf to version 4
> * {{StandardFeaturesTest.installAriesBlueprintWebFeature}} and
> {{RestExampleTest.testWhiteboard}} need a _compatibility bundle_ for Servlet
> API, so {{javax.servlet}} package is exported with version 3.1.0 (for
> blueprint.web and aries.jaxrs bundles)
> * {{CamelExampleTest}} needs some polish, because I see that asm 5.0.4 bundle
> is installed from Camel features and it doesn't work with JDK17
> * {{PaxCdiFeaturesTest}} should be removed (IMO), because Pax CDI is no
> longer maintained - Pax Web works well with Aries CDI
> * I've changed all {{}} elements of karaf-maven-plugin configuration
> to {{11}}
> * {{WebSocketExampleTest}} no longer works, as it uses
> {{org.eclipse.jetty.websocket.api.annotations.WebSocket}} and
> {{org.eclipse.jetty.websocket.servlet.WebSocketServlet}} which are not
> available in Jetty 10 - however Pax Web 8+ itself fully works with JSR356
> compatible web sockets (using ServletContainerInitializers for Jetty, Tomcat
> and Undertow)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (KARAF-7544) Upgrade to Jetty 10 and Pax Web 9
Grzegorz Grzybek created KARAF-7544:
---
Summary: Upgrade to Jetty 10 and Pax Web 9
Key: KARAF-7544
URL: https://issues.apache.org/jira/browse/KARAF-7544
Project: Karaf
Issue Type: Story
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
I've prepared Pax Web branch to release Pax Web 9 with Jetty 10 upgrade
(JDK11+). (see: https://github.com/ops4j/org.ops4j.pax.web/issues/1743)
With few tweaks, Karaf 4.4.2-SNAPSHOT works well with the above dependencies,
with few restrictions:
* I've generally upgraded Servlet API jar/bundle used by Karaf to version 4
* {{StandardFeaturesTest.installAriesBlueprintWebFeature}} and
{{RestExampleTest.testWhiteboard}} need a _compatibility bundle_ for Servlet
API, so {{javax.servlet}} package is exported with version 3.1.0 (for
blueprint.web and aries.jaxrs bundles)
* {{CamelExampleTest}} needs some polish, because I see that asm 5.0.4 bundle
is installed from Camel features and it doesn't work with JDK17
* {{PaxCdiFeaturesTest}} should be removed (IMO), because Pax CDI is no longer
maintained - Pax Web works well with Aries CDI
* I've changed all {{}} elements of karaf-maven-plugin configuration to
{{11}}
* {{WebSocketExampleTest}} no longer works, as it uses
{{org.eclipse.jetty.websocket.api.annotations.WebSocket}} and
{{org.eclipse.jetty.websocket.servlet.WebSocketServlet}} which are not
available in Jetty 10 - however Pax Web 8+ itself fully works with JSR356
compatible web sockets (using ServletContainerInitializers for Jetty, Tomcat
and Undertow)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7536) jolokia-access.xml stopped working in 4.4.1
[
https://issues.apache.org/jira/browse/KARAF-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17600612#comment-17600612
]
Grzegorz Grzybek commented on KARAF-7536:
-
[~rastislav.papp], which Java version and operating system do you use? on Linux
/ JDK 8/17 it works fine...
> jolokia-access.xml stopped working in 4.4.1
> ---
>
> Key: KARAF-7536
> URL: https://issues.apache.org/jira/browse/KARAF-7536
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.1
>Reporter: Rastislav Papp
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
>
> We use jolokia-osgi with access restricted via jolokia-access.xml, specifying
> that only localhost (or 127.0.0.1) is allowed.
> After upgrading to karaf 4.4.1, all jolokia requests return http 403, because
> {{getRemoteHost}} method of
> {{org.ops4j.pax.web.service.spi.servlet.OsgiHttpServletRequestWrapper}} now
> returns {{"[127.0.0.1]"}} instead of {{"127.0.0.1"}}. A hotfix was to add new
> entries to jolokia-access.xml, with the IPs wrapped with [], but I suspect
> other functionality might be broken because of this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563711#comment-17563711
]
Grzegorz Grzybek commented on KARAF-7389:
-
[~j3rem1e], referring to:
{quote}
The commit in this issue:
# Create a new configuration without the "felix.fileinstall.filename" property
# Then create the configuration file
{quote}
My original change for https://github.com/apache/karaf/pull/1489/files had two
goals:
# fileinstall getting CM_UPDATED with configuration _without_
{{felix.fileinstall.filename}} property won't process anything
# writing (by FeatureConfigInstaller) a file through tmp file won't trigger
fileinstall that could process (it happened to me) not-fully-written file
I never checked this problem with factory PIDs though.
{quote}
It tries to find the configuration by filename :
https://github.com/apache/felix-dev/blob/master/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/ConfigInstaller.java#L505
{quote}
Looks like the file is written by Karaf without {{felix.fileinstall.filename}}
property - maybe we should just add:
{code:java}
props.put(FILEINSTALL_FILE_NAME, cfgFile.getAbsoluteFile().toURI().toString());
{code}
before calling {{updateStorage(cid, props, false);}}?
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.0, 4.3.6, 4.2.15
>Reporter: Grzegorz Grzybek
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [!/:3.7.4]
> Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
> string
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
> ~[?:?]
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
> ~[?:?]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_312]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_312]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:641)
> ~[!/:3.7.4]
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KARAF-6703) Spec features and cleanup
[
https://issues.apache.org/jira/browse/KARAF-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553894#comment-17553894
]
Grzegorz Grzybek commented on KARAF-6703:
-
[~daltontc] in my case, we've fixed it in the fork of CXF (part of Fuse), but
simply by backporting CXF-8380 to older (used by Fuse) version of CXF.
The fix is (CXF side):
{noformat}
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
index bfc695528f2..1c615c00167 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
@@ -445,7 +445,7 @@ public class MultipartProvider extends
AbstractConfigurableProvider
Type genericType,
Annotation[] anns,
MediaType contentType) {
-super(new ByteDataSource("1".getBytes(), contentType.getType()));
+super(new ByteDataSource("1".getBytes(), contentType.toString()));
this.writer = writer;
this.obj = obj;
this.cls = cls;
{noformat}
[~ffang] ([~freeman.fang]?) may I ask you to check which upstream version of
CXF contains this fix? (or confirm it's 3.5.0, 3.4.2, 3.3.9)?
[~daltontc] which version of CXF do you use?
> Spec features and cleanup
> -
>
> Key: KARAF-6703
> URL: https://issues.apache.org/jira/browse/KARAF-6703
> Project: Karaf
> Issue Type: Task
> Components: karaf
>Reporter: Francois Papon
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> As already discussed, we should remove the lib/jdk9plus folder and all spec
> packages from etc/jre.properties to use spec features instead.
> That will give us more control in the specs version and support of JDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (KARAF-6703) Spec features and cleanup
[
https://issues.apache.org/jira/browse/KARAF-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553894#comment-17553894
]
Grzegorz Grzybek edited comment on KARAF-6703 at 6/14/22 4:57 AM:
--
[~daltontc] in my case, we've fixed it in the fork of CXF (part of Fuse), but
simply by backporting CXF-8380 to older (used by Fuse) version of CXF.
The fix is (CXF side):
{noformat}
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
index 76b735790fc..bfc695528f2 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
@@ -445,7 +445,7 @@ public class MultipartProvider extends
AbstractConfigurableProvider
Type genericType,
Annotation[] anns,
MediaType contentType) {
-super(new ByteDataSource("1".getBytes()));
+super(new ByteDataSource("1".getBytes(), contentType.getType()));
this.writer = writer;
this.obj = obj;
this.cls = cls;
...
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
index bfc695528f2..1c615c00167 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
@@ -445,7 +445,7 @@ public class MultipartProvider extends
AbstractConfigurableProvider
Type genericType,
Annotation[] anns,
MediaType contentType) {
-super(new ByteDataSource("1".getBytes(), contentType.getType()));
+super(new ByteDataSource("1".getBytes(), contentType.toString()));
this.writer = writer;
this.obj = obj;
this.cls = cls;
{noformat}
[~ffang] ([~freeman.fang]?) may I ask you to check which upstream version of
CXF contains this fix? (or confirm it's 3.5.0, 3.4.2, 3.3.9)?
[~daltontc] which version of CXF do you use?
was (Author: gzres):
[~daltontc] in my case, we've fixed it in the fork of CXF (part of Fuse), but
simply by backporting CXF-8380 to older (used by Fuse) version of CXF.
The fix is (CXF side):
{noformat}
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
index bfc695528f2..1c615c00167 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/MultipartProvider.java
@@ -445,7 +445,7 @@ public class MultipartProvider extends
AbstractConfigurableProvider
Type genericType,
Annotation[] anns,
MediaType contentType) {
-super(new ByteDataSource("1".getBytes(), contentType.getType()));
+super(new ByteDataSource("1".getBytes(), contentType.toString()));
this.writer = writer;
this.obj = obj;
this.cls = cls;
{noformat}
[~ffang] ([~freeman.fang]?) may I ask you to check which upstream version of
CXF contains this fix? (or confirm it's 3.5.0, 3.4.2, 3.3.9)?
[~daltontc] which version of CXF do you use?
> Spec features and cleanup
> -
>
> Key: KARAF-6703
> URL: https://issues.apache.org/jira/browse/KARAF-6703
> Project: Karaf
> Issue Type: Task
> Components: karaf
>Reporter: Francois Papon
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> As already discussed, we should remove the lib/jdk9plus folder and all spec
> packages from etc/jre.properties to use spec features instead.
> That will give us more control in the specs version and support of JDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (KARAF-7449) Upgrade to Pax Web 8.0.4
[ https://issues.apache.org/jira/browse/KARAF-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550855#comment-17550855 ] Grzegorz Grzybek commented on KARAF-7449: - Fixed [here|https://github.com/apache/karaf/commit/5ad29b15a310232a792916336fdd88b33023f4de] in main branch for Karaf 4.4.x. > Upgrade to Pax Web 8.0.4 > > > Key: KARAF-7449 > URL: https://issues.apache.org/jira/browse/KARAF-7449 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.4.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (KARAF-7449) Upgrade to Pax Web 8.0.4
[ https://issues.apache.org/jira/browse/KARAF-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved KARAF-7449. - Resolution: Fixed > Upgrade to Pax Web 8.0.4 > > > Key: KARAF-7449 > URL: https://issues.apache.org/jira/browse/KARAF-7449 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.4.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work started] (KARAF-7449) Upgrade to Pax Web 8.0.4
[ https://issues.apache.org/jira/browse/KARAF-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KARAF-7449 started by Grzegorz Grzybek. --- > Upgrade to Pax Web 8.0.4 > > > Key: KARAF-7449 > URL: https://issues.apache.org/jira/browse/KARAF-7449 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.4.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (KARAF-7449) Upgrade to Pax Web 8.0.4
Grzegorz Grzybek created KARAF-7449: --- Summary: Upgrade to Pax Web 8.0.4 Key: KARAF-7449 URL: https://issues.apache.org/jira/browse/KARAF-7449 Project: Karaf Issue Type: Dependency upgrade Reporter: Grzegorz Grzybek Fix For: 4.4.1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (KARAF-7449) Upgrade to Pax Web 8.0.4
[ https://issues.apache.org/jira/browse/KARAF-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned KARAF-7449: --- Assignee: Grzegorz Grzybek > Upgrade to Pax Web 8.0.4 > > > Key: KARAF-7449 > URL: https://issues.apache.org/jira/browse/KARAF-7449 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.4.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (KARAF-7406) Document Pax Web 8 changes in Karaf manual
[ https://issues.apache.org/jira/browse/KARAF-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514603#comment-17514603 ] Grzegorz Grzybek commented on KARAF-7406: - PR: https://github.com/apache/karaf/pull/1490 > Document Pax Web 8 changes in Karaf manual > -- > > Key: KARAF-7406 > URL: https://issues.apache.org/jira/browse/KARAF-7406 > Project: Karaf > Issue Type: Task > Components: karaf >Reporter: Grzegorz Grzybek >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KARAF-7406) Document Pax Web 8 changes in Karaf manual
Grzegorz Grzybek created KARAF-7406: --- Summary: Document Pax Web 8 changes in Karaf manual Key: KARAF-7406 URL: https://issues.apache.org/jira/browse/KARAF-7406 Project: Karaf Issue Type: Task Components: karaf Reporter: Grzegorz Grzybek Assignee: Grzegorz Grzybek Fix For: 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7389:
Component/s: karaf
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.4.0, 4.3.6, 4.2.15
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [!/:3.7.4]
> Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
> string
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
> ~[?:?]
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
> ~[?:?]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_312]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_312]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:641)
> ~[!/:3.7.4]
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7389:
Affects Version/s: 4.2.15
4.3.6
4.4.0
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.4.0, 4.3.6, 4.2.15
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [!/:3.7.4]
> Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
> string
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
> ~[?:?]
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
> ~[?:?]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_312]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_312]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:641)
> ~[!/:3.7.4]
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[ https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490862#comment-17490862 ] Grzegorz Grzybek commented on KARAF-7392: - PR: https://github.com/apache/karaf/pull/1490 > Upgrade to Pax Web 8 with its own Karaf commands > > > Key: KARAF-7392 > URL: https://issues.apache.org/jira/browse/KARAF-7392 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: 4.4.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[
https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490762#comment-17490762
]
Grzegorz Grzybek commented on KARAF-7392:
-
{{RestExampleTest.testWhiteboard}}: fails with {{Caused by:
org.apache.felix.resolver.reason.ReasonException: Unable to resolve
com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6: missing
requirement
[com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6]
osgi.wiring.package; filter:="(osgi.wiring.package=javax.activation)"
}}
> Upgrade to Pax Web 8 with its own Karaf commands
>
>
> Key: KARAF-7392
> URL: https://issues.apache.org/jira/browse/KARAF-7392
> Project: Karaf
> Issue Type: Dependency upgrade
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[
https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490762#comment-17490762
]
Grzegorz Grzybek edited comment on KARAF-7392 at 2/11/22, 8:59 AM:
---
{{RestExampleTest.testWhiteboard}}: fails with {{Caused by:
org.apache.felix.resolver.reason.ReasonException: Unable to resolve
com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6: missing
requirement
[com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6]
osgi.wiring.package; filter:="(osgi.wiring.package=javax.activation)"}}
was (Author: gzres):
{{RestExampleTest.testWhiteboard}}: fails with {{Caused by:
org.apache.felix.resolver.reason.ReasonException: Unable to resolve
com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6: missing
requirement
[com.fasterxml.jackson.module.jackson-module-jaxb-annotations/2.9.6]
osgi.wiring.package; filter:="(osgi.wiring.package=javax.activation)"
}}
> Upgrade to Pax Web 8 with its own Karaf commands
>
>
> Key: KARAF-7392
> URL: https://issues.apache.org/jira/browse/KARAF-7392
> Project: Karaf
> Issue Type: Dependency upgrade
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[
https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490717#comment-17490717
]
Grzegorz Grzybek commented on KARAF-7392:
-
MavenResolverRegisteredBeforeConfigAdminTest - I had to
{{org.osgi.util.function}} + {{org.osgi.util.promise}} to {{converter}} feature
in {{assemblies/features/specs/src/main/feature/feature.xml}}...
cc: [~jbonofre].
> Upgrade to Pax Web 8 with its own Karaf commands
>
>
> Key: KARAF-7392
> URL: https://issues.apache.org/jira/browse/KARAF-7392
> Project: Karaf
> Issue Type: Dependency upgrade
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[
https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490717#comment-17490717
]
Grzegorz Grzybek edited comment on KARAF-7392 at 2/11/22, 7:35 AM:
---
{{MavenResolverRegisteredBeforeConfigAdminTest}}: I had to add
{{org.osgi.util.function}} + {{org.osgi.util.promise}} to {{converter}} feature
in {{assemblies/features/specs/src/main/feature/feature.xml}}...
cc: [~jbonofre].
was (Author: gzres):
MavenResolverRegisteredBeforeConfigAdminTest - I had to
{{org.osgi.util.function}} + {{org.osgi.util.promise}} to {{converter}} feature
in {{assemblies/features/specs/src/main/feature/feature.xml}}...
cc: [~jbonofre].
> Upgrade to Pax Web 8 with its own Karaf commands
>
>
> Key: KARAF-7392
> URL: https://issues.apache.org/jira/browse/KARAF-7392
> Project: Karaf
> Issue Type: Dependency upgrade
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
[
https://issues.apache.org/jira/browse/KARAF-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490318#comment-17490318
]
Grzegorz Grzybek commented on KARAF-7392:
-
Itests (JDK8, so the problems with jakarta-activation can be ignored) after
upgrading to Pax Web 8 and quickly adjusting http/web/webconsole modules:
{noformat}
[ERROR] Errors:
[ERROR] HttpTest.list » EOF
[ERROR] HttpTest.listViaMBean » Connect Connection refused (Connection
refused)
[ERROR] HttpTest.testProxy » CommandNotFound Command not found: http:proxy-add
[ERROR] WebTest.installUninstallCommands » EOF
[ERROR] WebTest.installViaMBean:101 » MBean java.lang.NullPointerException
[ERROR] WebTest.listCommand » Connect Connection refused (Connection refused)
[ERROR] WebTest.listViaMBean » Connect Connection refused (Connection refused)
[ERROR]
HttpResourceExampleTest.test:41->KarafTestSupport.executeCommand:345->KarafTestSupport.executeCommand:358->KarafTestSupport.executeCommand:396->KarafTestSupport.waitForCommandService:599
» TestTimedOut
[ERROR] RestExampleTest.testBlueprintWithCxfClient » Reason Unable to resolve
com.sun
[ERROR] RestExampleTest.testBlueprintWithHttpClient » Reason Unable to
resolve com.sun...
[ERROR] RestExampleTest.testScrWithCxfClient » Reason Unable to resolve
com.sun.activa...
[ERROR] RestExampleTest.testScrWithHttpClient » Reason Unable to resolve
com.sun.activ...
[ERROR] RestExampleTest.testScrWithJerseyClient » Reason Unable to resolve
com.sun.act...
[ERROR] RestExampleTest.testWhiteboard » Reason Unable to resolve
org.apache.karaf.exa...
[ERROR] ServletExampleTest.testUploadServlet » Connect Connection refused
(Connection ...
[ERROR] ServletExampleTest.testWithAnnotation » CommandNotFound Command not
found: htt...
[ERROR] ServletExampleTest.testWithBlueprint » CommandNotFound Command not
found: http...
[ERROR] ServletExampleTest.testWithRegistration » Export internal error:
ObjID already...
[ERROR] ServletExampleTest.testWithScr » Export internal error: ObjID already
in use
[ERROR] SoapExampleTest.testBlueprint » Reason Unable to resolve
com.sun.activation.ja...
[ERROR] SoapExampleTest.testScr » Reason Unable to resolve
com.sun.activation.jakarta
[ERROR] WarExampleTest.test » EOF
[ERROR] WebSocketExampleTest.test:54 » Bundle Unable to resolve
org.apache.karaf.examp...
[ERROR] MavenResolverRegisteredBeforeConfigAdminTest.mavenResolverAvailable »
NotBound
[ERROR]
JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
» Runtime
[ERROR]
JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
» Runtime
[ERROR]
JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
» Runtime
[INFO]
[ERROR] Tests run: 267, Failures: 0, Errors: 27, Skipped: 5
{noformat}
will check tomorrow.
> Upgrade to Pax Web 8 with its own Karaf commands
>
>
> Key: KARAF-7392
> URL: https://issues.apache.org/jira/browse/KARAF-7392
> Project: Karaf
> Issue Type: Dependency upgrade
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.4.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (KARAF-7392) Upgrade to Pax Web 8 with its own Karaf commands
Grzegorz Grzybek created KARAF-7392: --- Summary: Upgrade to Pax Web 8 with its own Karaf commands Key: KARAF-7392 URL: https://issues.apache.org/jira/browse/KARAF-7392 Project: Karaf Issue Type: Dependency upgrade Reporter: Grzegorz Grzybek Assignee: Grzegorz Grzybek Fix For: 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489417#comment-17489417
]
Grzegorz Grzybek commented on KARAF-7389:
-
The original config from the feature is:
{noformat}
# non secure connector configuration
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
# secure connector configuration
org.osgi.service.http.secure.enabled = false
#org.osgi.service.http.port.secure = 8443
#org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.keystore.password = passw0rd
#org.ops4j.pax.web.ssl.keystore.type = JKS
#org.ops4j.pax.web.ssl.key.password = passw0rd
#org.ops4j.pax.web.ssl.key.alias = server
#org.ops4j.pax.web.ssl.clientauth.needed = false
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.3
#org.ops4j.pax.web.ssl.protocol = TLSv1.3
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.2 TLSv1.3
#org.ops4j.pax.web.ssl.ciphersuites.included = TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384
#org.ops4j.pax.web.ssl.secureRandom.algorithm = NativePRNGNonBlocking
#org.ops4j.pax.web.ssl.renegotiationAllowed = true
#org.ops4j.pax.web.ssl.session.enabled = true
# external Jetty configuration file where Jetty-specific beans may be declared
#org.ops4j.pax.web.config.file = ${karaf.etc}/jetty.xml
# this is a root directory for all the context-specific directories managed by
Pax Web
javax.servlet.context.tempdir = ${karaf.data}/pax-web/tmp
{noformat}
all the comments and commented properties are part of the
{{org.apache.felix.utils.properties.Properties.Layout}} under
{{javax.servlet.context.tempdir}} key in
{{org.apache.felix.utils.properties.Properties#layout}} map.
I can't catch exactly the moment where the comment changes into keyless
property, but these threads simply should be synchronized:
{{features-3-thread-1}} doing:
{code:java}
for (String key : storage.keySet())
{
Layout l = layout.get(key);
if (l != null && l.getCommentLines() != null)
{
for (String s : l.getCommentLines())
{
writer.writeln(s);
}
}
...
{code}
and {{CM Event Dispatcher (Fire ConfigurationEvent: pid=org.ops4j.pax.web)}}
thread doing:
{code:xml}
protected void loadLayout(Reader in, boolean maybeTyped) throws IOException
{
PropertiesReader reader = new PropertiesReader(in, maybeTyped);
boolean hasProperty = false;
while (reader.nextProperty())
{
hasProperty = true;
storage.put(reader.getPropertyName(), reader.getPropertyValue());
int idx = checkHeaderComment(reader.getCommentLines());
layout.put(reader.getPropertyName(),
new Layout(idx < reader.getCommentLines().size() ?
new
ArrayList(reader.getCommentLines().subList(idx,
reader.getCommentLines().size())) :
null,
new ArrayList(reader.getValueLines(;
}
...
{code}
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
>
[jira] [Comment Edited] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489417#comment-17489417
]
Grzegorz Grzybek edited comment on KARAF-7389 at 2/9/22, 9:56 AM:
--
The original config from the feature is:
{noformat}
# non secure connector configuration
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
# secure connector configuration
org.osgi.service.http.secure.enabled = false
#org.osgi.service.http.port.secure = 8443
#org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.keystore.password = passw0rd
#org.ops4j.pax.web.ssl.keystore.type = JKS
#org.ops4j.pax.web.ssl.key.password = passw0rd
#org.ops4j.pax.web.ssl.key.alias = server
#org.ops4j.pax.web.ssl.clientauth.needed = false
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.3
#org.ops4j.pax.web.ssl.protocol = TLSv1.3
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.2 TLSv1.3
#org.ops4j.pax.web.ssl.ciphersuites.included = TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384
#org.ops4j.pax.web.ssl.secureRandom.algorithm = NativePRNGNonBlocking
#org.ops4j.pax.web.ssl.renegotiationAllowed = true
#org.ops4j.pax.web.ssl.session.enabled = true
# external Jetty configuration file where Jetty-specific beans may be declared
#org.ops4j.pax.web.config.file = ${karaf.etc}/jetty.xml
# this is a root directory for all the context-specific directories managed by
Pax Web
javax.servlet.context.tempdir = ${karaf.data}/pax-web/tmp
{noformat}
all the comments and commented properties are part of the
{{org.apache.felix.utils.properties.Properties.Layout}} under
{{javax.servlet.context.tempdir}} key in
{{org.apache.felix.utils.properties.Properties#layout}} map.
I can't catch exactly the moment where the comment changes into keyless
property, but these threads simply should be synchronized:
{{features-3-thread-1}} doing:
{code:java}
for (String key : storage.keySet())
{
Layout l = layout.get(key);
if (l != null && l.getCommentLines() != null)
{
for (String s : l.getCommentLines())
{
writer.writeln(s);
}
}
...
{code}
and {{CM Event Dispatcher (Fire ConfigurationEvent: pid=org.ops4j.pax.web)}}
thread doing:
{code:java}
protected void loadLayout(Reader in, boolean maybeTyped) throws IOException
{
PropertiesReader reader = new PropertiesReader(in, maybeTyped);
boolean hasProperty = false;
while (reader.nextProperty())
{
hasProperty = true;
storage.put(reader.getPropertyName(), reader.getPropertyValue());
int idx = checkHeaderComment(reader.getCommentLines());
layout.put(reader.getPropertyName(),
new Layout(idx < reader.getCommentLines().size() ?
new
ArrayList(reader.getCommentLines().subList(idx,
reader.getCommentLines().size())) :
null,
new ArrayList(reader.getValueLines(;
}
...
{code}
was (Author: gzres):
The original config from the feature is:
{noformat}
# non secure connector configuration
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
# secure connector configuration
org.osgi.service.http.secure.enabled = false
#org.osgi.service.http.port.secure = 8443
#org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.keystore.password = passw0rd
#org.ops4j.pax.web.ssl.keystore.type = JKS
#org.ops4j.pax.web.ssl.key.password = passw0rd
#org.ops4j.pax.web.ssl.key.alias = server
#org.ops4j.pax.web.ssl.clientauth.needed = false
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.3
#org.ops4j.pax.web.ssl.protocol = TLSv1.3
#org.ops4j.pax.web.ssl.protocols.included = TLSv1.2 TLSv1.3
#org.ops4j.pax.web.ssl.ciphersuites.included = TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384
#org.ops4j.pax.web.ssl.secureRandom.algorithm = NativePRNGNonBlocking
#org.ops4j.pax.web.ssl.renegotiationAllowed = true
#org.ops4j.pax.web.ssl.session.enabled = true
# external Jetty configuration file where Jetty-specific beans may be declared
#org.ops4j.pax.web.config.file = ${karaf.etc}/jetty.xml
# this is a root directory for all the context-specific directories managed by
Pax Web
javax.servlet.context.tempdir = ${karaf.data}/pax-web/tmp
{noformat}
all the comments and commented properties are part of the
{{org.apache.felix.utils.properties.Properties.Layout}} under
{{javax.servlet.context.tempdir}} key in
{{org.apache.felix.utils.properties.Properties#layout}} map.
I can't catch exactly the moment
[jira] [Commented] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488865#comment-17488865
]
Grzegorz Grzybek commented on KARAF-7389:
-
Looks like a race between two threads:
feature installer:
{noformat}
"features-3-thread-1@7162" prio=5 tid=0x3f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.karaf.features.internal.service.FeatureConfigInstaller.installFeatureConfigs(FeatureConfigInstaller.java:145)
at
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.installConfigs(BundleInstallSupportImpl.java:301)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.installConfigs(FeaturesServiceImpl.java:1185)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:961)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl$$Lambda$119.185025815.call(Unknown
Source:-1)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
and CM Event dispatcher:
{noformat}
"CM Event Dispatcher (Fire ConfigurationEvent: pid=org.ops4j.pax.web)@7234"
daemon prio=5 tid=0x2b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.felix.fileinstall.internal.ConfigInstaller.configurationEvent(ConfigInstaller.java:222)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1720)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1662)
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [!/:3.7.4]
> Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
> string
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
> ~[?:?]
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
> ~[?:?]
> at
[jira] [Comment Edited] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488831#comment-17488831
]
Grzegorz Grzybek edited comment on KARAF-7389 at 2/8/22, 1:08 PM:
--
Got it. In
{{org.apache.felix.fileinstall.internal.ConfigInstaller#setConfig()}}:
{noformat}
ht = {java.util.Hashtable@7642} size = 7
{@7681} "javax.servlet.context.tempdir" -> {@7682}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp"
{@7683} "org.osgi.service.http.enabled" -> {@7684} "true"
{@7685} "org.osgi.service.http.port" -> {@7686} "8181"
{@7687} "org.apache.karaf.features.configKey" -> {@7688} "org.ops4j.pax.web"
{@7689} "org.osgi.service.http.secure.enabled" -> {@7690} "false"
{@7691} "felix.fileinstall.filename" -> {@7692}
"file:/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg"
{@7639} "" -> {@7693}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/server.keystore"
{noformat}
However it doesn't look like Fileinstall fault, because the file itself is
broken:
{noformat}
javax.servlet.context.tempdir =
/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp
org.apache.karaf.features.configKey = org.ops4j.pax.web
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
org.osgi.service.http.secure.enabled = false
= ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
...
{noformat}
was (Author: gzres):
Got it. In
{{org.apache.felix.fileinstall.internal.ConfigInstaller#setConfig()}}:
{noformat}
ht = {java.util.Hashtable@7642} size = 7
{@7681} "javax.servlet.context.tempdir" -> {@7682}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp"
{@7683} "org.osgi.service.http.enabled" -> {@7684} "true"
{@7685} "org.osgi.service.http.port" -> {@7686} "8181"
{@7687} "org.apache.karaf.features.configKey" -> {@7688} "org.ops4j.pax.web"
{@7689} "org.osgi.service.http.secure.enabled" -> {@7690} "false"
{@7691} "felix.fileinstall.filename" -> {@7692}
"file:/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg"
{@7639} "" -> {@7693}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/server.keystore"
{noformat}
However it doesn't look like Fileinstall fault, because the file itself is
broken:
{noformat}
javax.servlet.context.tempdir =
/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp
org.apache.karaf.features.configKey = org.ops4j.pax.web
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
org.osgi.service.http.secure.enabled = false
= ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
{noformat}
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
>
[jira] [Commented] (KARAF-7389) Problem installing features with embedded config
[
https://issues.apache.org/jira/browse/KARAF-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488831#comment-17488831
]
Grzegorz Grzybek commented on KARAF-7389:
-
Got it. In
{{org.apache.felix.fileinstall.internal.ConfigInstaller#setConfig()}}:
{noformat}
ht = {java.util.Hashtable@7642} size = 7
{@7681} "javax.servlet.context.tempdir" -> {@7682}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp"
{@7683} "org.osgi.service.http.enabled" -> {@7684} "true"
{@7685} "org.osgi.service.http.port" -> {@7686} "8181"
{@7687} "org.apache.karaf.features.configKey" -> {@7688} "org.ops4j.pax.web"
{@7689} "org.osgi.service.http.secure.enabled" -> {@7690} "false"
{@7691} "felix.fileinstall.filename" -> {@7692}
"file:/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg"
{@7639} "" -> {@7693}
"/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/server.keystore"
{noformat}
However it doesn't look like Fileinstall fault, because the file itself is
broken:
{noformat}
javax.servlet.context.tempdir =
/data/servers/apache-karaf-4.4.0-SNAPSHOT/data/pax-web/tmp
org.apache.karaf.features.configKey = org.ops4j.pax.web
org.osgi.service.http.enabled = true
org.osgi.service.http.port = 8181
org.osgi.service.http.secure.enabled = false
= ${karaf.etc}/server.keystore
#org.ops4j.pax.web.ssl.truststore.password = passw0rd
#org.ops4j.pax.web.ssl.truststore.type = JKS
#org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/server.keystore
{noformat}
> Problem installing features with embedded config
>
>
> Key: KARAF-7389
> URL: https://issues.apache.org/jira/browse/KARAF-7389
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
> {noformat}
> 2022-02-08T13:25:32,180 | INFO |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
> configuration {org.ops4j.pax.web} from
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> 2022-02-08T13:25:32,184 | ERROR |
> fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
>| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to
> install artifact:
> /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
> java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must
> not be an empty string
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
> ~[!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [!/:3.7.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [!/:3.7.4]
> Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
> string
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
> ~[?:?]
> at
> org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
> ~[?:?]
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
> ~[?:?]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_312]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_312]
> at
> org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:641)
> ~[!/:3.7.4]
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (KARAF-7389) Problem installing features with embedded config
Grzegorz Grzybek created KARAF-7389:
---
Summary: Problem installing features with embedded config
Key: KARAF-7389
URL: https://issues.apache.org/jira/browse/KARAF-7389
Project: Karaf
Issue Type: Bug
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
I've just seen this when installing Pax Web 8.0.1-SNAPSHOT features:
{noformat}
2022-02-08T13:25:32,180 | INFO |
fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
| 17 - org.apache.felix.fileinstall - 3.7.4 | Updating
configuration {org.ops4j.pax.web} from
/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
2022-02-08T13:25:32,184 | ERROR |
fileinstall-/data/servers/apache-karaf-4.4.0-SNAPSHOT/etc | fileinstall
| 17 - org.apache.felix.fileinstall - 3.7.4 | Failed to install
artifact: /data/servers/apache-karaf-4.4.0-SNAPSHOT/etc/org.ops4j.pax.web.cfg
java.lang.RuntimeException: java.lang.IllegalArgumentException: Key [] must not
be an empty string
at
org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:649)
~[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:411)
~[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:192)
~[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:950)
[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
[!/:3.7.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
[!/:3.7.4]
Caused by: java.lang.IllegalArgumentException: Key [] must not be an empty
string
at
org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:269)
~[?:?]
at
org.apache.felix.cm.impl.CaseInsensitiveDictionary.(CaseInsensitiveDictionary.java:73)
~[?:?]
at
org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:452)
~[?:?]
at
org.apache.felix.cm.impl.ConfigurationAdapter.updateIfDifferent(ConfigurationAdapter.java:204)
~[?:?]
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_312]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_312]
at
org.apache.felix.fileinstall.internal.ConfigInstaller.update0(ConfigInstaller.java:641)
~[!/:3.7.4]
... 7 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KARAF-7312) Add support for JMX RMI credentials filter pattern
[
https://issues.apache.org/jira/browse/KARAF-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485851#comment-17485851
]
Grzegorz Grzybek commented on KARAF-7312:
-
[~jbonofre] this looks like JDK11 only fix...
{{javax.management.remote.rmi.RMIConnectorServer#CREDENTIALS_FILTER_PATTERN}}
is not available in JDK8... Is this intended?
> Add support for JMX RMI credentials filter pattern
> --
>
> Key: KARAF-7312
> URL: https://issues.apache.org/jira/browse/KARAF-7312
> Project: Karaf
> Issue Type: Improvement
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.4.0, 4.3.6
>
>
> We should configure an ObjectInputFilter for the JMX service.
> This can be done by setting a suitable filter configuration for the
> {{jmx.remote.rmi.server.credentials.filter.pattern}} key that can be
> specified within the environment variables when creating a new JMX server
> instance.
> For Karaf, it should be done in the connector factory.
> An example can be found here:
> [https://github.com/openjdk/jdk/blob/master/src/jd]k.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java#L525
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (KARAF-7152) Narayana unable to create object store due to ClassNotFoundException on javax.security.cert.X509Certificate
[
https://issues.apache.org/jira/browse/KARAF-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405294#comment-17405294
]
Grzegorz Grzybek commented on KARAF-7152:
-
[~nannou9], [~jbonofre] please check
https://github.com/ops4j/org.ops4j.pax.transx/issues/50 - it should already be
fixed...
> Narayana unable to create object store due to ClassNotFoundException on
> javax.security.cert.X509Certificate
> ---
>
> Key: KARAF-7152
> URL: https://issues.apache.org/jira/browse/KARAF-7152
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.3.1
>Reporter: Piotr Klimczak
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> feature:install pax-transx-tm-narayana fails with:
> {code:java}
> 07:23:01.283 WARN [paxtransx-config-1-thread-1] ARJUNA048006: cannot create
> new instance of
> com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
> java.lang.reflect.InvocationTargetException
> 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
> com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:129)
> at
> com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:152)
> at
> com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:111)
> at
> com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:68)
> at
> com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.(AtomicActionRecoveryModule.java:67)
> 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
> com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
> at
> com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
> at
> com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:465)
> at
> com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:888)
> at
> com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.(PeriodicRecovery.java:121)
> at
> com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.(RecoveryManagerImple.java:107)
> at
> com.arjuna.ats.arjuna.recovery.RecoveryManager.(RecoveryManager.java:481)
> at
> com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
> at
> com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
> at
> com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
> at
> org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:89)
> at
> org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49)
> at
> org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NoClassDefFoundError: javax/security/cert/X509Certificate
> at io.netty.util.internal.EmptyArrays.(EmptyArrays.java:38)
> at
> io.netty.util.ResourceLeakDetector.(ResourceLeakDetector.java:564)
> at
>
[jira] [Commented] (KARAF-6955) JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
[
https://issues.apache.org/jira/browse/KARAF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361490#comment-17361490
]
Grzegorz Grzybek commented on KARAF-6955:
-
For anyone checking this issue, the PR was prepared in KARAF-7096.
> JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
>
>
> Key: KARAF-6955
> URL: https://issues.apache.org/jira/browse/KARAF-6955
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.9
>Reporter: Martin Lichtin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.11, 4.3.1
>
>
> JMX - with rmiRegistryHost = 127.0.0.1 Karaf should listen only on 127.0.0.1
> However, Karaf listens on 0.0.0.0 which opens up access to the network.
> {noformat}
> > config:list "(service.pid=org.apache.karaf.management)"
>
> Pid:org.apache.karaf.management
> BundleLocation: ?
> Properties:
>daemon = true
>felix.fileinstall.filename =
> file:mykaraf/etc/org.apache.karaf.management.cfg
>jmxRealm = karaf
>jmxmpEnabled = false
>jmxmpHost = 127.0.0.1
>jmxmpObjectName = connector:name=jmxmp
>jmxmpPort =
>jmxmpServiceUrl = service:jmx:jmxmp://127.0.0.1:
>objectName = connector:name=rmi
>rmiRegistryHost = 127.0.0.1
>rmiRegistryPort = 25031
>rmiServerHost = 127.0.0.1
>rmiServerPort = 25041
>service.pid = org.apache.karaf.management
>serviceUrl =
> service:jmx:rmi://127.0.0.1:25041/jndi/rmi://127.0.0.1:25031/karaf-mykaraf
>threaded = true
> {noformat}
> Using netstat one can see the listen address is not 127.0.0.1:
> {noformat}
> $ netstat -n -l -t|grep 25031
> tcp 0 0 0.0.0.0:25031 0.0.0.0:* LISTEN
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved KARAF-7126.
-
Target Version/s: (was: 4.2.12, 4.3.3)
Resolution: Won't Fix
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at java.net.URL.openStream(URL.java:1068)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> {noformat}
> 4. in
> org.apache.felix.fileinstall.internal.DirectoryWatcher#installOrUpdateBundle,
> simple1 is processed
> 5. log message:
> {noformat}
> Installing bundle simple1.xml / 0.0.0
> {noformat}
> 6. org.osgi.framework.BundleContext#installBundle() for simple1
> 7. featureXmlURL is set to simple2.xml
> 8. log message:
> {noformat}
> Installing bundle simple2.xml / 0.0.0
> {noformat}
> 9. org.osgi.framework.BundleContext#installBundle() for simple2
> Now:
> {noformat}
> 240 │ Installed │ 80 │ 0.0.0│
> feature:file:/data/karaf/deploy/simple1.xml
> 241 │ Installed │ 80 │ 0.0.0│
> feature:file:/data/karaf/deploy/simple2.xml
> {noformat}
> 10. Of course
>
[jira] [Commented] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354939#comment-17354939
]
Grzegorz Grzybek commented on KARAF-7126:
-
I was thinking about this issue and because normally it's not a problem (when
using {{feature:install f1 f2 ...}}) and it's occurring only when deploying
more XMLs to {{$karaf.home/deploy}} (or calling {{feature:install
f1 & feature:install f2}}), I'm closing this issue. _Fixing_ it may cause more
harm than benefits.
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at java.net.URL.openStream(URL.java:1068)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> {noformat}
> 4. in
> org.apache.felix.fileinstall.internal.DirectoryWatcher#installOrUpdateBundle,
> simple1 is processed
> 5. log message:
> {noformat}
> Installing bundle simple1.xml / 0.0.0
> {noformat}
> 6. org.osgi.framework.BundleContext#installBundle() for simple1
> 7. featureXmlURL is set to simple2.xml
> 8. log message:
> {noformat}
> Installing bundle simple2.xml / 0.0.0
> {noformat}
> 9. org.osgi.framework.BundleContext#installBundle() for
[jira] [Commented] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335275#comment-17335275
]
Grzegorz Grzybek commented on KARAF-7126:
-
Unfortunately moving state copy to the task doesn't solve the problem because
what is used to replace THE state of the features service after provisioning
task is not the passed state, but new state calculated after resolution:
{code:java}
//
// Update and save state
//
State newState = new State();
newState.bundleChecksums.putAll(deployment.bundleChecksums);
newState.requirements.putAll(request.requirements);
newState.installedFeatures.putAll(installedFeatures);
newState.stateFeatures.putAll(stateFeatures);
newState.managedBundles.putAll(managedBundles);
callback.saveState(newState);
{code}
So I have to move even the requirements calculation to a callback invoked from
within the task...
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at java.net.URL.openStream(URL.java:1068)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> {noformat}
> 4. in
>
[jira] [Commented] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335222#comment-17335222
]
Grzegorz Grzybek commented on KARAF-7126:
-
Thanks for comment [~gnodet]. I was thinking about lambdas that operate on the
state from within the provisioning thread.
But I think (at first glance) that this pattern:
* copy state before passing to thread
* copy current requirements from the copy of the state
* alter the copy of requirements (in feature installation/uninstallation/)
* pass the altered requirements + the initial copy of the state to the thread
* set the passed copy into
{{org.apache.karaf.features.internal.service.Deployer.DeploymentState#state}}
within the thread
and especially
({{org.apache.karaf.features.internal.service.FeaturesServiceImpl#doProvision()}}:
{code:java}
} catch (Deployer.PartialDeploymentException e) {
if (!prereqs.containsAll(e.getMissing())) {
prereqs.addAll(e.getMissing());
state = copyState();
...
{code}
that we can safely:
* still use a copy of the state made before the thread to prepare new
requirements
* but get another copy of the state as {{Deployer.DeploymentState#state}}
within the thread
I'll try and let you know
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at java.net.URL.openStream(URL.java:1068)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> at
>
[jira] [Commented] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334681#comment-17334681
]
Grzegorz Grzybek commented on KARAF-7126:
-
cc: [~jbonofre], [~gnodet] it seems easy - at least for the
{{FeatureDeploymentListener}} which only calls
{{org.apache.karaf.features.internal.service.FeaturesServiceImpl#updateReposAndRequirements()}}
where state is simply copied from current value and passed to
{{org.apache.karaf.features.internal.service.FeaturesServiceImpl#doProvisionInThread()}}.
But for many other paths, it's not that trivial.
For example, normal {{feature:install}} command copies current state, grabs
current requirements, copies the requirements and adds the features to be
installed and passes the copy of the state (with NOT modified requirements) to
{{doProvisionInThread()}}.
While the task is being processed in single thread pool, other command (or copy
to {{deploy/}}) may happen and a copy of current state is made again - but the
state is NOT yet altered by pending installation task.
I checked the places where state copy is taken and in fact always a copy is
passed, but what is actually needed is for example an updated set of
requirements per region. the state passed to doProvisionInThread() is used to
configure a "deployment state" - can it be copied within the task itself? so we
have kind of serialized access to really current state (updated after previous
provisioning task has finished)?
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.12, 4.3.2
>
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at
[jira] [Commented] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334673#comment-17334673
]
Grzegorz Grzybek commented on KARAF-7126:
-
Soon I'll have some proposal for this fix.
> State overwrite when installing more features at once
> -
>
> Key: KARAF-7126
> URL: https://issues.apache.org/jira/browse/KARAF-7126
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.12, 4.3.2
>
>
> I had a case, where (which is not recommended) two feature XML files were
> dropped into {{deploy/}} directory.
> _Often_ (but not always) one of the features was not marked as "Started" -
> and it happened in random order.
> It can be reproduced with {{simple1.xml}} file:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple1">
>
>
> start="true">mvn:commons-io/commons-io/2.8.0
>
>
>
> {code}
> and {{simple2.xml}}:
> {code:xml}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="simple2">
>
>
> start="true">mvn:commons-collections/commons-collections/3.2.2
>
>
>
> {code}
> dropped at the same time to {{deploy/}} directory.
> Here's my investigation:
> 1. deploy two files
> 2. these artifacts are processed in single fileinstall thread:
> {noformat}
> 0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
> path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
> jaredDirectory: java.io.File = {java.io.File@11683}
> "/data/karaf/deploy/simple1.xml"
> jaredUrl: java.net.URL = {java.net.URL@11703}
> "file:/data/karaf/deploy/simple1.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11646}
> "feature:file:/data/karaf/deploy/simple1.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 1818582559 (0x6C655E1F)
> 1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
> path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
> jaredDirectory: java.io.File = {java.io.File@11696}
> "/data/karaf/deploy/simple2.xml"
> jaredUrl: java.net.URL = {java.net.URL@11697}
> "file:/data/karaf/deploy/simple2.xml"
> listener: org.apache.felix.fileinstall.ArtifactListener =
> {org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
> transformedUrl: java.net.URL = {java.net.URL@11699}
> "feature:file:/data/karaf/deploy/simple2.xml"
> transformed: java.io.File = null
> bundleId: long = -1 (0x)
> checksum: long = 3138423735 (0xBB108BB7)
> {noformat}
> 3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler
> has its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL
> set to file:/data/karaf/deploy/simple1.xml
> stack trace:
> {noformat}
> "fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
> at java.net.URL.openConnection(URL.java:1002)
> at java.net.URL.openStream(URL.java:1068)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> {noformat}
> 4. in
> org.apache.felix.fileinstall.internal.DirectoryWatcher#installOrUpdateBundle,
> simple1 is processed
> 5. log message:
> {noformat}
> Installing bundle simple1.xml / 0.0.0
> {noformat}
> 6. org.osgi.framework.BundleContext#installBundle() for simple1
> 7. featureXmlURL is set to simple2.xml
> 8. log message:
> {noformat}
> Installing bundle simple2.xml / 0.0.0
> {noformat}
> 9. org.osgi.framework.BundleContext#installBundle() for simple2
> Now:
> {noformat}
> 240 │ Installed │ 80 │ 0.0.0│
> feature:file:/data/karaf/deploy/simple1.xml
> 241 │ Installed │ 80 │ 0.0.0│
> feature:file:/data/karaf/deploy/simple2.xml
>
[jira] [Updated] (KARAF-7126) State overwrite when installing more features at once
[
https://issues.apache.org/jira/browse/KARAF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7126:
Description:
I had a case, where (which is not recommended) two feature XML files were
dropped into {{deploy/}} directory.
_Often_ (but not always) one of the features was not marked as "Started" - and
it happened in random order.
It can be reproduced with {{simple1.xml}} file:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="simple1">
mvn:commons-io/commons-io/2.8.0
{code}
and {{simple2.xml}}:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="simple2">
mvn:commons-collections/commons-collections/3.2.2
{code}
dropped at the same time to {{deploy/}} directory.
Here's my investigation:
1. deploy two files
2. these artifacts are processed in single fileinstall thread:
{noformat}
0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
jaredDirectory: java.io.File = {java.io.File@11683}
"/data/karaf/deploy/simple1.xml"
jaredUrl: java.net.URL = {java.net.URL@11703}
"file:/data/karaf/deploy/simple1.xml"
listener: org.apache.felix.fileinstall.ArtifactListener =
{org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
transformedUrl: java.net.URL = {java.net.URL@11646}
"feature:file:/data/karaf/deploy/simple1.xml"
transformed: java.io.File = null
bundleId: long = -1 (0x)
checksum: long = 1818582559 (0x6C655E1F)
1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
jaredDirectory: java.io.File = {java.io.File@11696}
"/data/karaf/deploy/simple2.xml"
jaredUrl: java.net.URL = {java.net.URL@11697}
"file:/data/karaf/deploy/simple2.xml"
listener: org.apache.felix.fileinstall.ArtifactListener =
{org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
transformedUrl: java.net.URL = {java.net.URL@11699}
"feature:file:/data/karaf/deploy/simple2.xml"
transformed: java.io.File = null
bundleId: long = -1 (0x)
checksum: long = 3138423735 (0xBB108BB7)
{noformat}
3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler has
its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL set to
file:/data/karaf/deploy/simple1.xml
stack trace:
{noformat}
"fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
at java.net.URL.openConnection(URL.java:1002)
at java.net.URL.openStream(URL.java:1068)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
{noformat}
4. in
org.apache.felix.fileinstall.internal.DirectoryWatcher#installOrUpdateBundle,
simple1 is processed
5. log message:
{noformat}
Installing bundle simple1.xml / 0.0.0
{noformat}
6. org.osgi.framework.BundleContext#installBundle() for simple1
7. featureXmlURL is set to simple2.xml
8. log message:
{noformat}
Installing bundle simple2.xml / 0.0.0
{noformat}
9. org.osgi.framework.BundleContext#installBundle() for simple2
Now:
{noformat}
240 │ Installed │ 80 │ 0.0.0│
feature:file:/data/karaf/deploy/simple1.xml
241 │ Installed │ 80 │ 0.0.0│
feature:file:/data/karaf/deploy/simple2.xml
{noformat}
10. Of course
org.apache.felix.fileinstall.internal.DirectoryWatcher#doProcess() uses
HashMaps... that's why bundle2 may be started earlier
11. org.apache.felix.fileinstall.internal.FileInstall#refresh() is called for
the two bundles in random order - but they're still in INSTALLED state
12. org.apache.felix.fileinstall.internal.DirectoryWatcher#startBundles() is
called
13. org.osgi.framework.Bundle#start(int) is called for each bundle and the
event is caught by:
{noformat}
"FelixDispatchQueue@11772" prio=5 tid=0xd nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:186)
-
[jira] [Created] (KARAF-7126) State overwrite when installing more features at once
Grzegorz Grzybek created KARAF-7126:
---
Summary: State overwrite when installing more features at once
Key: KARAF-7126
URL: https://issues.apache.org/jira/browse/KARAF-7126
Project: Karaf
Issue Type: Bug
Affects Versions: 4.3.1, 4.2.11
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
Fix For: 4.2.12, 4.3.2
I had a case, where (which is not recommended) two feature XML files were
dropped into {{deploy/}} directory.
_Often_ (but not always) one of the features was not marked as "Started" - and
it happened in random order.
It can be reproduced with {{simple1.xml}} file:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="simple1">
mvn:commons-io/commons-io/2.8.0
{code}
and {{simple2.xml}}:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="simple2">
mvn:commons-collections/commons-collections/3.2.2
{code}
dropped at the same time to {{deploy/}} directory.
Here's my investigation:
1. deploy two files
2. these artifacts are processed in single fileinstall thread:
{noformat}
0 = {org.apache.felix.fileinstall.internal.Artifact@11682}
path: java.io.File = {java.io.File@11683} "/data/karaf/deploy/simple1.xml"
jaredDirectory: java.io.File = {java.io.File@11683}
"/data/karaf/deploy/simple1.xml"
jaredUrl: java.net.URL = {java.net.URL@11703}
"file:/data/karaf/deploy/simple1.xml"
listener: org.apache.felix.fileinstall.ArtifactListener =
{org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
transformedUrl: java.net.URL = {java.net.URL@11646}
"feature:file:/data/karaf/deploy/simple1.xml"
transformed: java.io.File = null
bundleId: long = -1 (0x)
checksum: long = 1818582559 (0x6C655E1F)
1 = {org.apache.felix.fileinstall.internal.Artifact@11694}
path: java.io.File = {java.io.File@11696} "/data/karaf/deploy/simple2.xml"
jaredDirectory: java.io.File = {java.io.File@11696}
"/data/karaf/deploy/simple2.xml"
jaredUrl: java.net.URL = {java.net.URL@11697}
"file:/data/karaf/deploy/simple2.xml"
listener: org.apache.felix.fileinstall.ArtifactListener =
{org.apache.karaf.deployer.features.FeatureDeploymentListener@11698}
transformedUrl: java.net.URL = {java.net.URL@11699}
"feature:file:/data/karaf/deploy/simple2.xml"
transformed: java.io.File = null
bundleId: long = -1 (0x)
checksum: long = 3138423735 (0xBB108BB7)
3. single instance of org.apache.karaf.deployer.features.FeatureURLHandler has
its org.apache.karaf.deployer.features.FeatureURLHandler#featureXmlURL set to
file:/data/karaf/deploy/simple1.xml
stack trace:
{noformat}
"fileinstall-/data/karaf/deploy@11585" daemon prio=5 tid=0x2e nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.karaf.deployer.features.FeatureURLHandler.openConnection(FeatureURLHandler.java:56)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:271)
at java.net.URL.openConnection(URL.java:1002)
at java.net.URL.openStream(URL.java:1068)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
{noformat}
4. in
org.apache.felix.fileinstall.internal.DirectoryWatcher#installOrUpdateBundle,
simple1 is processed
5. log message:
{noformat}
Installing bundle simple1.xml / 0.0.0
{noformat}
6. org.osgi.framework.BundleContext#installBundle() for simple1
7. featureXmlURL is set to simple2.xml
8. log message:
{noformat}
Installing bundle simple2.xml / 0.0.0
{noformat}
9. org.osgi.framework.BundleContext#installBundle() for simple2
Now:
{noformat}
240 │ Installed │ 80 │ 0.0.0│
feature:file:/data/karaf/deploy/simple1.xml
241 │ Installed │ 80 │ 0.0.0│
feature:file:/data/karaf/deploy/simple2.xml
{noformat}
10. Of course
org.apache.felix.fileinstall.internal.DirectoryWatcher#doProcess() uses
HashMaps... that's why bundle2 may be started earlier
11. org.apache.felix.fileinstall.internal.FileInstall#refresh() is called for
the two bundles in random order - but they're still in INSTALLED state
12. org.apache.felix.fileinstall.internal.DirectoryWatcher#startBundles() is
called
13. org.osgi.framework.Bundle#start(int) is called for each bundle and the
event is caught by:
{noformat}
[jira] [Commented] (KARAF-7096) When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
[
https://issues.apache.org/jira/browse/KARAF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317195#comment-17317195
]
Grzegorz Grzybek commented on KARAF-7096:
-
PR: https://github.com/apache/karaf/pull/1343
> When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
>
>
> Key: KARAF-7096
> URL: https://issues.apache.org/jira/browse/KARAF-7096
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.12, 4.3.2
>
>
> It's a follow-up of the investigation from KARAF-6955. Copying the
> description:
> I had problem after this change - {{jconsole}} stopped working and sample
> Java application ended with {{Connection refused}} exception.
> I did enjoyable analysis and I found that:
> * ports are opened on proper interfaces ({{:::127.0.0.1}} in my case,
> which is an IPv6 address from _:::0:0/96 CIDR_ that represents
> _Transition from IPv4_ address block)
> * I could connect to RMI Registry at port 1099 and even obtain {{karaf-root}}
> object from there, which:
> ** is of {{javax.management.remote.rmi.RMIServer}} interface
> ** is of {{javax.management.remote.rmi.RMIServerImpl_Stub}} implementation
> The problem is that this stub contains:
> {noformat}
> ref: java.rmi.server.RemoteRef = {sun.rmi.server.UnicastRef2@1918}
> ...
> ref: sun.rmi.transport.LiveRef = {sun.rmi.transport.LiveRef@1925}
> "[endpoint:[192.168.0.38:4](remote),objID:[2f23195f:178a6a29327:-7ffa,
> 4962682433218761153]]"
> ep: sun.rmi.transport.Endpoint = {sun.rmi.transport.tcp.TCPEndpoint@1927}
> "[192.168.0.38:4]"
>host: java.lang.String = "192.168.0.38"
>port: int = 4 (0xAD9C)
> {noformat}
> The problem is that when {{RMIServerImpl_Stub}} is created *at server side*
> by karaf.management.server bundle, the bind address of this remote object is
> NOT taken from {{rmiServerHost}} property of {{org.apache.karaf.management}}
> PID. It's taken from (top to bottom):
> * sun.rmi.transport.tcp.TCPEndpoint#getLocalEndpoint()
> * java.net.InetAddress#getLocalHost()
> * java.net.InetAddressImpl#getLocalHostName()
> * java.net.InetAddress#getAddressesFromNameService()
> * java.net.Inet6AddressImpl#lookupAllHostAddr()
> * getaddress() libc method
> * /etc/hosts
> The way to solve this is to set {{java.rmi.server.hostname}} system property
> to 127.0.0.1, so the Stub contains proper address.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KARAF-7096) When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
[
https://issues.apache.org/jira/browse/KARAF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7096:
Affects Version/s: 4.2.11
4.3.1
> When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
>
>
> Key: KARAF-7096
> URL: https://issues.apache.org/jira/browse/KARAF-7096
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> It's a follow-up of the investigation from KARAF-6955. Copying the
> description:
> I had problem after this change - {{jconsole}} stopped working and sample
> Java application ended with {{Connection refused}} exception.
> I did enjoyable analysis and I found that:
> * ports are opened on proper interfaces ({{:::127.0.0.1}} in my case,
> which is an IPv6 address from _:::0:0/96 CIDR_ that represents
> _Transition from IPv4_ address block)
> * I could connect to RMI Registry at port 1099 and even obtain {{karaf-root}}
> object from there, which:
> ** is of {{javax.management.remote.rmi.RMIServer}} interface
> ** is of {{javax.management.remote.rmi.RMIServerImpl_Stub}} implementation
> The problem is that this stub contains:
> {noformat}
> ref: java.rmi.server.RemoteRef = {sun.rmi.server.UnicastRef2@1918}
> ...
> ref: sun.rmi.transport.LiveRef = {sun.rmi.transport.LiveRef@1925}
> "[endpoint:[192.168.0.38:4](remote),objID:[2f23195f:178a6a29327:-7ffa,
> 4962682433218761153]]"
> ep: sun.rmi.transport.Endpoint = {sun.rmi.transport.tcp.TCPEndpoint@1927}
> "[192.168.0.38:4]"
>host: java.lang.String = "192.168.0.38"
>port: int = 4 (0xAD9C)
> {noformat}
> The problem is that when {{RMIServerImpl_Stub}} is created *at server side*
> by karaf.management.server bundle, the bind address of this remote object is
> NOT taken from {{rmiServerHost}} property of {{org.apache.karaf.management}}
> PID. It's taken from (top to bottom):
> * sun.rmi.transport.tcp.TCPEndpoint#getLocalEndpoint()
> * java.net.InetAddress#getLocalHost()
> * java.net.InetAddressImpl#getLocalHostName()
> * java.net.InetAddress#getAddressesFromNameService()
> * java.net.Inet6AddressImpl#lookupAllHostAddr()
> * getaddress() libc method
> * /etc/hosts
> The way to solve this is to set {{java.rmi.server.hostname}} system property
> to 127.0.0.1, so the Stub contains proper address.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KARAF-7096) When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
[
https://issues.apache.org/jira/browse/KARAF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7096:
Fix Version/s: 4.3.2
4.2.12
> When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
>
>
> Key: KARAF-7096
> URL: https://issues.apache.org/jira/browse/KARAF-7096
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.2.11, 4.3.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.12, 4.3.2
>
>
> It's a follow-up of the investigation from KARAF-6955. Copying the
> description:
> I had problem after this change - {{jconsole}} stopped working and sample
> Java application ended with {{Connection refused}} exception.
> I did enjoyable analysis and I found that:
> * ports are opened on proper interfaces ({{:::127.0.0.1}} in my case,
> which is an IPv6 address from _:::0:0/96 CIDR_ that represents
> _Transition from IPv4_ address block)
> * I could connect to RMI Registry at port 1099 and even obtain {{karaf-root}}
> object from there, which:
> ** is of {{javax.management.remote.rmi.RMIServer}} interface
> ** is of {{javax.management.remote.rmi.RMIServerImpl_Stub}} implementation
> The problem is that this stub contains:
> {noformat}
> ref: java.rmi.server.RemoteRef = {sun.rmi.server.UnicastRef2@1918}
> ...
> ref: sun.rmi.transport.LiveRef = {sun.rmi.transport.LiveRef@1925}
> "[endpoint:[192.168.0.38:4](remote),objID:[2f23195f:178a6a29327:-7ffa,
> 4962682433218761153]]"
> ep: sun.rmi.transport.Endpoint = {sun.rmi.transport.tcp.TCPEndpoint@1927}
> "[192.168.0.38:4]"
>host: java.lang.String = "192.168.0.38"
>port: int = 4 (0xAD9C)
> {noformat}
> The problem is that when {{RMIServerImpl_Stub}} is created *at server side*
> by karaf.management.server bundle, the bind address of this remote object is
> NOT taken from {{rmiServerHost}} property of {{org.apache.karaf.management}}
> PID. It's taken from (top to bottom):
> * sun.rmi.transport.tcp.TCPEndpoint#getLocalEndpoint()
> * java.net.InetAddress#getLocalHost()
> * java.net.InetAddressImpl#getLocalHostName()
> * java.net.InetAddress#getAddressesFromNameService()
> * java.net.Inet6AddressImpl#lookupAllHostAddr()
> * getaddress() libc method
> * /etc/hosts
> The way to solve this is to set {{java.rmi.server.hostname}} system property
> to 127.0.0.1, so the Stub contains proper address.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KARAF-7096) When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still uses hostname's IP
Grzegorz Grzybek created KARAF-7096:
---
Summary: When rmiServerHost is 127.0.0.1, RMIServerImpl_Stub still
uses hostname's IP
Key: KARAF-7096
URL: https://issues.apache.org/jira/browse/KARAF-7096
Project: Karaf
Issue Type: Bug
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
It's a follow-up of the investigation from KARAF-6955. Copying the description:
I had problem after this change - {{jconsole}} stopped working and sample Java
application ended with {{Connection refused}} exception.
I did enjoyable analysis and I found that:
* ports are opened on proper interfaces ({{:::127.0.0.1}} in my case, which
is an IPv6 address from _:::0:0/96 CIDR_ that represents _Transition from
IPv4_ address block)
* I could connect to RMI Registry at port 1099 and even obtain {{karaf-root}}
object from there, which:
** is of {{javax.management.remote.rmi.RMIServer}} interface
** is of {{javax.management.remote.rmi.RMIServerImpl_Stub}} implementation
The problem is that this stub contains:
{noformat}
ref: java.rmi.server.RemoteRef = {sun.rmi.server.UnicastRef2@1918}
...
ref: sun.rmi.transport.LiveRef = {sun.rmi.transport.LiveRef@1925}
"[endpoint:[192.168.0.38:4](remote),objID:[2f23195f:178a6a29327:-7ffa,
4962682433218761153]]"
ep: sun.rmi.transport.Endpoint = {sun.rmi.transport.tcp.TCPEndpoint@1927}
"[192.168.0.38:4]"
host: java.lang.String = "192.168.0.38"
port: int = 4 (0xAD9C)
{noformat}
The problem is that when {{RMIServerImpl_Stub}} is created *at server side* by
karaf.management.server bundle, the bind address of this remote object is NOT
taken from {{rmiServerHost}} property of {{org.apache.karaf.management}} PID.
It's taken from (top to bottom):
* sun.rmi.transport.tcp.TCPEndpoint#getLocalEndpoint()
* java.net.InetAddress#getLocalHost()
* java.net.InetAddressImpl#getLocalHostName()
* java.net.InetAddress#getAddressesFromNameService()
* java.net.Inet6AddressImpl#lookupAllHostAddr()
* getaddress() libc method
* /etc/hosts
The way to solve this is to set {{java.rmi.server.hostname}} system property to
127.0.0.1, so the Stub contains proper address.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-6955) JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
[
https://issues.apache.org/jira/browse/KARAF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316869#comment-17316869
]
Grzegorz Grzybek commented on KARAF-6955:
-
I'll prepare a PR today, ok?
> JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
>
>
> Key: KARAF-6955
> URL: https://issues.apache.org/jira/browse/KARAF-6955
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.9
>Reporter: Martin Lichtin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.11, 4.3.1
>
>
> JMX - with rmiRegistryHost = 127.0.0.1 Karaf should listen only on 127.0.0.1
> However, Karaf listens on 0.0.0.0 which opens up access to the network.
> {noformat}
> > config:list "(service.pid=org.apache.karaf.management)"
>
> Pid:org.apache.karaf.management
> BundleLocation: ?
> Properties:
>daemon = true
>felix.fileinstall.filename =
> file:mykaraf/etc/org.apache.karaf.management.cfg
>jmxRealm = karaf
>jmxmpEnabled = false
>jmxmpHost = 127.0.0.1
>jmxmpObjectName = connector:name=jmxmp
>jmxmpPort =
>jmxmpServiceUrl = service:jmx:jmxmp://127.0.0.1:
>objectName = connector:name=rmi
>rmiRegistryHost = 127.0.0.1
>rmiRegistryPort = 25031
>rmiServerHost = 127.0.0.1
>rmiServerPort = 25041
>service.pid = org.apache.karaf.management
>serviceUrl =
> service:jmx:rmi://127.0.0.1:25041/jndi/rmi://127.0.0.1:25031/karaf-mykaraf
>threaded = true
> {noformat}
> Using netstat one can see the listen address is not 127.0.0.1:
> {noformat}
> $ netstat -n -l -t|grep 25031
> tcp 0 0 0.0.0.0:25031 0.0.0.0:* LISTEN
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KARAF-6955) JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
[
https://issues.apache.org/jira/browse/KARAF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316350#comment-17316350
]
Grzegorz Grzybek edited comment on KARAF-6955 at 4/7/21, 1:51 PM:
--
I've talked a bit with [~jbonofre]. In my opinion, activator of
karaf.management.server bundle should (seeing {{rmiServerHost}} property)
immediately call {{System.setProperty("java.rmi.server.hostname", )}}. Because it IS RMI endpoint.
We all know, that JDK itself (especially {{sun.\*}} and {{com.sun.\*}})
packages are full of static methods/fields configured using only system
properties... I don't see any elegant solution here.
was (Author: gzres):
I've talked a bit with [~jbonofre]. In my opinion, activator of
karaf.management.server bundle should (seeing {{rmiServerHost}} property)
immediately call {{System.setProperty("java.rmi.server.hostname", )}}. Because it IS RMI endpoint.
We all know, that JDK itself (especially {{sun.*}} and {{com.sun.*}}) packages
are full of static methods/fields configured using only system properties... I
don't see any elegant solution here.
> JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
>
>
> Key: KARAF-6955
> URL: https://issues.apache.org/jira/browse/KARAF-6955
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.9
>Reporter: Martin Lichtin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.11, 4.3.1
>
>
> JMX - with rmiRegistryHost = 127.0.0.1 Karaf should listen only on 127.0.0.1
> However, Karaf listens on 0.0.0.0 which opens up access to the network.
> {noformat}
> > config:list "(service.pid=org.apache.karaf.management)"
>
> Pid:org.apache.karaf.management
> BundleLocation: ?
> Properties:
>daemon = true
>felix.fileinstall.filename =
> file:mykaraf/etc/org.apache.karaf.management.cfg
>jmxRealm = karaf
>jmxmpEnabled = false
>jmxmpHost = 127.0.0.1
>jmxmpObjectName = connector:name=jmxmp
>jmxmpPort =
>jmxmpServiceUrl = service:jmx:jmxmp://127.0.0.1:
>objectName = connector:name=rmi
>rmiRegistryHost = 127.0.0.1
>rmiRegistryPort = 25031
>rmiServerHost = 127.0.0.1
>rmiServerPort = 25041
>service.pid = org.apache.karaf.management
>serviceUrl =
> service:jmx:rmi://127.0.0.1:25041/jndi/rmi://127.0.0.1:25031/karaf-mykaraf
>threaded = true
> {noformat}
> Using netstat one can see the listen address is not 127.0.0.1:
> {noformat}
> $ netstat -n -l -t|grep 25031
> tcp 0 0 0.0.0.0:25031 0.0.0.0:* LISTEN
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-6955) JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
[
https://issues.apache.org/jira/browse/KARAF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316350#comment-17316350
]
Grzegorz Grzybek commented on KARAF-6955:
-
I've talked a bit with [~jbonofre]. In my opinion, activator of
karaf.management.server bundle should (seeing {{rmiServerHost}} property)
immediately call {{System.setProperty("java.rmi.server.hostname", )}}. Because it IS RMI endpoint.
We all know, that JDK itself (especially {{sun.*}} and {{com.sun.*}}) packages
are full of static methods/fields configured using only system properties... I
don't see any elegant solution here.
> JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
>
>
> Key: KARAF-6955
> URL: https://issues.apache.org/jira/browse/KARAF-6955
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.9
>Reporter: Martin Lichtin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.11, 4.3.1
>
>
> JMX - with rmiRegistryHost = 127.0.0.1 Karaf should listen only on 127.0.0.1
> However, Karaf listens on 0.0.0.0 which opens up access to the network.
> {noformat}
> > config:list "(service.pid=org.apache.karaf.management)"
>
> Pid:org.apache.karaf.management
> BundleLocation: ?
> Properties:
>daemon = true
>felix.fileinstall.filename =
> file:mykaraf/etc/org.apache.karaf.management.cfg
>jmxRealm = karaf
>jmxmpEnabled = false
>jmxmpHost = 127.0.0.1
>jmxmpObjectName = connector:name=jmxmp
>jmxmpPort =
>jmxmpServiceUrl = service:jmx:jmxmp://127.0.0.1:
>objectName = connector:name=rmi
>rmiRegistryHost = 127.0.0.1
>rmiRegistryPort = 25031
>rmiServerHost = 127.0.0.1
>rmiServerPort = 25041
>service.pid = org.apache.karaf.management
>serviceUrl =
> service:jmx:rmi://127.0.0.1:25041/jndi/rmi://127.0.0.1:25031/karaf-mykaraf
>threaded = true
> {noformat}
> Using netstat one can see the listen address is not 127.0.0.1:
> {noformat}
> $ netstat -n -l -t|grep 25031
> tcp 0 0 0.0.0.0:25031 0.0.0.0:* LISTEN
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-6955) JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
[
https://issues.apache.org/jira/browse/KARAF-6955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315418#comment-17315418
]
Grzegorz Grzybek commented on KARAF-6955:
-
I had problem after this change - {{jconsole}} stopped working and sample Java
application ended with {{Connection refused}} exception.
I did enjoyable analysis and I found that:
* ports are opened on proper interfaces ({{:::127.0.0.1}} in my case, which
is an IPv6 address from _:::0:0/96 CIDR_ that represents _Transition from
IPv4_ address block)
* I could connect to RMI Registry at port 1099 and even obtain {{karaf-root}}
object from there, which:
** is of {{javax.management.remote.rmi.RMIServer}} interface
** is of {{javax.management.remote.rmi.RMIServerImpl_Stub}} implementation
The problem is that this stub contains:
{noformat}
ref: java.rmi.server.RemoteRef = {sun.rmi.server.UnicastRef2@1918}
...
ref: sun.rmi.transport.LiveRef = {sun.rmi.transport.LiveRef@1925}
"[endpoint:[192.168.0.38:4](remote),objID:[2f23195f:178a6a29327:-7ffa,
4962682433218761153]]"
ep: sun.rmi.transport.Endpoint = {sun.rmi.transport.tcp.TCPEndpoint@1927}
"[192.168.0.38:4]"
host: java.lang.String = "192.168.0.38"
port: int = 4 (0xAD9C)
{noformat}
The problem is that when {{RMIServerImpl_Stub}} is created *at server side* by
karaf.management.server bundle, the bind address of this remote object is NOT
taken from {{rmiServerHost}} property of {{org.apache.karaf.management}} PID.
It's taken from (top to bottom):
* sun.rmi.transport.tcp.TCPEndpoint#getLocalEndpoint()
* java.net.InetAddress#getLocalHost()
* java.net.InetAddressImpl#getLocalHostName()
* java.net.InetAddress#getAddressesFromNameService()
* java.net.Inet6AddressImpl#lookupAllHostAddr()
* getaddress() libc method
* /etc/hosts
The way to solve this is to set {{java.rmi.server.hostname}} system property to
127.0.0.1, so the Stub contains proper address.
> JMX: With rmiRegistryHost = 127.0.0.1, Karaf should listen only on 127.0.0.1
>
>
> Key: KARAF-6955
> URL: https://issues.apache.org/jira/browse/KARAF-6955
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.9
>Reporter: Martin Lichtin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.11, 4.3.1
>
>
> JMX - with rmiRegistryHost = 127.0.0.1 Karaf should listen only on 127.0.0.1
> However, Karaf listens on 0.0.0.0 which opens up access to the network.
> {noformat}
> > config:list "(service.pid=org.apache.karaf.management)"
>
> Pid:org.apache.karaf.management
> BundleLocation: ?
> Properties:
>daemon = true
>felix.fileinstall.filename =
> file:mykaraf/etc/org.apache.karaf.management.cfg
>jmxRealm = karaf
>jmxmpEnabled = false
>jmxmpHost = 127.0.0.1
>jmxmpObjectName = connector:name=jmxmp
>jmxmpPort =
>jmxmpServiceUrl = service:jmx:jmxmp://127.0.0.1:
>objectName = connector:name=rmi
>rmiRegistryHost = 127.0.0.1
>rmiRegistryPort = 25031
>rmiServerHost = 127.0.0.1
>rmiServerPort = 25041
>service.pid = org.apache.karaf.management
>serviceUrl =
> service:jmx:rmi://127.0.0.1:25041/jndi/rmi://127.0.0.1:25031/karaf-mykaraf
>threaded = true
> {noformat}
> Using netstat one can see the listen address is not 127.0.0.1:
> {noformat}
> $ netstat -n -l -t|grep 25031
> tcp 0 0 0.0.0.0:25031 0.0.0.0:* LISTEN
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309323#comment-17309323
]
Grzegorz Grzybek edited comment on KARAF-7084 at 3/26/21, 10:09 AM:
And finally, a real archaeology... JEP 268: XML Catalog API was generally
related to exposing internal (in JDK8):
{noformat}
com.sun.org.apache.xml.internal.resolver.CatalogManager
{noformat}
as public (in JDK9+, {{java.xml}} module):
{noformat}
javax.xml.catalog.CatalogManager
{noformat}
{{com.sun.org.apache.xml.internal.resolver.CatalogManager}} is of course
related to {{org.apache.xml.resolver.CatalogManager}} which is available in
https://search.maven.org/artifact/xml-resolver/xml-resolver/1.2/jar with the
source code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-resolver-1_2/
Original (\?) JAXP API is available through
https://search.maven.org/artifact/xml-apis/xml-apis/1.4.01/jar with the source
code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-external-1_4_01/
There are SMX bundles both for Xerces and Xalan, which require (through
Import-Package):
* Xalan needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.bcel/5.2_4
* Xerces needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver/1.2_5
So when installing Xerces/Xalan SMX bundles, we need to ensure that the
requirements are also installed (see for example Camel's {{camel-box}} Karaf
feature).
was (Author: gzres):
And finally, a real archaeology... JEP 268: XML Catalog API was generally
related to exposing internal (in JDK8):
{noformat}
com.sun.org.apache.xml.internal.resolver.CatalogManager
{noformat}
as public (in JDK9+, {{java.xml}} module):
{noformat}
javax.xml.catalog.CatalogManager
{noformat}
{{com.sun.org.apache.xml.internal.resolver.CatalogManager}} is of course
related to {{org.apache.xml.resolver.CatalogManager}} which is available in
https://search.maven.org/artifact/xml-resolver/xml-resolver/1.2/jar with the
source code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-resolver-1_2/
Original (?) JAXP API is available through
https://search.maven.org/artifact/xml-apis/xml-apis/1.4.01/jar with the source
code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-external-1_4_01/
There are SMX bundles both for Xerces and Xalan, which require (through
Import-Package):
* Xalan needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.bcel/5.2_4
* Xerces needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver/1.2_5
So when installing Xerces/Xalan SMX bundles, we need to ensure that the
requirements are also installed (see for example Camel's {{camel-box}} Karaf
feature).
> Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
>
>
> Key: KARAF-7084
> URL: https://issues.apache.org/jira/browse/KARAF-7084
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.2
>
>
> I was checking this code:
> {code:java}
> System.out.println("== JAXP");
> info(DatatypeFactory.class, DatatypeFactory.newInstance());
> info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
> info(SAXParserFactory.class, SAXParserFactory.newInstance());
> info(XMLEventFactory.class, XMLEventFactory.newInstance());
> info(XMLInputFactory.class, XMLInputFactory.newInstance());
> info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
> info(TransformerFactory.class, TransformerFactory.newInstance());
> info(SchemaFactory.class,
> SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
> info(XPathFactory.class, XPathFactory.newInstance());
> System.out.println("== SAAJ");
> try {
> info(MessageFactory.class, MessageFactory.newInstance());
> info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
> info(SOAPFactory.class, SOAPFactory.newInstance());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAX-WS");
> try {
> info(Provider.class, Provider.provider());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAXB");
> try {
> info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
> getClass().getClassLoader()));
> Class cfClass =
> FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
> System.out.println("ContextFactory class = " + cfClass);
> } catch (Throwable ignored) {
> }
> ...
> private void info(Class clazz, Object service) {
> System.out.printf(" - %s: %s%n", clazz,
[jira] [Commented] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309323#comment-17309323
]
Grzegorz Grzybek commented on KARAF-7084:
-
And finally, a real archaeology... JEP 268: XML Catalog API was generally
related to exposing internal (in JDK8):
{noformat}
com.sun.org.apache.xml.internal.resolver.CatalogManager
{noformat}
as public (in JDK9+, {{java.xml}} module):
{noformat}
javax.xml.catalog.CatalogManager
{noformat}
{{com.sun.org.apache.xml.internal.resolver.CatalogManager}} is of course
related to {{org.apache.xml.resolver.CatalogManager}} which is available in
https://search.maven.org/artifact/xml-resolver/xml-resolver/1.2/jar with the
source code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-resolver-1_2/
Original (?) JAXP API is available through
https://search.maven.org/artifact/xml-apis/xml-apis/1.4.01/jar with the source
code available in
http://svn.apache.org/repos/asf/xerces/xml-commons/tags/xml-commons-external-1_4_01/
There are SMX bundles both for Xerces and Xalan, which require (through
Import-Package):
* Xalan needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.bcel/5.2_4
* Xerces needs
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xmlresolver/1.2_5
So when installing Xerces/Xalan SMX bundles, we need to ensure that the
requirements are also installed (see for example Camel's {{camel-box}} Karaf
feature).
> Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
>
>
> Key: KARAF-7084
> URL: https://issues.apache.org/jira/browse/KARAF-7084
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.2
>
>
> I was checking this code:
> {code:java}
> System.out.println("== JAXP");
> info(DatatypeFactory.class, DatatypeFactory.newInstance());
> info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
> info(SAXParserFactory.class, SAXParserFactory.newInstance());
> info(XMLEventFactory.class, XMLEventFactory.newInstance());
> info(XMLInputFactory.class, XMLInputFactory.newInstance());
> info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
> info(TransformerFactory.class, TransformerFactory.newInstance());
> info(SchemaFactory.class,
> SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
> info(XPathFactory.class, XPathFactory.newInstance());
> System.out.println("== SAAJ");
> try {
> info(MessageFactory.class, MessageFactory.newInstance());
> info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
> info(SOAPFactory.class, SOAPFactory.newInstance());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAX-WS");
> try {
> info(Provider.class, Provider.provider());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAXB");
> try {
> info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
> getClass().getClassLoader()));
> Class cfClass =
> FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
> System.out.println("ContextFactory class = " + cfClass);
> } catch (Throwable ignored) {
> }
> ...
> private void info(Class clazz, Object service) {
> System.out.printf(" - %s: %s%n", clazz, service.getClass().getName());
> System.out.printf(" - %s%n", FrameworkUtil.getBundle(service.getClass()));
> }
> {code}
> TO see if I really can get implementations of JAXP interfaces, if given
> interface is implemented in a bundle with proper
> {{/META-INF/services/}}. It works well with _some_ JAXP
> interfaces and with SAAJ. However it doesn't work with:
> * javax.xml.validation.SchemaFactory
> * javax.xml.xpath.XPathFactory
> * org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded
> factory in {{java.xml}} Karaf spec)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309302#comment-17309302
]
Grzegorz Grzybek commented on KARAF-7084:
-
Knowing that "Karaf specs" modules are supposed to enhance the discovery
mechanisms highlighted in JAXP specification, I believe it is wise to assume
few requirements:
* karaf/specs/java.xml[.ws] libraries should shade/replace _original_ discovery
mechanisms from JAXP 1.6 and further JDK9+ releases which don't increment JAXP
specification version without touching anything else
* we should keep every possible discovery step (like checking
{{jaxp.properties}} file or some system properties) and only add _OSGi locator_
step before proceeding to {{ServiceLoader}} usage
* we should change _every_ JAXP factory and also JAXB/SAAJ/JAX-RS/JAX-WS
* we also should change the Activation API discovery mechanism when searching
for:
** {{META-INF/mailcap}}
** {{META-INF/mime.types}}
[~gnodet] confirmed that Karaf's {{specs}} module is an incarnation of SMX
{{locator}} + {{activator}} libraries that themselves are based on JAXP APIs
that _may_ (please confirm [~gnodet]) date back to very old APIs from before
the time where {{ServiceLoader}} was used everywhere.
I wanted to track down the JAXP API source code to work on two goals:
* Karaf's XML spec libraries for JDK8 should go to {{endorsed}} directory and
should be based on real JAXP source code from jdk8u repositories
* Karaf's XML spec libraries for JDK9+ (effectively JDK11+) should be used with
{{--patch-module=java.xml}} and should be based on real *post-JAXP* source code
from jdk11u repositories
Fortunately, with [JEP 369|https://openjdk.java.net/jeps/369] we can finally
see entire history of all (relevant) JDKs (including JDK8) in GitHub. For me
personally it's much easier to track history of individual files/packages in
Git than in Mercurial.
So here's what I found in https://github.com/openjdk/jdk8u/tree/master/jaxp:
{noformat}
* (2017-10-19 17:03:20 +0100) 9dff2c4611 8186080: Transform XML interfaces
810: A JAXB JCK test failure found after 8186080
* (2017-04-06 21:26:31 +0300) bab2bdb000 8176731: JCK tests in
api/javax_xml/transform/ spec conformance started failing after 8172469
* (2017-03-07 13:49:26 +0300) c435b236e9 8172469: Transform Transformer
Exceptions
* (2014-01-28 09:20:40 -0800) 951552b79f 8032392: Spec:
javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String,
ClassLoader) referring to ServiceLoader.load(Class, ClassLoader)
* (2013-12-23 11:26:36 -0800) 8164cbcdd1 8029236: Update copyright year to
match last edit in jdk8 jaxp repository for 2013
* (2013-12-12 11:36:40 -0800) a1f10b3f0b 8029895:
XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
* (2013-12-04 00:17:12 -0800) fcc3014ea5 8027973: Error in the documentation
for newFactory method of the javax.xml.stream factories
* (2013-10-11 19:49:44 +0100) 5528179e83 Merge
|\
| * (2013-07-17 18:46:28 +0200) dee5d80756 8013502: Improve stream factories
* | (2013-10-04 19:15:10 +0200) 785483b7a9 8025745: Clarify API documentation
of JAXP factories
|/
* (2013-06-06 20:40:43 +0400) 53ae44836c 8009579: Xpathexception does not honor
initcause()
* (2013-05-10 09:23:22 -0700) 8620b1e2d7 8014333: javadoc error in JAXP 1.5
patch
* (2013-05-08 23:38:03 -0700) f0330c4199 8011653: Upgrade JDK8 to JAXP 1.5
* (2013-04-17 15:23:19 +0200) 9a94591b8e 8005954: JAXP Plugability Layer should
use java.util.ServiceLoader
* (2013-02-18 11:33:35 -0800) 8b12f5abcc 6657673: Issues with JAXP
* (2013-02-05 14:56:34 +) 3d09f6b621 8007389: Remove uses of _ as
identifier in jaxp
* (2012-12-27 18:17:58 -0800) c04f299d28 8005473: Warnings compiling jaxp
* (2012-08-17 09:49:42 -0700) 5d2e65169c 7191547:
XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work
as expected
* (2012-04-17 11:17:59 -0700) db4db38876 7160380: Sync JDK8 with JAXP 1.4.5
* (2012-04-12 08:38:26 -0700) 60663487f6 7160496: Rename JDK8 JAXP source
directory
{noformat}
There are no major changes after 2013.
Checking the same for
https://github.com/openjdk/jdk11u/tree/master/src/java.xml/share/classes, and
including the refactorings related to modularization I found that {{8032392}}
bug:
bq. Spec:
javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String,
ClassLoader) referring to ServiceLoader.load(Class, ClassLoader)
is present in both JDK8 and JDK11. Then {{2098d07f0f 8172469: Transform
Transformer Exceptions}} is also added to both JDK8 and JDK11 around 2017.
I found some synchronization with Xerces/Xalan, but the very interesting thing
is https://github.com/openjdk/jdk11u/commit/ed903000ea related to
https://bugs.openjdk.java.net/browse/JDK-8081248:
bq. JDK-8081248 – Implement JEP 268: XML Catalog API
Even if JDK-8081248 mentions {{jaxp}}
[jira] [Comment Edited] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309280#comment-17309280
]
Grzegorz Grzybek edited comment on KARAF-7084 at 3/26/21, 9:03 AM:
---
Here are some interesting (archaeology) findings about "Java + XML"...
As mentioned in [JSR 5 - JAXP 1.0|https://jcp.org/en/jsr/detail?id=5]:
bq. {color:blue}In many ways, XML and the Java Platform are a partnership made
in heaven.{color}
There were handy overview pages like:
* https://docs.oracle.com/javase/6/docs/index.html
* https://docs.oracle.com/javase/7/docs/index.html
* https://docs.oracle.com/javase/8/docs/index.html
But the pages changed after JDK8.
There were also pages explicitly for JAXP:
* https://docs.oracle.com/javase/6/docs/technotes/guides/xml/jaxp/index.html
* https://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/index.html
* https://docs.oracle.com/javase/8/docs/technotes/guides/xml/jaxp/index.html
That mentioned these packages (for all the 3 JDKs: 6, 7 and 8):
* javax.xml.datatype
* javax.xml.namespace
* javax.xml.parsers
* javax.xml.stream
* javax.xml.stream.events
* javax.xml.stream.util
* javax.xml.transform
* javax.xml.transform.dom
* javax.xml.transform.sax
* javax.xml.transform.stax
* javax.xml.transform.stream
* javax.xml.validation
* javax.xml.xpath
* org.w3c.dom
* org.w3c.dom.ranges
* org.w3c.dom.traversal
* org.w3c.dom.bootstrap
* org.w3c.dom.events
* org.w3c.dom.ls
* org.xml.sax
* org.xml.sax.ext
* org.xml.sax.helpers
The differences are explicitly highlighted:
*JDK 6*:
bq. The Java Platform, Standard Edition version 6.0 includes JAXP 1.4. JAXP 1.4
is a maintenance release of JAXP 1.3 with support for the Streaming API for XML
(StAX).
*JDK 7*:
bq. The Java Platform, Standard Edition version 7.0 includes JAXP 1.4. JAXP 1.4
is a maintenance release of JAXP 1.3 with support for the Streaming API for XML
(StAX).
*JDK 8*:
bq. The Java SE 7 Update 40 release includes JAXP 1.5.0. The Java SE 8 release
includes JAXP 1.6.
So actually JAXP 1.5 was introduced after JDK7u40.
What is most important in my opinion is this:
{quote}
The Java SE 8 release contains Java API for XML Processing (JAXP) 1.6, which
requires the use of the service provider loader facility defined by
java.util.ServiceLoader to load services from service configuration files. The
rationale for this is to allow for future modularization of the Java SE
platform where service providers may be deployed by means other than JAR files
and perhaps without the service configuration files. Note that the JAXP has
always specified the use of the 'Services API' without reference to a specific
API or service provider loading facility.
{quote}
[JEP 162|http://openjdk.java.net/jeps/162] mentiones the usage of
{{java.util.ServiceLoader}} wherever possible.
I wasn't able to find *why* JAXP (JSR 206) was simply withdrawn after releasing
JAXP 1.6...
What is interesting however is that XML stuff is Java is still carefully
handled. In [JDK 11 API documentation for java.xml
module|https://docs.oracle.com/en/java/javase/11/docs/api/java.xml/module-summary.html]
we can see:
{noformat}
*Module java.xml*
Defines the Java API for XML Processing (JAXP), the Streaming API for XML
(StAX), the Simple API for XML (SAX), and the W3C Document Object Model (DOM)
API.
{noformat}
And the most interesting thing is that because JPMS modules now export real
_services_ we know exactly what should we handle in special way in _Karaf
specs_:
* DatatypeFactory - Factory that creates new javax.xml.datatype Objects that
map XML to/from Java Objects.
* DocumentBuilderFactory - Defines a factory API that enables applications to
obtain a parser that produces DOM object trees from XML documents.
* SAXParserFactory - Defines a factory API that enables applications to
configure and obtain a SAX based parser to parse XML documents.
* SchemaFactory - Factory that creates Schema objects.
* TransformerFactory - A TransformerFactory instance can be used to create
Transformer and Templates objects.
* XMLEventFactory - This interface defines a utility class for creating
instances of XMLEvents
* XMLInputFactory - Defines an abstract implementation of a factory for getting
streams.
* XMLOutputFactory - Defines an abstract implementation of a factory for
getting XMLEventWriters and XMLStreamWriters.
* XMLReader - Interface for reading an XML document using callbacks. -
deprecated in favor of SAXParserFactory
* XPathFactory - An XPathFactory instance can be used to create XPath objects.
There are *two* new packages in {{java.xml}} module of JDK9+ comparing to JAXP
1.6 implemented in JDK8:
* javax.xml.catalog
* org.w3c.dom.views - this package is also available in JDK8, not mentioned in
[JAXP 1.6 page of JDK 8
guide|https://docs.oracle.com/javase/8/docs/technotes/guides/xml/jaxp/index.html]
but it is mentioned in JAXP 1.6 (JSR 206)
[jira] [Commented] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309280#comment-17309280
]
Grzegorz Grzybek commented on KARAF-7084:
-
Here are some interesting (archaeology) findings about "Java + XML"...
As mentioned in [JSR 5 - JAXP 1.0|https://jcp.org/en/jsr/detail?id=5]:
bq. In many ways, XML and the Java Platform are a partnership made in heaven.
There were handy overview pages like:
* https://docs.oracle.com/javase/6/docs/index.html
* https://docs.oracle.com/javase/7/docs/index.html
* https://docs.oracle.com/javase/8/docs/index.html
But the pages changed after JDK8.
There were also pages explicitly for JAXP:
* https://docs.oracle.com/javase/6/docs/technotes/guides/xml/jaxp/index.html
* https://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/index.html
* https://docs.oracle.com/javase/8/docs/technotes/guides/xml/jaxp/index.html
That mentioned these packages (for all the 3 JDKs: 6, 7 and 8):
* javax.xml.datatype
* javax.xml.namespace
* javax.xml.parsers
* javax.xml.stream
* javax.xml.stream.events
* javax.xml.stream.util
* javax.xml.transform
* javax.xml.transform.dom
* javax.xml.transform.sax
* javax.xml.transform.stax
* javax.xml.transform.stream
* javax.xml.validation
* javax.xml.xpath
* org.w3c.dom
* org.w3c.dom.ranges
* org.w3c.dom.traversal
* org.w3c.dom.bootstrap
* org.w3c.dom.events
* org.w3c.dom.ls
* org.xml.sax
* org.xml.sax.ext
* org.xml.sax.helpers
The differences are explicitly highlighted:
*JDK 6*:
bq. The Java Platform, Standard Edition version 6.0 includes JAXP 1.4. JAXP 1.4
is a maintenance release of JAXP 1.3 with support for the Streaming API for XML
(StAX).
*JDK 7*:
bq. The Java Platform, Standard Edition version 7.0 includes JAXP 1.4. JAXP 1.4
is a maintenance release of JAXP 1.3 with support for the Streaming API for XML
(StAX).
*JDK 8*:
bq. The Java SE 7 Update 40 release includes JAXP 1.5.0. The Java SE 8 release
includes JAXP 1.6.
So actually JAXP 1.5 was introduced after JDK7u40.
What is most important in my opinion is this:
{quote}
The Java SE 8 release contains Java API for XML Processing (JAXP) 1.6, which
requires the use of the service provider loader facility defined by
java.util.ServiceLoader to load services from service configuration files. The
rationale for this is to allow for future modularization of the Java SE
platform where service providers may be deployed by means other than JAR files
and perhaps without the service configuration files. Note that the JAXP has
always specified the use of the 'Services API' without reference to a specific
API or service provider loading facility.
{quote}
[JEP 162|http://openjdk.java.net/jeps/162] mentiones the usage of
{{java.util.ServiceLoader}} wherever possible.
I wasn't able to find *why* JAXP (JSR 206) was simply withdrawn after releasing
JAXP 1.6...
What is interesting however is that XML stuff is Java is still carefully
handled. In [JDK 11 API documentation for java.xml
module|https://docs.oracle.com/en/java/javase/11/docs/api/java.xml/module-summary.html]
we can see:
{noformat}
*Module java.xml*
Defines the Java API for XML Processing (JAXP), the Streaming API for XML
(StAX), the Simple API for XML (SAX), and the W3C Document Object Model (DOM)
API.
{noformat}
And the most interesting thing is that because JPMS modules now export real
_services_ we know exactly what should we handle in special way in _Karaf
specs_:
* DatatypeFactory - Factory that creates new javax.xml.datatype Objects that
map XML to/from Java Objects.
* DocumentBuilderFactory - Defines a factory API that enables applications to
obtain a parser that produces DOM object trees from XML documents.
* SAXParserFactory - Defines a factory API that enables applications to
configure and obtain a SAX based parser to parse XML documents.
* SchemaFactory - Factory that creates Schema objects.
* TransformerFactory - A TransformerFactory instance can be used to create
Transformer and Templates objects.
* XMLEventFactory - This interface defines a utility class for creating
instances of XMLEvents
* XMLInputFactory - Defines an abstract implementation of a factory for getting
streams.
* XMLOutputFactory - Defines an abstract implementation of a factory for
getting XMLEventWriters and XMLStreamWriters.
* XMLReader - Interface for reading an XML document using callbacks. -
deprecated in favor of SAXParserFactory
* XPathFactory - An XPathFactory instance can be used to create XPath objects.
There are *two* new packages in {{java.xml}} module of JDK9+ comparing to JAXP
1.6 implemented in JDK8:
* javax.xml.catalog
* org.w3c.dom.views - this package is also available in JDK8, not mentioned in
[JAXP 1.6 page of JDK 8
guide|https://docs.oracle.com/javase/8/docs/technotes/guides/xml/jaxp/index.html]
but it is mentioned in JAXP 1.6 (JSR 206) itself.
Next comment will switch from JAXP/Specification research to
[jira] [Commented] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308710#comment-17308710
]
Grzegorz Grzybek commented on KARAF-7084:
-
I'm working on it.
> Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
>
>
> Key: KARAF-7084
> URL: https://issues.apache.org/jira/browse/KARAF-7084
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.2
>
>
> I was checking this code:
> {code:java}
> System.out.println("== JAXP");
> info(DatatypeFactory.class, DatatypeFactory.newInstance());
> info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
> info(SAXParserFactory.class, SAXParserFactory.newInstance());
> info(XMLEventFactory.class, XMLEventFactory.newInstance());
> info(XMLInputFactory.class, XMLInputFactory.newInstance());
> info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
> info(TransformerFactory.class, TransformerFactory.newInstance());
> info(SchemaFactory.class,
> SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
> info(XPathFactory.class, XPathFactory.newInstance());
> System.out.println("== SAAJ");
> try {
> info(MessageFactory.class, MessageFactory.newInstance());
> info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
> info(SOAPFactory.class, SOAPFactory.newInstance());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAX-WS");
> try {
> info(Provider.class, Provider.provider());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAXB");
> try {
> info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
> getClass().getClassLoader()));
> Class cfClass =
> FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
> System.out.println("ContextFactory class = " + cfClass);
> } catch (Throwable ignored) {
> }
> ...
> private void info(Class clazz, Object service) {
> System.out.printf(" - %s: %s%n", clazz, service.getClass().getName());
> System.out.printf(" - %s%n", FrameworkUtil.getBundle(service.getClass()));
> }
> {code}
> TO see if I really can get implementations of JAXP interfaces, if given
> interface is implemented in a bundle with proper
> {{/META-INF/services/}}. It works well with _some_ JAXP
> interfaces and with SAAJ. However it doesn't work with:
> * javax.xml.validation.SchemaFactory
> * javax.xml.xpath.XPathFactory
> * org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded
> factory in {{java.xml}} Karaf spec)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7084:
Description:
I was checking this code:
{code:java}
System.out.println("== JAXP");
info(DatatypeFactory.class, DatatypeFactory.newInstance());
info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
info(SAXParserFactory.class, SAXParserFactory.newInstance());
info(XMLEventFactory.class, XMLEventFactory.newInstance());
info(XMLInputFactory.class, XMLInputFactory.newInstance());
info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
info(TransformerFactory.class, TransformerFactory.newInstance());
info(SchemaFactory.class,
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
info(XPathFactory.class, XPathFactory.newInstance());
System.out.println("== SAAJ");
try {
info(MessageFactory.class, MessageFactory.newInstance());
info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
info(SOAPFactory.class, SOAPFactory.newInstance());
} catch (Throwable ignored) {
}
System.out.println("== JAX-WS");
try {
info(Provider.class, Provider.provider());
} catch (Throwable ignored) {
}
System.out.println("== JAXB");
try {
info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
getClass().getClassLoader()));
Class cfClass =
FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
System.out.println("ContextFactory class = " + cfClass);
} catch (Throwable ignored) {
}
...
private void info(Class clazz, Object service) {
System.out.printf(" - %s: %s%n", clazz, service.getClass().getName());
System.out.printf(" - %s%n", FrameworkUtil.getBundle(service.getClass()));
}
{code}
TO see if I really can get implementations of JAXP interfaces, if given
interface is implemented in a bundle with proper
{{/META-INF/services/}}. It works well with _some_ JAXP
interfaces and with SAAJ. However it doesn't work with:
* javax.xml.validation.SchemaFactory
* javax.xml.xpath.XPathFactory
* org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded factory
in {{java.xml}} Karaf spec)
was:
I was checking this code:
{code:java}
System.out.println("== JAXP");
info(DatatypeFactory.class, DatatypeFactory.newInstance());
info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
info(SAXParserFactory.class, SAXParserFactory.newInstance());
info(XMLEventFactory.class, XMLEventFactory.newInstance());
info(XMLInputFactory.class, XMLInputFactory.newInstance());
info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
info(TransformerFactory.class, TransformerFactory.newInstance());
info(SchemaFactory.class,
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
info(XPathFactory.class, XPathFactory.newInstance());
System.out.println("== SAAJ");
try {
info(MessageFactory.class, MessageFactory.newInstance());
info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
info(SOAPFactory.class, SOAPFactory.newInstance());
System.out.printf("%s - %s%n", SAAJMetaFactory.class,
SAAJMetaFactory.getInstance());
} catch (Throwable ignored) {
}
System.out.println("== JAX-WS");
try {
info(Provider.class, Provider.provider());
} catch (Throwable ignored) {
}
System.out.println("== JAXB");
try {
info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
getClass().getClassLoader()));
Class cfClass =
FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
System.out.println("ContextFactory class = " + cfClass);
} catch (Throwable ignored) {
}
{code}
TO see if I really can get implementations of JAXP interfaces, if given
interface is implemented in a bundle with proper
{{/META-INF/services/}}. It works well with _some_ JAXP
interfaces and with SAAJ. However it doesn't work with:
* javax.xml.validation.SchemaFactory
* javax.xml.xpath.XPathFactory
* org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded factory
in {{java.xml}} Karaf spec)
> Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
>
>
> Key: KARAF-7084
> URL: https://issues.apache.org/jira/browse/KARAF-7084
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.2
>
>
> I was checking this code:
> {code:java}
> System.out.println("== JAXP");
> info(DatatypeFactory.class, DatatypeFactory.newInstance());
> info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
> info(SAXParserFactory.class, SAXParserFactory.newInstance());
>
[jira] [Updated] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
[
https://issues.apache.org/jira/browse/KARAF-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated KARAF-7084:
Description:
I was checking this code:
{code:java}
System.out.println("== JAXP");
info(DatatypeFactory.class, DatatypeFactory.newInstance());
info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
info(SAXParserFactory.class, SAXParserFactory.newInstance());
info(XMLEventFactory.class, XMLEventFactory.newInstance());
info(XMLInputFactory.class, XMLInputFactory.newInstance());
info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
info(TransformerFactory.class, TransformerFactory.newInstance());
info(SchemaFactory.class,
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
info(XPathFactory.class, XPathFactory.newInstance());
System.out.println("== SAAJ");
try {
info(MessageFactory.class, MessageFactory.newInstance());
info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
info(SOAPFactory.class, SOAPFactory.newInstance());
System.out.printf("%s - %s%n", SAAJMetaFactory.class,
SAAJMetaFactory.getInstance());
} catch (Throwable ignored) {
}
System.out.println("== JAX-WS");
try {
info(Provider.class, Provider.provider());
} catch (Throwable ignored) {
}
System.out.println("== JAXB");
try {
info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
getClass().getClassLoader()));
Class cfClass =
FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
System.out.println("ContextFactory class = " + cfClass);
} catch (Throwable ignored) {
}
{code}
TO see if I really can get implementations of JAXP interfaces, if given
interface is implemented in a bundle with proper
{{/META-INF/services/}}. It works well with _some_ JAXP
interfaces and with SAAJ. However it doesn't work with:
* javax.xml.validation.SchemaFactory
* javax.xml.xpath.XPathFactory
* org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded factory
in {{java.xml}} Karaf spec)
> Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
>
>
> Key: KARAF-7084
> URL: https://issues.apache.org/jira/browse/KARAF-7084
> Project: Karaf
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.3.2
>
>
> I was checking this code:
> {code:java}
> System.out.println("== JAXP");
> info(DatatypeFactory.class, DatatypeFactory.newInstance());
> info(DocumentBuilderFactory.class, DocumentBuilderFactory.newInstance());
> info(SAXParserFactory.class, SAXParserFactory.newInstance());
> info(XMLEventFactory.class, XMLEventFactory.newInstance());
> info(XMLInputFactory.class, XMLInputFactory.newInstance());
> info(XMLOutputFactory.class, XMLOutputFactory.newInstance());
> info(TransformerFactory.class, TransformerFactory.newInstance());
> info(SchemaFactory.class,
> SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI));
> info(XPathFactory.class, XPathFactory.newInstance());
> System.out.println("== SAAJ");
> try {
> info(MessageFactory.class, MessageFactory.newInstance());
> info(SOAPConnectionFactory.class, SOAPConnectionFactory.newInstance());
> info(SOAPFactory.class, SOAPFactory.newInstance());
> System.out.printf("%s - %s%n", SAAJMetaFactory.class,
> SAAJMetaFactory.getInstance());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAX-WS");
> try {
> info(Provider.class, Provider.provider());
> } catch (Throwable ignored) {
> }
> System.out.println("== JAXB");
> try {
> info(JAXBContext.class, JAXBContext.newInstance("grgr.test.jaxb.model",
> getClass().getClassLoader()));
> Class cfClass =
> FrameworkUtil.getBundle(this.getClass()).adapt(BundleWiring.class).getClassLoader().loadClass("com.sun.xml.bind.v2.ContextFactory");
> System.out.println("ContextFactory class = " + cfClass);
> } catch (Throwable ignored) {
> }
> {code}
> TO see if I really can get implementations of JAXP interfaces, if given
> interface is implemented in a bundle with proper
> {{/META-INF/services/}}. It works well with _some_ JAXP
> interfaces and with SAAJ. However it doesn't work with:
> * javax.xml.validation.SchemaFactory
> * javax.xml.xpath.XPathFactory
> * org.xml.sax.helpers.XMLReaderFactory (here there's not even a shaded
> factory in {{java.xml}} Karaf spec)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KARAF-7084) Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator
Grzegorz Grzybek created KARAF-7084: --- Summary: Not every factory access from JAXP (specs/java.xml) goes through OsgiLocator Key: KARAF-7084 URL: https://issues.apache.org/jira/browse/KARAF-7084 Project: Karaf Issue Type: Bug Reporter: Grzegorz Grzybek Assignee: Grzegorz Grzybek Fix For: 4.3.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KARAF-6703) Spec features and cleanup
[ https://issues.apache.org/jira/browse/KARAF-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307789#comment-17307789 ] Grzegorz Grzybek commented on KARAF-6703: - Just a note - CXF's approach to handle missing/removed APIs in JDK9+ is ... [simply to add them back|https://github.com/apache/cxf/blob/cxf-3.4.3/parent/pom.xml#L2274-L2356]. > Spec features and cleanup > - > > Key: KARAF-6703 > URL: https://issues.apache.org/jira/browse/KARAF-6703 > Project: Karaf > Issue Type: Task > Components: karaf >Reporter: Francois Papon >Assignee: Jean-Baptiste Onofré >Priority: Major > > As already discussed, we should remove the lib/jdk9plus folder and all spec > packages from etc/jre.properties to use spec features instead. > That will give us more control in the specs version and support of JDK. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (KARAF-6703) Spec features and cleanup
[
https://issues.apache.org/jira/browse/KARAF-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307053#comment-17307053
]
Grzegorz Grzybek edited comment on KARAF-6703 at 3/23/21, 1:27 PM:
---
A little investigation about Activation API:
I had problem with CXF ("fixed" with CXF-8380) and attachments:
{noformat}
Caused by: java.lang.NullPointerException: mimeType
at java.awt.datatransfer.DataFlavor.(DataFlavor.java:430)
at
javax.activation.ActivationDataFlavor.(ActivationDataFlavor.java:113)
at javax.activation.DataHandler.(DataHandler.java:41)
at
org.apache.cxf.jaxrs.provider.MultipartProvider$MessageBodyWriterDataHandler.(MultipartProvider.java:448)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.getHandlerForObject(MultipartProvider.java:401)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.getHandlerForObject(MultipartProvider.java:409)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.createDataHandler(MultipartProvider.java:353)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.createDataHandler(MultipartProvider.java:327)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.getAttachments(MultipartProvider.java:311)
...
{noformat}
{{javax.activation.DataHandler}} constructor is fascinating.
In what I think that should be canonical (at least for JDK8):
*
[hg.openjdk.java.net/jdk8u/jdk8u/jaxws|http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/file/2534e08d1f08/src/share/jaf_classes/javax/activation/DataHandler.java]
* [github.com/javaee/activation, 1.2.0
tag|https://github.com/javaee/activation/blob/JAF-1_2_0/activation/src/main/java/javax/activation/DataHandler.java]
* [github.com/eclipse-ee4j/jaf, 1.2.2
tag|https://github.com/eclipse-ee4j/jaf/blob/1.2.2/activation/src/main/java/javax/activation/DataHandler.java]
we have:
{code:java}
public DataHandler(DataSource ds) {
// save a reference to the incoming DS
dataSource = ds;
oldFactory = factory; // keep track of the factory
}
{code}
SMX version of
org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.2.1/1.2.1_3
but also
org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/2.9.0
{code:java}
public DataHandler(DataSource ds) {
this.ds = ds;
this.flavor = new ActivationDataFlavor(ds.getContentType(), null);
}
{code}
where {{javax.activation.ActivationDataFlavor}} extends
{{java.awt.datatransfer.DataFlavor}} and AWT's DataFlavor has:
{code:java}
public DataFlavor(String mimeType, String humanPresentableName) {
super();
if (mimeType == null) {
throw new NullPointerException("mimeType");
}
{code}
But even:
* [javax/activation/DataHandler.java in JDK
6|http://hg.openjdk.java.net/jdk6/jdk6/jaxws/file/4b3bab9533cd/drop_included/jaf_src/src/javax/activation/DataHandler.java]
* [javax/activation/DataHandler.java in JDK
7|http://hg.openjdk.java.net/jdk7u/jdk7u/jaxws/file/4a302acff4de/src/share/jaf_classes/javax/activation/DataHandler.java]
have:
{code:java}
public DataHandler(DataSource ds) {
// save a reference to the incoming DS
dataSource = ds;
oldFactory = factory; // keep track of the factory
}
{code}
The SMX version of activation API comes from
org.apache.geronimo.specs/geronimo-activation_1.1_spec and was added with
DataHandler(DataSource ds) constructor that uses ActivationDataFlavor in
https://issues.apache.org/jira/browse/GERONIMO-2466 [back in
2006|https://github.com/apache/geronimo-specs/commit/70028d2cce20067e79d8a15f4bea4998f3f1f918].
DataHandler.java from activation API 1.1 is a copy of DataHandler.java from
activation API 1.0.2 in Geronimo specs repository and ActivationDataFlavor
usage dates [back to
2004|https://github.com/apache/geronimo-specs/commit/af8f64656e3386f7c26f2b61b403a98a8be19d93]
where the track is lost - I don't have any reference to Jira/BZ number in this
commit...
Long story short: SMX version of Activation API is wrong.
was (Author: gzres):
A little investigation about Activation API:
I had problem with CXF and attachments:
{noformat}
Caused by: java.lang.NullPointerException: mimeType
at java.awt.datatransfer.DataFlavor.(DataFlavor.java:430)
at
javax.activation.ActivationDataFlavor.(ActivationDataFlavor.java:113)
at javax.activation.DataHandler.(DataHandler.java:41)
at
org.apache.cxf.jaxrs.provider.MultipartProvider$MessageBodyWriterDataHandler.(MultipartProvider.java:448)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.getHandlerForObject(MultipartProvider.java:401)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.getHandlerForObject(MultipartProvider.java:409)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.createDataHandler(MultipartProvider.java:353)
at
