Other version of javax.xml.bind when running with Java 8 and 11

Hello, Is there a technical reason for org.apache.felix.framework providing other version of javax.xml.bind package when running with Java 8 (2.2.8) and Java 11 (2.3.0)? Best regards, Lukasz Lech -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: /bin/status ERROR: transport error 202: bind failed: Address already in use

Looks great. That call should be much more performant then bin/status, I guess? So I ignore that issue for now and wait for release. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

/bin/status ERROR: transport error 202: bind failed: Address already in use

I'm experiencing something that looks like regression to KARAF-5332. I've prepared scripts for liveness / readiness probe for Kubernetes, that are using $KARAF_HOME/bin/status. To test them, I've started docker container locally (with docker run) and when calling /bin/status I'm getting the

A feature (CXF) exposing its own version of javax.xml.bind

Hello, After updating some of the libraries in my container, I've got an error about javax.xml.bind being exposed via 2 dependency chains. It is about javax.xml.bind that is exposed by both system bundle and and jakarta.xml.bind-api, which is installed by cxf-features

Re: 501 status code when starting Karaf built with maven plugin

That's true, that is not the complete list. I've removed private features, and one of them is including cxf. I've found out, that the cxf-karaf-commands are included in feature cxf-commands, and that feature is conditional: cxf-specs

Re: 501 status code when starting Karaf built with maven plugin

OK it seems that something was wrong and I haven't noticed it before. The error is when transfering the artifact http://repo1.maven.org/maven2/org/apache/cxf/karaf/cxf-karaf-commands/3.3.1/cxf-karaf-commands-3.3.1.jar It is not in target/assemby/system after build. The karaf writes it is about

Re: 501 status code when starting Karaf built with maven plugin

jbonofre wrote > Hi, > > you can take a look on https://issues.apache.org/jira/browse/KARAF-6600 > > Just quick workaround: just change http to https in > etc/org.ops4j.pax.url.mvn.cfg > > Regards > JB Hello, This is exactly what I wanted to test, but my question is, do karaf requires

501 status code when starting Karaf built with maven plugin

Hello, I'm using karaf built with maven plugin in docker image. Today I've noticed error when starting. Stack trace was showing to 501 error when contacting central maven repository, which seems to be caused by the issue https://support.sonatype.com/hc/en-us/articles/360041287334 While it is

Re: Active sessions getting invalidated

This is pax-web 7.2.10, provided with karaf 4.2.6. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Active sessions getting invalidated

As for now, I could it replicate only for Windows. Linux (dockerized) seems not to have this issue. Jetty seem to rely too heavily on java.util.Timer, which many people claim is generally unreliable... -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Active sessions getting invalidated

What is connector idle timeout and how it differs from session idle timeout? The session is active, and I'm doing normal HTTP request. Do I need to do something special in my keepalive routine to mark the session as active? -- Sent from:

Active sessions getting invalidated

I'm using Karaf 4.2.6 and I have a keepalive thread in my client that does http get to the servlet that only pings the session (request.getSession().getId()). I'm loggint out the last access date from session and it gets updated after each keepalive. However, Jetty's HouseKeeper keeps

Re: Loader constraint violation: javax.xml.soap.SOAPFault

Hello, I've found something out. The exception comes from: java.lang.LinkageError: javax/xml/soap/SOAPFault at javax.xml.ws.soap.SOAPFaultException.(SOAPFaultException.java:63) ~[?:?] at org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195) ~[?:?] at

Re: Adding Jackson to Karaf startup.properties file to enable JSON logging

I've installed mvn:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.10.2 (through console bundle:install) and it do import com.fasterxml.jackson.databind.ser, but I still get the same error from mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.10.2 Decanter looks like an overkill, especially that

Re: Adding Jackson to Karaf startup.properties file to enable JSON logging

Hello, I've just got similar problem after trying to activate JSON logging for Karaf 4.2.6, with configuration that worked perfectly in 4.1.2: log4j2.appender.rolling.layout.type = JsonLayout log4j2.appender.rolling.layout.compact = true log4j2.appender.rolling.layout.eventEol = true I'm

Re: Problems with Jetty Session Managemenent?

OK great, I've updated Karaf and tested, ans everything is fine -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Problems with Jetty Session Managemenent?

