[jira] [Commented] (KARAF-4260) Setting karaf.clean.all = true breaks service wrapper service script
[
https://issues.apache.org/jira/browse/KARAF-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15434315#comment-15434315
]
Ralf Steppacher commented on KARAF-4260:
We put the PID file into {{KARAF_BASE}} and had no issues with that location.
> Setting karaf.clean.all = true breaks service wrapper service script
>
>
> Key: KARAF-4260
> URL: https://issues.apache.org/jira/browse/KARAF-4260
> Project: Karaf
> Issue Type: Bug
> Components: karaf-config
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 4.1.0, 4.0.7
>
>
> The Karaf service wrapper script is generated such that the PID file is
> created in {{$KARAF_HOME/data}}. When setting {{karaf.clean.all = true}} then
> the PID file created by the service script gets deleted together with the
> data directory. As a result of this the service script reports Karaf as not
> running and it is not possible to stop the process via the script.
> The PID file location probably should be outside the data directory by
> default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15405449#comment-15405449
]
Ralf Steppacher commented on KARAF-4261:
[~ch...@die-schneider.net], thanks for your comment and apologies for my long
response times.
Yes, as far as I can tell the problem occurs only when deploying a KAR file via
the {{deploy}} folder. Not being able to use a KAR with the deploy folder will
make the instructions for our operations team for deployment and upgrades that
much more elaborate and error prone. It would be really great of deploying and
undeploying a KAR via the deploy folder could be fixed.
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
> Fix For: 4.1.0, 4.0.6
>
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352446#comment-15352446
]
Ralf Steppacher edited comment on KARAF-4261 at 6/28/16 6:28 AM:
-
I am using Felix.
was (Author: ralfsteppacher):
I am using Felix.
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
> Fix For: 4.1.0, 4.0.6
>
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352446#comment-15352446
]
Ralf Steppacher commented on KARAF-4261:
I am using Felix.
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
> Fix For: 4.1.0, 4.0.6
>
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4522) Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
[
https://issues.apache.org/jira/browse/KARAF-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated KARAF-4522:
---
Description:
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component to subscribe to
LDAP updates, which again depends on the UnboundID SDK.
{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
{noformat}
The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
implement in the custom camel component. In the call-back implementation I
spawn a new thread that attempts to re-establish the connection at a certain
interval. Instantiating this thread fails consistently on the first attempt,
but always succeeds on the second.
If I wrap the call to {{new ReconnectionThread}} in a loop like so:
{code:java}
success = false;
while(!success) {
try {
ReconnectThread rt = new ReconnectThread(...);
success = true;
} catch (Exception e) {
LOG.warn("Failed to spawn LDAP re-connection thread.", e);
}
}
{code}
Then the first attempt fails consistently while the second time around it
consistently succeeds.
The exception I receive is the following:
{noformat}
2016-05-09 08:37:24,492 | WARN | dap:389 (closed) |
ReconnectingDisconnectHandler| 53 - ch.vivates.ams.camel-uldap -
4.0.9.SNAPSHOT | | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
at java.net.URL.toString(URL.java:915)[:1.8.0_77]
at
java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
at
ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
at
com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}
It appears the problem is limited to bundle deployment time. If the LDAP server
is available while the bundle gets deployed and only fails later, then the
reconnection thread is spawned on the first attempt.
Another thing I have noticed: The creation of the reconnection thread only
fails when I attempt to spawn it from the disconnect handler, which is driven
by a thread associated to the LDAP connection ({{LDAPConnectionReader}}). If I
try to spawn my reconnect-thread from the thread that starts the camel
component, then this works on the first attempt as well.
The feature file I am using to deploy the bundles is simple:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="Features">
Camel endpoint to subscribe with an OpenLDAP server and
convert updates to the LDAP into Camel exchanges.
camel-core
mvn:ch.vivates.ams/camel-uldap/4.0.9-SNAPSHOT
mvn:com.unboundid/unboundid-ldapsdk/3.1.1
Replicates the HPD LDAP into the graph DB
transaction
camel-core
camel-blueprint
base
titan-client
[jira] [Updated] (KARAF-4522) Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
[
https://issues.apache.org/jira/browse/KARAF-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated KARAF-4522:
---
Description:
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component to subscribe to
LDAP updates, which again depends on the UnboundID SDK.
{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
{noformat}
The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
implement in the custom camel component. In the call-back implementation I
spawn a new thread that attempts to re-establish the connection at a certain
interval. Instantiating this thread fails consistently on the first attempt,
but always succeeds on the second.
If I wrap the call to {{new ReconnectionThread}} in a loop like so:
{code:java}
success = false;
while(!success) {
try {
ReconnectThread rt = new ReconnectThread(...);
success = true;
} catch (Exception e) {
LOG.warn("Failed to spawn LDAP re-connection thread.", e);
}
}
{code}
Then the first attempt fails consistently while the second time around it
consistently succeeds.
The exception I receive is the following:
{noformat}
2016-05-09 08:37:24,492 | WARN | dap:389 (closed) |
ReconnectingDisconnectHandler| 53 - ch.vivates.ams.camel-uldap -
4.0.9.SNAPSHOT | | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
at java.net.URL.toString(URL.java:915)[:1.8.0_77]
at
java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
at
ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
at
com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}
It appears the problem is limited to bundle deployment time. If the LDAP server
is available while the bundle gets deployed and only fails later, then the
reconnection thread is spawned on the first attempt.
Another thing I have noticed: The creation of the reconnection thread only
fails when I attempt to spawn it from the disconnect handler, which is driven
by a thread associated to the LDAP connection ({{LDAPConnectionReader}}). If I
try to spawn my reconnect-thread from the thread that starts the camel
component, then this works on the first attempt as well.
The feature file I am using to deploy the bundles is simple:
{code:xml}
http://karaf.apache.org/xmlns/features/v1.3.0; name="Features">
Camel endpoint to subscribe with an OpenLDAP server and
convert updates to the LDAP into Camel exchanges.
camel-core
mvn:ch.vivates.ams/camel-uldap/4.0.9-SNAPSHOT
mvn:com.unboundid/unboundid-ldapsdk/3.1.1
{code}
was:
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component
[jira] [Updated] (KARAF-4522) Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
[
https://issues.apache.org/jira/browse/KARAF-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated KARAF-4522:
---
Description:
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component to subscribe to
LDAP updates, which again depends on the UnboundID SDK.
{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
{noformat}
The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
implement in the custom camel component. In the call-back implementation I
spawn a new thread that attempts to re-establish the connection at a certain
interval. Instantiating this thread fails consistently on the first attempt,
but always succeeds on the second.
If I wrap the call to {{new ReconnectionThread}} in a loop like so:
{code:java}
success = false;
while(!success) {
try {
ReconnectThread rt = new ReconnectThread(...);
success = true;
} catch (Exception e) {
LOG.warn("Failed to spawn LDAP re-connection thread.", e);
}
}
{code}
Then the first attempt fails consistently while the second time around it
consistently succeeds.
The exception I receive is the following:
{noformat}
2016-05-09 08:37:24,492 | WARN | dap:389 (closed) |
ReconnectingDisconnectHandler| 53 - ch.vivates.ams.camel-uldap -
4.0.9.SNAPSHOT | | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
at java.net.URL.toString(URL.java:915)[:1.8.0_77]
at
java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
at
ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
at
com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}
It appears the problem is limited to bundle deployment time. If the LDAP server
is available while the bundle gets deployed and only fails later, then the
reconnection thread is spawned on the first attempt.
Another thing I have noticed: The creation of the reconnection thread only
fails when I attempt to spawn it from the disconnect handler, which is driven
by a thread associated to the LDAP connection ({{LDAPConnectionReader}}). If I
try to spawn my reconnect-thread from the thread that starts the camel
component, then this works on the first attempt as well.
was:
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component to subscribe to
LDAP updates, which again depends on the UnboundID SDK.
{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
{noformat}
The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
implement in the custom camel component. In the call-back implementation I
spawn a new thread that attempts to re-establish the connection at a
[jira] [Updated] (KARAF-4522) Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
[
https://issues.apache.org/jira/browse/KARAF-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated KARAF-4522:
---
Summary: Instantiating class fails on first try but succeeds on second
attempt: java.lang.IllegalStateException: Unknown protocol: mvn (was:
Instanciating class fails on first try but succeeds on second attempt:
java.lang.IllegalStateException: Unknown protocol: mvn)
> Instantiating class fails on first try but succeeds on second attempt:
> java.lang.IllegalStateException: Unknown protocol: mvn
> -
>
> Key: KARAF-4522
> URL: https://issues.apache.org/jira/browse/KARAF-4522
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.5
> Environment: OSX El Capitan, IBM JDK 8, Camel 2.16.3, Blueprint
>Reporter: Ralf Steppacher
>
> I am trying to deploy a bundle that starts a Camel context via a Blueprint
> context file. The bundle depends on a custom Camel component to subscribe to
> LDAP updates, which again depends on the UnboundID SDK.
> {noformat}
> bundle: camel context --> bundle: custom camel component --> bundle:
> UnboundID SDK
> {noformat}
> The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
> implement in the custom camel component. In the call-back implementation I
> spawn a new thread that attempts to re-establish the connection at a certain
> interval. Instantiating this thread fails consistently on the first attempt,
> but always succeeds on the second.
> If I wrap the call to {{new ReconnectionThread}} in a loop like so:
> {code:java}
> success = false;
> while(!success) {
> try {
> ReconnectThread rt = new ReconnectThread(...);
> success = true;
> } catch (Exception e) {
> LOG.warn("Failed to spawn LDAP re-connection thread.", e);
> }
> }
> {code}
> Then the first attempt fails consistently while the second time around it
> consistently succeeds.
> The exception I receive is the following:
> {noformat}
> 2016-05-09 08:37:24,492 | WARN | dap:389 (closed) |
> ReconnectingDisconnectHandler| 53 - ch.vivates.ams.camel-uldap -
> 4.0.9.SNAPSHOT | | Failed to spawn LDAP re-connection thread.
> java.lang.IllegalStateException: Unknown protocol: mvn
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
> at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
> at java.net.URL.toString(URL.java:915)[:1.8.0_77]
> at
> java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
> at
> ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
> at
> com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
> at
> com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
> at
> com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
> at
> com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
> at
> com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-4522) Instanciating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
Ralf Steppacher created KARAF-4522:
--
Summary: Instanciating class fails on first try but succeeds on
second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
Key: KARAF-4522
URL: https://issues.apache.org/jira/browse/KARAF-4522
Project: Karaf
Issue Type: Bug
Components: karaf-core
Affects Versions: 4.0.5
Environment: OSX El Capitan, IBM JDK 8, Camel 2.16.3, Blueprint
Reporter: Ralf Steppacher
I am trying to deploy a bundle that starts a Camel context via a Blueprint
context file. The bundle depends on a custom Camel component to subscribe to
LDAP updates, which again depends on the UnboundID SDK.
{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
{noformat}
The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I
implement in the custom camel component. In the call-back implementation I
spawn a new thread that attempts to re-establish the connection at a certain
interval. Instantiating this thread fails consistently on the first attempt,
but always succeeds on the second.
If I wrap the call to {{new ReconnectionThread}} in a loop like so:
{code:java}
success = false;
while(!success) {
try {
ReconnectThread rt = new ReconnectThread(...);
success = true;
} catch (Exception e) {
LOG.warn("Failed to spawn LDAP re-connection thread.", e);
}
}
{code}
Then the first attempt fails consistently while the second time around it
consistently succeeds.
The exception I receive is the following:
{noformat}
2016-05-09 08:37:24,492 | WARN | dap:389 (closed) |
ReconnectingDisconnectHandler| 53 - ch.vivates.ams.camel-uldap -
4.0.9.SNAPSHOT | | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
at java.net.URL.toString(URL.java:915)[:1.8.0_77]
at
java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
at
ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
at
com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
at
com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15093550#comment-15093550
]
Ralf Steppacher commented on KARAF-4261:
I tried on a second machine (3 start/stop cycles). It appears that the
start/stop order is the same per Karaf instance, if that is at all possible
with {{karaf.clean.all = true}}. On the second machine the data access bundle
is consistently started last (3 of 3 times) but is shut as the second bundle
after the _PEP_ bundle (3 of 3 times).
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15093503#comment-15093503
]
Ralf Steppacher commented on KARAF-4261:
It looks like the bundle start-level is also not fully honored during the
initial KAR deployment either. Or my understanding of the start-level is wrong.
I have changed the order in which my bundles should be started such that my
data access bundle starts before the webservices start and shuts down after the
webservices have shut down. However, the change is not reflected in the
start/stop order of the bundles. The data access bundle (_Graph Manager_, id
206) is still consistently started last and shut down first. Though looking at
the start-levels it should be the other way round:
{noformat}
karaf@root()> bundle:list | grep 4.0.3.SNAP
52 | Active | 88 | 4.0.3.SNAPSHOT | Base
60 | Active | 89 | 4.0.3.SNAPSHOT | Patient webservice implementation
63 | Active | 89 | 4.0.3.SNAPSHOT | Camel UnboundIDLDAP Component
65 | Active | 91 | 4.0.3.SNAPSHOT | Webservice Health Professionals
152 | Active | 91 | 4.0.3.SNAPSHOT | REST API
167 | Active | 91 | 4.0.3.SNAPSHOT | Webservice Patients
168 | Active | 91 | 4.0.3.SNAPSHOT | Webservice Patient Registration
177 | Active | 91 | 4.0.3.SNAPSHOT | PEP
206 | Active | 90 | 4.0.3.SNAPSHOT | Graph Manager
karaf@root()>
{noformat}
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
Ralf Steppacher created KARAF-4261:
--
Summary: Bundle start-level seems to be ignored at Karaf restart
Key: KARAF-4261
URL: https://issues.apache.org/jira/browse/KARAF-4261
Project: Karaf
Issue Type: Bug
Components: karaf-core
Affects Versions: 4.0.3
Reporter: Ralf Steppacher
AS a workaround for CAMEL-9483 I have set a start-level for my bundles deployed
as part of my features. This works as expected during initial deployment (order
of deployment is according to the start levels I set), but not during
sub-sequent starts of Karaf. It appears the start-level of the bundles is
ignored, meaning the order of deployment of my bundles is more or less random
and I observe the issues described in CAMEL-9483 again.
{{bundle:list}} shows my bundles with the start-levels they have been
originally deployed with, though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-4260) Setting karaf.clean.all = true breaks service wrapper service script
Ralf Steppacher created KARAF-4260:
--
Summary: Setting karaf.clean.all = true breaks service wrapper
service script
Key: KARAF-4260
URL: https://issues.apache.org/jira/browse/KARAF-4260
Project: Karaf
Issue Type: Bug
Components: karaf-config
Affects Versions: 4.0.3
Reporter: Ralf Steppacher
Priority: Minor
The Karaf service wrapper script is generated such that the PID file is created
in {{$KARAF_HOME/data}}. When setting {{karaf.clean.all = true}} then the PID
file created by the service script gets deleted together with the data
directory. As a result of this the service script reports Karaf as not running
and it is not possible to stop the process via the script.
The PID file location probably should be outside the data directory by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated KARAF-4261:
---
Description:
AS a workaround for CAMEL-9483 I have set a start-level for my bundles deployed
as part of my features. This works as expected during initial deployment (order
of deployment is according to the start levels I set), but not during
sub-sequent starts of Karaf. It appears the start-level of the bundles is
ignored, meaning the order of deployment of my bundles is more or less random
and I observe the issues described in CAMEL-9483 again.
{{bundle:list}} shows my bundles with the start-levels they have been
originally deployed with, though.
As a workaround I set {{karaf.clean.all = true}} in system.properties.
was:
AS a workaround for CAMEL-9483 I have set a start-level for my bundles deployed
as part of my features. This works as expected during initial deployment (order
of deployment is according to the start levels I set), but not during
sub-sequent starts of Karaf. It appears the start-level of the bundles is
ignored, meaning the order of deployment of my bundles is more or less random
and I observe the issues described in CAMEL-9483 again.
{{bundle:list}} shows my bundles with the start-levels they have been
originally deployed with, though.
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-3286) karaf-maven-plugin does not merge bundle entry with URL parameters
[
https://issues.apache.org/jira/browse/KARAF-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173988#comment-14173988
]
Ralf Steppacher commented on KARAF-3286:
I have the syntax from the Karaf [deployer
documention|http://karaf.apache.org/manual/latest/users-guide/deployers.html]
(bottom of the page). And it works if I use it like that in the feature.xml. I
will try your suggested syntax and report back.
karaf-maven-plugin does not merge bundle entry with URL parameters
--
Key: KARAF-3286
URL: https://issues.apache.org/jira/browse/KARAF-3286
Project: Karaf
Issue Type: Bug
Components: karaf-tooling
Affects Versions: 3.0.1
Reporter: Ralf Steppacher
If a template contains an entry with URL parameters, e.g.
{code:xml}bundlewrap:mvn:jboss/jbossall-client/4.2.3.GA/$Bundle-SymbolicName=jbossall-clientamp;Bundle-Version=4.2.3.GA/bundle{code}
then it is not merged with a maven compile dependency. Instead the resulting
feature.xml contains two entries for that bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-3286) karaf-maven-plugin does not merge bundle entry with URL parameters
[
https://issues.apache.org/jira/browse/KARAF-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172093#comment-14172093
]
Ralf Steppacher commented on KARAF-3286:
No, it does not work with 3.0.2 either. The exact line that fails merging looks
like this:
{code:xml}bundlemvn:${project.groupId}/base/${project.version}/$Export-Package=an.api.package/bundle{code}
The produced feature.xml contains the following two lines:
{code:xml}
bundlemvn:ch.vivates.ams/base/3.0.0-SNAPSHOT/$Export-Package=an.api.package/bundle
bundlemvn:ch.vivates.ams/base/3.0.0-SNAPSHOT/bundle
{code}
karaf-maven-plugin does not merge bundle entry with URL parameters
--
Key: KARAF-3286
URL: https://issues.apache.org/jira/browse/KARAF-3286
Project: Karaf
Issue Type: Bug
Components: karaf-tooling
Affects Versions: 3.0.1
Reporter: Ralf Steppacher
If a template contains an entry with URL parameters, e.g.
{code:xml}bundlewrap:mvn:jboss/jbossall-client/4.2.3.GA/$Bundle-SymbolicName=jbossall-clientamp;Bundle-Version=4.2.3.GA/bundle{code}
then it is not merged with a maven compile dependency. Instead the resulting
feature.xml contains two entries for that bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-3286) karaf-maven-plugin does not merge bundle entry with URL parameters
Ralf Steppacher created KARAF-3286:
--
Summary: karaf-maven-plugin does not merge bundle entry with URL
parameters
Key: KARAF-3286
URL: https://issues.apache.org/jira/browse/KARAF-3286
Project: Karaf
Issue Type: Bug
Components: karaf-tooling
Affects Versions: 3.0.1
Reporter: Ralf Steppacher
If a template contains an entry with URL parameters, e.g.
{code:xml}bundlewrap:mvn:jboss/jbossall-client/4.2.3.GA/$Bundle-SymbolicName=jbossall-clientamp;Bundle-Version=4.2.3.GA/bundle{code}
then it is not merged with a maven compile dependency. Instead the resulting
feature.xml contains two entries for that bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
