[jira] [Created] (KARAF-5767) missing OSGi service for @Reference in Action does not lead to failed diag but
Michael Vorburger created KARAF-5767:
Summary: missing OSGi service for @Reference in Action does not
lead to failed diag but
Key: KARAF-5767
URL: https://issues.apache.org/jira/browse/KARAF-5767
Project: Karaf
Issue Type: Bug
Components: karaf-shell
Affects Versions: 4.2.0
Reporter: Michael Vorburger
While [migrating a Karaf command from extending deprecated OsgiCommandSupport
to implementing the Action
interface|https://git.opendaylight.org/gerrit/#/c/72204], I've noticed that if
you have a {{@Reference}} to a type under which there is no OSGi Service
registered, then that command is simply ignored - without any error in the log.
While I understand perfectly well that this lazy initialiation is how
Declarative Services (DS) work, because the bundle that provides said service
could still be installed later, it still seems to me that {{diag}} (which is
based on {{org.apache.karaf.bundle.core.BundleService}} AFAIK) could and in an
ideal world should report such missing services.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-5376) Processor mechanism for feature definitions (a.k.a. "better overrides")
[
https://issues.apache.org/jira/browse/KARAF-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431886#comment-16431886
]
Michael Vorburger commented on KARAF-5376:
--
[~gzres] this could possibly be useful to use (ODL), but I'm not immediately
seeing how to apply this here... has the Karaf documentation been updated about
this, or can you e.g. point to an example commit anywhere illustrating how to
blacklist a transitively inherited feature?
> Processor mechanism for feature definitions (a.k.a. "better overrides")
> ---
>
> Key: KARAF-5376
> URL: https://issues.apache.org/jira/browse/KARAF-5376
> Project: Karaf
> Issue Type: Proposal
> Components: karaf-feature
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.0.M2
>
>
> It'd be good to have a mechanism that could transform/enhance/process feature
> definitions after reading them from original feature XML descriptors and
> before passing them to Karaf features deployer.
> Current overrides mechanism could be generalized beyond simple version change
> for {{/}} URIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KARAF-5570) Prompt branding no longer works
[
https://issues.apache.org/jira/browse/KARAF-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated KARAF-5570:
-
Description:
as found in https://jira.opendaylight.org/browse/ODLPARENT-137 by OpenDaylight:
That [prompt branding stuff|https://karaf.apache.org/manual/latest/#_branding]
which as still OK e.g. in 4.0.9 seems to have broken some time in 4.1.x ...
here's how to reproduce:
{noformat}$ nano etc/branding.properties
welcome=Duh
prompt=Dah{noformat}
In all of apache-karaf-4.2.0.M2, apache-karaf-4.1.4 and apache-karaf-4.1.3 this
leads to:
{noformat}Duh
karaf@root()>{noformat}
whereas in 4.0.9 it led to:
{noformat}Duh
Dah^C
Dah^DDah{noformat}
was:
as found in https://jira.opendaylight.org/browse/ODLPARENT-137 by OpenDaylight:
That [prompt branding stuff|https://karaf.apache.org/manual/latest/#_branding]
which as still OK e.g. in 4.0.9 seems to have broken some time in 4.1.x ...
here's how to reproduce:
{noformat}$ nano etc/branding.properties
welcome=Duh
prompt=Dah\{noformat}
In all of apache-karaf-4.2.0.M2, apache-karaf-4.1.4 and apache-karaf-4.1.3 this
leads to:
{noformat}Duh
karaf@root()>\{noformat}
whereas in 4.0.9 it led to:
{noformat}Duh
Dah^C
Dah^DDah\{noformat}
> Prompt branding no longer works
> ---
>
> Key: KARAF-5570
> URL: https://issues.apache.org/jira/browse/KARAF-5570
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.3, 4.1.4, 4.2.0.M2
>Reporter: Michael Vorburger
>Priority: Major
>
> as found in https://jira.opendaylight.org/browse/ODLPARENT-137 by
> OpenDaylight:
> That [prompt branding
> stuff|https://karaf.apache.org/manual/latest/#_branding] which as still OK
> e.g. in 4.0.9 seems to have broken some time in 4.1.x ... here's how to
> reproduce:
> {noformat}$ nano etc/branding.properties
> welcome=Duh
> prompt=Dah{noformat}
> In all of apache-karaf-4.2.0.M2, apache-karaf-4.1.4 and apache-karaf-4.1.3
> this leads to:
> {noformat}Duh
> karaf@root()>{noformat}
> whereas in 4.0.9 it led to:
> {noformat}Duh
> Dah^C
> Dah^DDah{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KARAF-5570) Prompt branding no longer works
Michael Vorburger created KARAF-5570:
Summary: Prompt branding no longer works
Key: KARAF-5570
URL: https://issues.apache.org/jira/browse/KARAF-5570
Project: Karaf
Issue Type: Bug
Affects Versions: 4.2.0.M2, 4.1.4, 4.1.3
Reporter: Michael Vorburger
as found in https://jira.opendaylight.org/browse/ODLPARENT-137 by OpenDaylight:
That [prompt branding stuff|https://karaf.apache.org/manual/latest/#_branding]
which as still OK e.g. in 4.0.9 seems to have broken some time in 4.1.x ...
here's how to reproduce:
{noformat}$ nano etc/branding.properties
welcome=Duh
prompt=Dah\{noformat}
In all of apache-karaf-4.2.0.M2, apache-karaf-4.1.4 and apache-karaf-4.1.3 this
leads to:
{noformat}Duh
karaf@root()>\{noformat}
whereas in 4.0.9 it led to:
{noformat}Duh
Dah^C
Dah^DDah\{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (KARAF-5275) Add systemd journal logging support
[ https://issues.apache.org/jira/browse/KARAF-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103530#comment-16103530 ] Michael Vorburger edited comment on KARAF-5275 at 7/27/17 5:22 PM: --- Started looking at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... was (Author: vorburger): Started looked at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... > Add systemd journal logging support > --- > > Key: KARAF-5275 > URL: https://issues.apache.org/jira/browse/KARAF-5275 > Project: Karaf > Issue Type: New Feature > Components: karaf-os-integration >Affects Versions: 4.0.9 >Reporter: Michael Vorburger > > KARAF-3858 introduced systemd support in the wrapper. > But (unless I'm missing something), Karaf cannot yet log to the systemd > journal, out of the box? > https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project > which seems to make this easy. Would a contribution to Karaf to include this > external library in the distribution and have an example configuration in > etc/org.ops4j.pax.logging.cfg be welcome? > Or am I getting this all wrong, and this needs to go into OPS4j's PAX > Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5275) Add systemd journal logging support
[ https://issues.apache.org/jira/browse/KARAF-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103530#comment-16103530 ] Michael Vorburger commented on KARAF-5275: -- Started looked at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... > Add systemd journal logging support > --- > > Key: KARAF-5275 > URL: https://issues.apache.org/jira/browse/KARAF-5275 > Project: Karaf > Issue Type: New Feature > Components: karaf-os-integration >Affects Versions: 4.0.9 >Reporter: Michael Vorburger > > KARAF-3858 introduced systemd support in the wrapper. > But (unless I'm missing something), Karaf cannot yet log to the systemd > journal, out of the box? > https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project > which seems to make this easy. Would a contribution to Karaf to include this > external library in the distribution and have an example configuration in > etc/org.ops4j.pax.logging.cfg be welcome? > Or am I getting this all wrong, and this needs to go into OPS4j's PAX > Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-3858) Add systemd support in the wrapper
[ https://issues.apache.org/jira/browse/KARAF-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103464#comment-16103464 ] Michael Vorburger commented on KARAF-3858: -- New issue KARAF-5275 opened for vaguely related topic of systemd journal logging support. > Add systemd support in the wrapper > -- > > Key: KARAF-3858 > URL: https://issues.apache.org/jira/browse/KARAF-3858 > Project: Karaf > Issue Type: Improvement > Components: karaf-os-integration >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 3.0.5, 4.0.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5275) Add systemd journal logging support
Michael Vorburger created KARAF-5275: Summary: Add systemd journal logging support Key: KARAF-5275 URL: https://issues.apache.org/jira/browse/KARAF-5275 Project: Karaf Issue Type: New Feature Components: karaf-os-integration Affects Versions: 4.0.9 Reporter: Michael Vorburger KARAF-3858 introduced systemd support in the wrapper. But (unless I'm missing something), Karaf cannot yet log to the systemd journal, out of the box? https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project which seems to make this easy. Would a contribution to Karaf to include this external library in the distribution and have an example configuration in etc/org.ops4j.pax.logging.cfg be welcome? Or am I getting this all wrong, and this needs to go into OPS4j's PAX Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15981168#comment-15981168
]
Michael Vorburger commented on KARAF-5086:
--
> How does you blueprint look like?
https://git.opendaylight.org/gerrit/#/c/48920/32/caches/sample/impl/src/main/resources/OSGI-INF/blueprint/autowire.xml
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Christian Schneider
>Priority: Critical
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
>
[jira] [Created] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
Michael Vorburger created KARAF-5086:
Summary: Java 8 default methods cause IncompatibleClassChangeError
in blueprint
Key: KARAF-5086
URL: https://issues.apache.org/jira/browse/KARAF-5086
Project: Karaf
Issue Type: Bug
Affects Versions: 4.0.7
Reporter: Michael Vorburger
Priority: Critical
I have an interface with a default method and an implementation of that is
exposed as an OSGi service via Aries Blueprint, and when the default method is
called, it's causing this error: {code}IncompatibleClassChangeError: Found
interface org.opendaylight.infrautils.caches.CacheProvider, but class was
expected. at Proxy*.newCache(){code}
The code looks something like this:
{code}public interface CacheProvider {
Cache newCache(CacheConfig cacheConfig, CachePolicy
initialPolicy);
default Cache newCache(CacheConfig cacheConfig) {
return newCache(cacheConfig, new CachePolicyBuilder().build());
}
{code}
And here's the full stack trace:
{code}opendaylight-user@root>diag
caches-sample (57)
--
Status: Failure
Blueprint
9/4/17 5:35 AM
Exception:
org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
instantiating bean sampleServiceWithCachingImpl of class
org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
org.osgi.service.blueprint.container.ComponentDefinitionException:
org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
instantiating bean sampleServiceWithCachingImpl of class
org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
at
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
at
org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
at
org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
at
org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
at
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
at
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)
at
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)
at
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)
at
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)
at
[jira] [Closed] (KARAF-5084) Use of LocateRegistry in RmiRegistryFactory problematic due to InetAddress.getLocalHost().getHostAddress()
[
https://issues.apache.org/jira/browse/KARAF-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger closed KARAF-5084.
Resolution: Later
> Use of LocateRegistry in RmiRegistryFactory problematic due to
> InetAddress.getLocalHost().getHostAddress()
> --
>
> Key: KARAF-5084
> URL: https://issues.apache.org/jira/browse/KARAF-5084
> Project: Karaf
> Issue Type: Bug
> Components: karaf-management
>Affects Versions: 4.1.1
>Reporter: Michael Vorburger
>
> I'm hitting this error e.g. from the
> KarafTestContainerITest.checkKarafSystemService in the
> org.ops4j.pax.exam2/containers/pax-exam-container-karaf :
> {code}Exception in thread "JMX Connector Thread
> [service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]"
> java.lang.RuntimeException: Could not start JMX connector server
> at
> org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:258)
> Caused by: java.io.IOException: Cannot bind to URL
> [rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: Exception creating connection to:
> 0.0.0.0; nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)]
> at
> javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
> at
> org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:245)
> Caused by: javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: Exception creating connection to: 0.0.0.0;
> nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)]
> at
> com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:161)
> at
> com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
> at javax.naming.InitialContext.bind(InitialContext.java:425)
> at
> javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
> ... 1 more
> Caused by: java.rmi.ConnectIOException: Exception creating connection to:
> 0.0.0.0; nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:631)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
> at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
> at
> com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:155)
> ... 5 more
> Caused by: java.net.NoRouteToHostException: No route to host (Host
> unreachable)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:204)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> ... 10 more
> 02:33:50.966 [main] INFO o.o.p.e.spi.reactors.ReactorManager - suite finished
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 182.081 sec
> <<< FAILURE! - in org.ops4j.pax.exam.karaf.container.KarafTestContainerITest
> checkKarafSystemService(org.ops4j.pax.exam.karaf.container.KarafTestContainerITest)
> Time elapsed: 182.074 sec <<< ERROR!
> java.net.NoRouteToHostException: No route to host (Host unreachable)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at
[jira] [Commented] (KARAF-5084) Use of LocateRegistry in RmiRegistryFactory problematic due to InetAddress.getLocalHost().getHostAddress()
[
https://issues.apache.org/jira/browse/KARAF-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15961400#comment-15961400
]
Michael Vorburger commented on KARAF-5084:
--
http://blog2.vorburger.ch/2017/04/java-local-rmi-using-jdks-inetaddress.html
describes more background about what's going on here.
It turns out that I slightly confused two things: There are two strictly
speaking separate problems in the log above - the first exception, from
org.apache.karaf.management.ConnectorServerFactory, is a actually not directly
impacting Pax Exam - it just means that Karaf Management JMX server hits a
similar issue. Unless you need to use JMX, that is not a problem at least for
running tests. The second exception is
https://ops4j1.jira.com/browse/PAXEXAM-740, and fixing that required no
changes in Karaf, just in Pax Exam, after all.
I'll close this issue as my interest was to get PAXEXAM-740 resolved. If
someone else is bothered by the NoRouteToHostException from Karaf JMX, then
feel free to re-open. The big difference though is that one may WANT the Karaf
JMX RMI server to be accessible on non-loopback network interfaces too, for
remote monitoring & administration; contrary to Pax Exam's RMI which is always
strictly local. So e.g. programmatically in Karaf code forcing
System.setProperty("java.rmi.server.hostname",
InetAddress.getLoopbackAddress().getHostAddress()) is most probably Not a Good
Idea... you may want to simply set java.rmi.server.hostname to a "suitable"
hostname for your system in your Karaf start-up script?
> Use of LocateRegistry in RmiRegistryFactory problematic due to
> InetAddress.getLocalHost().getHostAddress()
> --
>
> Key: KARAF-5084
> URL: https://issues.apache.org/jira/browse/KARAF-5084
> Project: Karaf
> Issue Type: Bug
> Components: karaf-management
>Affects Versions: 4.1.1
>Reporter: Michael Vorburger
>
> I'm hitting this error e.g. from the
> KarafTestContainerITest.checkKarafSystemService in the
> org.ops4j.pax.exam2/containers/pax-exam-container-karaf :
> {code}Exception in thread "JMX Connector Thread
> [service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]"
> java.lang.RuntimeException: Could not start JMX connector server
> at
> org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:258)
> Caused by: java.io.IOException: Cannot bind to URL
> [rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: Exception creating connection to:
> 0.0.0.0; nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)]
> at
> javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
> at
> org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:245)
> Caused by: javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: Exception creating connection to: 0.0.0.0;
> nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)]
> at
> com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:161)
> at
> com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
> at javax.naming.InitialContext.bind(InitialContext.java:425)
> at
> javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
> ... 1 more
> Caused by: java.rmi.ConnectIOException: Exception creating connection to:
> 0.0.0.0; nested exception is:
> java.net.NoRouteToHostException: No route to host (Host unreachable)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:631)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
> at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
> at
> com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:155)
> ... 5 more
> Caused by: java.net.NoRouteToHostException: No route to host (Host
> unreachable)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:204)
> at
>
[jira] [Created] (KARAF-5084) Use of LocateRegistry in RmiRegistryFactory problematic due to InetAddress.getLocalHost().getHostAddress()
Michael Vorburger created KARAF-5084:
Summary: Use of LocateRegistry in RmiRegistryFactory problematic
due to InetAddress.getLocalHost().getHostAddress()
Key: KARAF-5084
URL: https://issues.apache.org/jira/browse/KARAF-5084
Project: Karaf
Issue Type: Bug
Components: karaf-management
Affects Versions: 4.1.1
Reporter: Michael Vorburger
I'm hitting this error e.g. from the
KarafTestContainerITest.checkKarafSystemService in the
org.ops4j.pax.exam2/containers/pax-exam-container-karaf :
{code}Exception in thread "JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]"
java.lang.RuntimeException: Could not start JMX connector server
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:258)
Caused by: java.io.IOException: Cannot bind to URL
[rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
exception is java.rmi.ConnectIOException: Exception creating connection to:
0.0.0.0; nested exception is:
java.net.NoRouteToHostException: No route to host (Host unreachable)]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:245)
Caused by: javax.naming.CommunicationException [Root exception is
java.rmi.ConnectIOException: Exception creating connection to: 0.0.0.0; nested
exception is:
java.net.NoRouteToHostException: No route to host (Host unreachable)]
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:161)
at
com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
at javax.naming.InitialContext.bind(InitialContext.java:425)
at
javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 1 more
Caused by: java.rmi.ConnectIOException: Exception creating connection to:
0.0.0.0; nested exception is:
java.net.NoRouteToHostException: No route to host (Host unreachable)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:631)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:155)
... 5 more
Caused by: java.net.NoRouteToHostException: No route to host (Host unreachable)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:204)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 10 more
02:33:50.966 [main] INFO o.o.p.e.spi.reactors.ReactorManager - suite finished
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 182.081 sec <<<
FAILURE! - in org.ops4j.pax.exam.karaf.container.KarafTestContainerITest
checkKarafSystemService(org.ops4j.pax.exam.karaf.container.KarafTestContainerITest)
Time elapsed: 182.074 sec <<< ERROR!
java.net.NoRouteToHostException: No route to host (Host unreachable)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
[jira] [Commented] (KARAF-4599) KARAF-4564 impact: karaf startup command now only works when invoked from current directoy, no longer via absolute path
[
https://issues.apache.org/jira/browse/KARAF-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356187#comment-15356187
]
Michael Vorburger commented on KARAF-4599:
--
[~jbonofre] I'm NOT a UNIX Shell script crack, BUT I've just played around with
this, and added this at the top of the startup script to understand, after that
new first block ending in PROGNAME=`basename "$REALNAME"` :
{noformat}echo "€0 = " $0
echo "REALNAME = " $REALNAME
echo "DIRNAME = " $DIRNAME
echo "PROGNAME = " $PROGNAME{noformat}
AND as far as I can see, what was done in KARAF-4564 is simply completely
broken, no? I never see any values set for DIRNAME and PROGNAME, and it seems
to just work by chance.
However, if you REMOVE "> /dev/null 2>&1" from that readlink, so that the first
line reads:
{noformat}REALNAME=`readlink -e "$0"`{noformat}
THEN it all works great for me. Given that readlink is a command which prints
to STDOUT, isn't that redirect just plain wrong then? Or am I totally not
getting something here?
PS: Will someone else with a better understand about Karaf's release management
and knowledge about whether KARAF-4564 went into master and/or 4.0.x do the
necessary Affects Version & Fix Version and later cherry-pick correctly etc.
> KARAF-4564 impact: karaf startup command now only works when invoked from
> current directoy, no longer via absolute path
> ---
>
> Key: KARAF-4599
> URL: https://issues.apache.org/jira/browse/KARAF-4599
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 3.0.7, 3.0.8
>Reporter: Michael Vorburger
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 3.0.8
>
>
> KARAF-4564 introduced a fix for "Can't start karaf using symbolic link", but
> this introduced a new regression: Following that change, the ./karaf startup
> command now only works when invoked from current directoy, no longer via
> absolute path. For example:
> {noformat}git clone git://git.apache.org/karaf.git
> cd karaf
> git checkout karaf-3.0.x
> cd tooling/karaf-maven-plugin
> mvn clean install
> cd ../..
> mvn clean install -DskipTests
> cd assemblies/apache-karaf/target/assembly/bin/
> chmod +x karaf
> ./karaf
> cd ../../../../..
> ./assemblies/apache-karaf/target/assembly/bin/karaf
> Error: Could not find or load main class org.apache.karaf.main.Main
> {noformat}
> Of course we could further fiddle with the startup script to solve this
> somehow, but it occurred to me that perhaps somewhere on Apache there is a
> ready made script for this already? Like maybe looking at e.g. how the Maven
> / Ant & other such tools (Gradle?) would be valuable.
> Perhaps some sort of non-regression integration test for both start-up
> scenarios, from current as well as via abs. path, would be of value?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4599) KARAF-4564 impact: karaf startup command now only works when invoked from current directoy, no longer via absolute path
[
https://issues.apache.org/jira/browse/KARAF-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated KARAF-4599:
-
Affects Version/s: 3.0.7
> KARAF-4564 impact: karaf startup command now only works when invoked from
> current directoy, no longer via absolute path
> ---
>
> Key: KARAF-4599
> URL: https://issues.apache.org/jira/browse/KARAF-4599
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 3.0.7, 3.0.8
>Reporter: Michael Vorburger
>Priority: Critical
> Fix For: 3.0.8
>
>
> KARAF-4564 introduced a fix for "Can't start karaf using symbolic link", but
> this introduced a new regression: Following that change, the ./karaf startup
> command now only works when invoked from current directoy, no longer via
> absolute path. For example:
> {noformat}git clone git://git.apache.org/karaf.git
> cd karaf
> git checkout karaf-3.0.x
> cd tooling/karaf-maven-plugin
> mvn clean install
> cd ../..
> mvn clean install -DskipTests
> cd assemblies/apache-karaf/target/assembly/bin/
> chmod +x karaf
> ./karaf
> cd ../../../../..
> ./assemblies/apache-karaf/target/assembly/bin/karaf
> Error: Could not find or load main class org.apache.karaf.main.Main
> {noformat}
> Of course we could further fiddle with the startup script to solve this
> somehow, but it occurred to me that perhaps somewhere on Apache there is a
> ready made script for this already? Like maybe looking at e.g. how the Maven
> / Ant & other such tools (Gradle?) would be valuable.
> Perhaps some sort of non-regression integration test for both start-up
> scenarios, from current as well as via abs. path, would be of value?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4599) KARAF-4564 impact: karaf startup command now only works when invoked from current directoy, no longer via absolute path
[
https://issues.apache.org/jira/browse/KARAF-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated KARAF-4599:
-
Fix Version/s: 3.0.8
> KARAF-4564 impact: karaf startup command now only works when invoked from
> current directoy, no longer via absolute path
> ---
>
> Key: KARAF-4599
> URL: https://issues.apache.org/jira/browse/KARAF-4599
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 3.0.8
>Reporter: Michael Vorburger
>Priority: Critical
> Fix For: 3.0.8
>
>
> KARAF-4564 introduced a fix for "Can't start karaf using symbolic link", but
> this introduced a new regression: Following that change, the ./karaf startup
> command now only works when invoked from current directoy, no longer via
> absolute path. For example:
> {noformat}git clone git://git.apache.org/karaf.git
> cd karaf
> git checkout karaf-3.0.x
> cd tooling/karaf-maven-plugin
> mvn clean install
> cd ../..
> mvn clean install -DskipTests
> cd assemblies/apache-karaf/target/assembly/bin/
> chmod +x karaf
> ./karaf
> cd ../../../../..
> ./assemblies/apache-karaf/target/assembly/bin/karaf
> Error: Could not find or load main class org.apache.karaf.main.Main
> {noformat}
> Of course we could further fiddle with the startup script to solve this
> somehow, but it occurred to me that perhaps somewhere on Apache there is a
> ready made script for this already? Like maybe looking at e.g. how the Maven
> / Ant & other such tools (Gradle?) would be valuable.
> Perhaps some sort of non-regression integration test for both start-up
> scenarios, from current as well as via abs. path, would be of value?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4564) Can't start karaf using symbolic link
[ https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355623#comment-15355623 ] Michael Vorburger commented on KARAF-4564: -- ==> KARAF-4599 > Can't start karaf using symbolic link > -- > > Key: KARAF-4564 > URL: https://issues.apache.org/jira/browse/KARAF-4564 > Project: Karaf > Issue Type: Bug >Affects Versions: 3.0.6 > Environment: Ubuntu (Linux vagrant 3.19.0-25-generic > #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 > GNU/Linux) > OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 > 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64) > Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc) >Reporter: Alexis de Talhouët >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 3.0.7, 4.0.6 > > > When using a symbolic link to use the scripts defined here: > https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin > e.g. karaf or client and so on, it's failing to start the container and show > this error: > Error: Could not find or load main class org.apache.karaf.main.Main > This issue is related to the DIRNAME variable and the way it is setup. > This bug has been found in OpenDaylight, here is the ticket with more > information https://bugs.opendaylight.org/show_bug.cgi?id=6027 > I have also propose a candidate fix in ODL: > https://git.opendaylight.org/gerrit/#/c/39982/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-4599) KARAF-4564 impact: karaf startup command now only works when invoked from current directoy, no longer via absolute path
Michael Vorburger created KARAF-4599:
Summary: KARAF-4564 impact: karaf startup command now only works
when invoked from current directoy, no longer via absolute path
Key: KARAF-4599
URL: https://issues.apache.org/jira/browse/KARAF-4599
Project: Karaf
Issue Type: Bug
Affects Versions: 3.0.8
Reporter: Michael Vorburger
Priority: Critical
KARAF-4564 introduced a fix for "Can't start karaf using symbolic link", but
this introduced a new regression: Following that change, the ./karaf startup
command now only works when invoked from current directoy, no longer via
absolute path. For example:
{noformat}git clone git://git.apache.org/karaf.git
cd karaf
git checkout karaf-3.0.x
cd tooling/karaf-maven-plugin
mvn clean install
cd ../..
mvn clean install -DskipTests
cd assemblies/apache-karaf/target/assembly/bin/
chmod +x karaf
./karaf
cd ../../../../..
./assemblies/apache-karaf/target/assembly/bin/karaf
Error: Could not find or load main class org.apache.karaf.main.Main
{noformat}
Of course we could further fiddle with the startup script to solve this
somehow, but it occurred to me that perhaps somewhere on Apache there is a
ready made script for this already? Like maybe looking at e.g. how the Maven /
Ant & other such tools (Gradle?) would be valuable.
Perhaps some sort of non-regression integration test for both start-up
scenarios, from current as well as via abs. path, would be of value?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