Hello, Is it fixed in Karaf 4.2.6? I can't find the issue in the release notes for pax web. What is the issue number? Best regards, Lukasz Lech -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Loader constraint violation: javax.xml.soap.SOAPFault

I can provide more specific information. I've checked other web services that we are calling. The services that throws declared exception (via wsdl:fault section in wsdl) are OK. The only problem are services that declare no exceptions, and throw runtime exceptions. Those exceptions are tried to

Re: Loader constraint violation: javax.xml.soap.SOAPFault

I've updated karaf to version 4.2.5 and cxf to 3.3.2 and the problem is still existing. Only handlin of SOAPFault produces the problem. How exactly are you using CXF? I have the following import in my bundle: org.apache.cxf.jaxws.spi If I remove it, I have the following error: SEVERE:

Re: Loader constraint violation: javax.xml.soap.SOAPFault

I see only one exporter of javax.xml.soap: Bundle 353 - Apache ServiceMix :: Specs :: SAAJ API 1.3 2.9.0 (state: Active) Symbolic Name: org.apache.servicemix.specs.saaj-api-1.3 Version: 2.9.0 Bundle Location:

Loader constraint violation: javax.xml.soap.SOAPFault

Hello, I'm getting LinkageError when processing SOAPFault: java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "javax/xml/soap/SOAPFault" I've found out the very old issue about this:

Re: karaf-maven-plugin doesn't fail on feature name typo

mvn karaf:verify doesn't fail when referring non-existing features. It is inconsistent, because if I give non-existing bootRepository, the mvn verify will fail, however the non-existing bootFeature will be silently ignored. -- Sent from:

Re: Problems with Jetty Session Managemenent?

Hello, Have you found some solution or workaroud? Is it possible to downgrade Jetty? I start having strange feeling I'd be stuck with Karaf version 4.1.3 until Oracle finally kills Java project... ;) -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by org.apache.karaf.webconsole.console [73]

Hello, When running Karaf 4.2.4 with Java 11 I'm getting the following error when restarting/reloading bundle from web console: Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by org.apache.karaf.webconsole.console [73] The bundle starts

Re: Problems with Jetty Session Managemenent?

jbonofre wrote > Yes, that could be an issue. It's maybe my fault when I updated to the > new Jetty version. > > Let me check and add a test. What is the potential solution? Waiting for Jetty fix or rollback to last stable version? Is it possible to rollback manually without big issues, or some

Re: Problems with Jetty Session Managemenent?

Probably that? https://ops4j1.jira.com/browse/PAXWEB-1197?attachmentOrder=desc -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Problems with Jetty Session Managemenent?

I've found something very disturbing, I need to rollback to Karaf 4.1.3 and redo the tests. I've seen that my SessionListener is registered *twice*. I've quickly started 4.1.3 locally and confirmed, there the SessionListener is called only once. But to find out, if doubling of SessionListener

Re: Problems with Jetty Session Managemenent?

jbonofre wrote > Hi Lukasz, > > not I'm aware off. Do you have a scenario ? Not something application-agnostic. I have a memory intensive application, that stores big objects in session. The session is invalidated on user logout. The test brings the container near to JVM memory limit, but there

Re: Guide for upgrading from karaf 4.1.x to 4.2.x

Thanks, I've needed to update persistence to 2_1, unfortunately it means that the change in code is not backwards-compatible... placing blueprint descriptors in the same project like JPA classes and logic looked like a good idea at the beginning, as always in life... I have no idea why my

Re: Karaf 4.2.1 JDK 10 - provide jax-ws

This is exactly my problem, finding out the required bundles to install. As for now, I've found that 'canonical' SO answer: https://stackoverflow.com/questions/48204141/replacements-for-deprecated-jpms-modules-with-java-ee-apis/48204154#48204154 unfortunately, many of the listed artifacts are

Re: Karaf 4.2.1 JDK 10 - provide jax-ws

No, from CXF. I suppose I wasn't expect to because they collide? There is no reason I'd need CXF, I simply need any JAXB+JAX-WS implementation. jbonofre wrote > Hi, > > Did you install JAXB bundle (from ServiceMix) ? > > Regards > JB -- Sent from:

Re: Karaf 4.2.1 JDK 10 - provide jax-ws

