[jira] [Resolved] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved KARAF-4523.
-
Resolution: Fixed
Fix Version/s: 4.0.6
4.1.0
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
> Fix For: 4.1.0, 4.0.6
>
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277709#comment-15277709
]
ASF subversion and git services commented on KARAF-4523:
Commit 0e8cfd9a97a54f26d7fea4f409768a538f36db1e in karaf's branch
refs/heads/karaf-4.0.x from [~tadayosi]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=0e8cfd9 ]
[KARAF-4523] JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery
contains duplicate operations
This fix is based on the original patch by Grzegorz Grzybek
(cherry picked from commit 1fff0131967ac11b0a481f503fbc952f777fc30d)
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277703#comment-15277703
]
ASF GitHub Bot commented on KARAF-4523:
---
Github user asfgit closed the pull request at:
https://github.com/apache/karaf/pull/182
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277702#comment-15277702
]
ASF subversion and git services commented on KARAF-4523:
Commit 1fff0131967ac11b0a481f503fbc952f777fc30d in karaf's branch
refs/heads/master from [~tadayosi]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=1fff013 ]
[KARAF-4523] JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery
contains duplicate operations
This fix is based on the original patch by Grzegorz Grzybek
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KARAF-4523 started by Freeman Fang.
---
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned KARAF-4523:
---
Assignee: Freeman Fang
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
[
https://issues.apache.org/jira/browse/KARAF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277506#comment-15277506
]
ASF GitHub Bot commented on KARAF-4523:
---
GitHub user tadayosi opened a pull request:
https://github.com/apache/karaf/pull/182
[KARAF-4523] JMXSecurityMBean bulk canInvoke should be robust even if
bulkQuery contains duplicate operations
https://issues.apache.org/jira/browse/KARAF-4523
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tadayosi/karaf KARAF-4523
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/karaf/pull/182.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #182
commit 1fff0131967ac11b0a481f503fbc952f777fc30d
Author: Tadayoshi Sato
Date: 2016-05-10T02:32:34Z
[KARAF-4523] JMXSecurityMBean bulk canInvoke should be robust even if
bulkQuery contains duplicate operations
This fix is based on the original patch by Grzegorz Grzybek
> JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains
> duplicate operations
>
>
> Key: KARAF-4523
> URL: https://issues.apache.org/jira/browse/KARAF-4523
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-management
>Affects Versions: 4.0.5
>Reporter: Tadayoshi Sato
>
> {{JMXSecurityMBean#canInvoke(Map>)}} method throws the
> following exception in the presence of duplicate operations in the
> {{bulkQuery}} parameter:
> {code}
> javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
> calculated according to this TabularData instance's tabularType, already
> refers to a value in this table.
> at
> javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
> at
> javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
> at
> javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
> at
> org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
> ...
> {code}
> There is an improvement (KARAF-1300) that addressed a similar situlation in a
> different component, so why not make {{JMXSecurityMBean}} robust as well?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-4523) JMXSecurityMBean bulk canInvoke should be robust even if bulkQuery contains duplicate operations
Tadayoshi Sato created KARAF-4523:
-
Summary: JMXSecurityMBean bulk canInvoke should be robust even if
bulkQuery contains duplicate operations
Key: KARAF-4523
URL: https://issues.apache.org/jira/browse/KARAF-4523
Project: Karaf
Issue Type: Improvement
Components: karaf-management
Affects Versions: 4.0.5
Reporter: Tadayoshi Sato
{{JMXSecurityMBean#canInvoke(Map>)}} method throws the
following exception in the presence of duplicate operations in the
{{bulkQuery}} parameter:
{code}
javax.management.openmbean.KeyAlreadyExistsException: Argument value's index,
calculated according to this TabularData instance's tabularType, already refers
to a value in this table.
at
javax.management.openmbean.TabularDataSupport.checkValueAndIndex(TabularDataSupport.java:898)
at
javax.management.openmbean.TabularDataSupport.internalPut(TabularDataSupport.java:358)
at
javax.management.openmbean.TabularDataSupport.put(TabularDataSupport.java:350)
at
org.apache.karaf.management.internal.JMXSecurityMBeanImpl.canInvoke(JMXSecurityMBeanImpl.java:102)
...
{code}
There is an improvement (KARAF-1300) that addressed a similar situlation in a
different component, so why not make {{JMXSecurityMBean}} robust as well?
--
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 ce
[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)