Hello, I'm using OpenJDK 10.0.2 from Ubuntu distribution. After installing jaxws-api I've got another problem from the part of the code that prepares XML to be sent via WS : javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath. at

Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor

karaf@root()> package:exports |grep com.sun.xml.bind com.sun.xml.bind.annotation | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl com.sun.xml.bind.api.impl | 2.2.11 |

Re: Check if Feature was fully installed?

Hello, It looks like I've solved this problem by adding additional check: I check the state of all bundles after all features are 'Started'. The bundle can be Active, GrantPeriod or Failure, but ought not to be simply 'Resolved'. This additional check asserts, that all bundles are kicked out of

Re: OSGi and karaf in the cloud. Looking for some experiences and stories

How are you doing that? Are you using Maven plugin to build karaf distribution? I was exploring that option at the beginning, but I've never got runable Karaf distribution that way... Now I'm modifying karaf config files to add my features to boot, but the big issue with that is, it requires to

Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor

I think I miss some background to understand what you mean by blacklisting... We have the code, that is working in desktop version, is working in Karaf 4.1.3, but has problems with Karaf 4.2.1. So something must have changed between those versions. Status update: removing CXF changes nothing,

Re: OSGi and karaf in the cloud. Looking for some experiences and stories

I'm running Karaf in docker image in OpenShift. No cloud yet but cloud-compliant. I've got to trick like hell in order to build docker image. I've created a bundle that installs features using FeatureService (based on config file) and then stops bundle 0, so that all bundles are installed during

Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor

I'm using Oracle JDK 8 (Windows). Those the imports that I make in one bundle which has this issue: org.apache.commons.csv,version=1.5.0 from org.apache.commons.csv (197) org.apache.commons.io,version=1.4. from org.apache.commons.io (201) org.apache.commons.io,version=2.4.0 from

Re: Confused about feature dependency="true"

Ready: https://issues.apache.org/jira/browse/KARAF-5542 I've replicated that behaviour with the following feature set: https://github.com/llech/karaf-refresh-demo/tree/master -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Confused about feature dependency="true"

So it doesn't look like my case. The update happens when the subsequent features are batch-updated, there is no change of snapshot in the meantime. If it can be disabled, how? How is that mechanism called and which part of code is responsible for that? I'd like to take look on java sources to

Re: Confused about feature dependency="true"

OK so the code would not refresh if aries-jpa was not a snapshot? Quite unfortunately, there is a HUGE (for us) bug in aries-jpa is fixed in 2.7.0 version, which is not released... I'm able to do a 'fake' release to our local maven repository. I didn't thought there's some logic in feature

Re: Confused about feature dependency="true"

Bundles to install: here are only my private bundles listed Bundles to refresh: com.eclipsesource.jaxrs.jaxrs-publisher/5.3.1 (Wired to org.glassfish.jersey.containers.jersey-container-servlet-core/2.22.2 which is being refreshed) javax.persistence/2.1.1.v201509150925 (Should be wired

Re: Confused about feature dependency="true"

I think I've found the offender. The message says: org.glassfish.jersey.containers.jersey-container-servlet-core/2.22.2 (Wired to javax.persistence/2.1.1.v201509150925 which is being refreshed) However, there's no indicator why it should be refreshed. The exact bundle is already installed in

Re: Confused about feature dependency="true"

Ok thank you, all my features are verified by maven plugin. So you say that no matter if I have features with dependency="true" or not, if the feature is already installed, it will not be touched? So the observed behavior, that after installing new feature the blueprint context from bundles from

Re: Confused about feature dependency="true"

Does the same appply to features? Because I've noticed an improvement, after marking the dependent features as dependency="true": service1-core However, if I've done the same for all my features, including system ones (jpa, transaction-api, transaction etc.) I've ended up with my bundles

Re: Unable to install feature via console: datasource filtered by name not found

It might have something to do with http://stackoverflow.com/questions/42476572/karaf-feature-install-missing-requirement-osgi-service-but-it-is-there Adding <_removeheaders>Require-Capability to maven-bundle-plugin configuration hs "solved" the problem. -- View this message in context:

Unable to install feature via console: datasource filtered by name not found

Hello, I've packed my persistence unit in feature (there are much more bundles, but only the persistence one is relevant in the problem). It looks like following (irrelevant depencencies are removed): jpa transaction-api transaction