jersey-min does work, jersey-all generates 503

[col-panic]

If I try to re-implement the ds example in http://eclipsesource.com/blogs/2014/02/04/step-by-step-how-to-bring-jax-rs-and-osgi-together/ to a current target (Mars) then using jersey-min within my application does work as expected, using jersey-all does always result in

HTTP ERROR: 503

Problem accessing /services/status. Reason:

    Jersey is not ready yet!

[hstaudacher]

@kolkoo can you confirm? For me both libs are working fine.

[col-panic]

Just tried again. Adding com.eclipsesource.jaxrs.jersey-min to my application feature does work, com.eclipsesource.jaxrs.jersey-max fails, the output on startup, however, is for both the same

2015-09-02 10:14:19.519:INFO::Start Level: Equinox Container: 00e60e9c-4a51-0015-15ab-c9380a664e1e: Logging initialized @616ms
2015-09-02 10:14:19.586:INFO:oejs.Server:Start Level: Equinox Container: 00e60e9c-4a51-0015-15ab-c9380a664e1e: jetty-9.2.9.v20150224
2015-09-02 10:14:19.615:INFO:oejsh.ContextHandler:Start Level: Equinox Container: 00e60e9c-4a51-0015-15ab-c9380a664e1e: Started o.e.j.s.ServletContextHandler@57462756{/,null,AVAILABLE}
2015-09-02 10:14:19.621:INFO:oejs.ServerConnector:Start Level: Equinox Container: 00e60e9c-4a51-0015-15ab-c9380a664e1e: Started ServerConnector@6613b2fb{HTTP/1.1}{0.0.0.0:9090}
2015-09-02 10:14:19.621:INFO:oejs.Server:Start Level: Equinox Container: 00e60e9c-4a51-0015-15ab-c9380a664e1e: Started @720ms

[hstaudacher]

when you say it's a problem with both (min and all) then I bet it's a problem in the connector itself. bad thing is I can't reproduce it. Would you mind to export your projects together with the launch config and the target file? Putting it in a git repo that I could clone would be perfect ;)

[col-panic]

Please find the code in https://github.com/elexis/elexisbox you may re-enact it as follows: The start configuration is ElexisBox OSGI.launch, in the feature eb.core.app.feature replace jersey-min with jersey-all - each time after start connecting to http://localhost:9090/services/isAlive with jersey-min you get time current timestamp, with jersey-all you get 503

thanks a lot!

[hstaudacher]

Alright, thank you. I will check it out. But it will take a while.

[kolkoo]

I will also take a look as soon as I can

[col-panic]

thanks a lot guys!

Ivan Iliev schrieb:

I will also take a look as soon as I can

— Reply to this email directly or view it on GitHub https://github.com/hstaudacher/osgi-jax-rs-connector/issues/106#issuecomment-136980251.

[maggu2810]

Hello, I must admint, I knew nothing about JAX-RS.

I would like to migrate openHAB 2 to use Karaf. I have recently seen you offer a feature for JAX-RS. Until now I am using a custom one, but I do not think this is related.

If I install and run my custom Karaf distribution I get the "Jersey is not ready yet!", too. Could you help me with some inspection?

If you would like to give it a try:

git clone git@github.com:maggu2810/openhab2.git
cd openhab2
git checkout -b master-for-karaf origin/master-for-karaf
mvn clean install
cd distributions/openhab2-runtime/target/assembly
bin/karaf

# In the Karaf console install the Paper UI
feature:install openhab2-addon-ui-paper

After that you can have a look at: http://127.0.0.1:8080/ui/index.html

[maggu2810]

My problem exists also using jersey-min.

I debugged a little bit:

ServletContainerBridge: public void run() The method "getServletContainer().init( servletConfig );" is called and after that the finally block is executed. So I tried to investigate the line of code, that raises the (non ServletException) exception.

ServletContainer.java
169: init(final WebConfig webconfig)
170: ... new WebComponent(...
WebComponent.java
322: public WebComponent(...
339: ... new ApplicationHandler(...
ApplicationHandler.java
322: public ApplicationHandler(...
344: ... ResourceConfig.createRuntimeCOnfig(application);
ResourceConfig.java
...
1167: private RuntimeConfig(...
1174: registerComponentsOf(customRootApp);
...
1199: private void registerComponentsOf(final Application application)
Look into the Runnable...
1207: registerIntances(...
541: public final ResourceConfig registerInstances(final Set<Object> instances)
547: register(instance);
448: public ResourceConfig register(final Object component)
450: state.register(component);
CommonConfig.java
460: public CommonConfig register(final Object component)
464: if (componentBag.register(component, getModelEnhancer(componentClass))) {
ComponentBag.java
307: public boolean register(Object component, Inflector<ContractProvider.Builder, ContractProvider> modelEnhancer) {
309: ... registerModel(...
ComponentBag.java
393: private boolean registerModel(...
406: ... modelFor(...
444: private static ContractProvider modelFor(...
contractMap is null
450: ... asMap(...
483: if (annotation instanceof Priority) {
NoClassDefFoundError.java
58: public NoClassDefFoundError(String s)
s = javax/annotation/Priority

For me it seems to be: NoClassDefFoundError "javax/annotation/Priority"

Will check this.

Would be nice if the NoClassDefFoundError would be not catched at all and reported to the OSGi framework.

[maggu2810]

Before jersey does call the init of the ServletContainer it sets the context class loader of the current thread to that on of the Request class in ServletContainerBridge line 46.

Thread.currentThread().setContextClassLoader( Request.class.getClassLoader() );

Does this mean, that the javax.annotation must be imported by the class using Jersey without use it themselves?

[maggu2810]

For me a bug in Karaf raised the problem. This is the commit, that will solve it for 4.0.2: https://github.com/apache/karaf/commit/59c11e4deebd6940136149a44f8485a941653e28

The 4.0.1 Karaf config.properties states, that the OSGi framework bundle will export javax.annotation 1.2.

So, all fine now (for me). My problem is solved.

[col-panic]

I hope that the solution you found for Karaf will also be applicable to Equinox?!

[maggu2810]

The problem on my setup was caused by a bug in Karaf 4.0.1 (did not check older versions). It is not related to Eclipse Equinox or Apache Felix (not running in Karaf) at all.

[col-panic]

I just started from scratch with a new project, and all steps and the result is still the same :( Could you point me to a location showing the differences of min and all? Do I need all? thanks

[hstaudacher]

The min and all bundles are created via a maven build, see:

https://github.com/hstaudacher/osgi-jax-rs-connector/blob/master/build/com.eclipsesource.jaxrs.jersey.all/pom.xml https://github.com/hstaudacher/osgi-jax-rs-connector/blob/master/build/com.eclipsesource.jaxrs.jersey.min/pom.xml

[cschneider]

Are you sure such a rebundling is a good idea? We did that in cxf at the start but we are using separate bundles again now. From the pom you listed it seems there are not that many dependencies involved (Very possible that I am simply missing the transitive ones :-)

[hstaudacher]

@cschneider, yes I think rebundling is a good idea ;). The first versions of the connector used the jersey bundle as they were at the time. This works out pretty good with Jersey 1.x because they cared about their depdendencies. With Jersey 2.x there was a bundle and dependency explosion . So, we ended up having dozens of Jersey bundles and dependencies. The connector still works with the original bundles. The jersey-min and jersey-all are just convenience bundles we use ourself.

[cschneider]

There might be issues when another karaf feature also installs jersey. If both use the same bundles karaf can make sure that jersey is only installed once. If one of the features uses a rebundled version we probably end up with two sets of jersey bundles. As I currently do not know of such a case I do not have a strong opinion about it. We should keep an eye on this though.

[hstaudacher]

Ok I see your point. But as I said the jersey-all is optional. So, why do we not just modify the karaf feature to use plain jersey bundles? I'm not that familiar with karaf. So, if you could help out here this would be great.

[cschneider]

Ok .. will create a pull request.

[hstaudacher]

any progress here?

[hstaudacher]

No response. Will close the issue as "works for me" ;).

Please reopen if this issue still occurs.

[col-panic]

For me its still the case .. but I can happily live with jersey-min :)

[MinimaJack]

Up the same problem

24   jersey-allcom.eclipsesource.jaxrs.jersey-all   2.22.2      Active  
25   OSGi JAX-RS Connectorcom.eclipsesource.jaxrs.publisher 5.3.1.201602281253      Active

and got Jersey is not ready yet!

[maggu2810]

Using Karaf I solved it using a separate feature instead of the mega-multi-bundle.

The different start-levels do the trick. https://github.com/maggu2810/kat/blob/master/features/jersey-min/src/main/feature/feature.xml

@MinimaJack See my commit message here: https://github.com/maggu2810/kat/commit/94270c30e484ca3255b045771a756dbe83f7db4c

First:
===
If the jersey modules are initiated on the same level as the ones that
registered the ServletContainer class, this could lead to errors using
asyncrhonous processing:
javax.servlet.ServletException: java.lang.UnsupportedOperationException:
Asynchronous processing not supported on Servlet 2.x container.

See e.g.
https://gist.github.com/maggu2810/ef57c2656fa9f76052042da5f70d9d2f

This could be worked around to start the Jersey components in front of
the usage.
The important module is jersey-core-server, that adds support for
servlet 3.x.
===

Second:
===
Without this start-level tuning you can run in a
HTTP ERROR 503: Jersey is not ready yet!

[danielWQ]

I had the same problem using provider-gson (2.3) and publisher (5.3.1) in my application. After investigating a bit, I found out that in my case this was a classloading issue. (BTW: it didn't work with jersey-min as described above).

The ServletContainerBridge dismisses the current classloader and exchanges it by the one of javax.ws.rs.core.Request. During initialization, org.glassfish.jersey.server.internal.RuntimeDelegateImpl is requested from the classloader, but it cannot find the class and raises a ClassNotFoundException. The requested class is part of the jersey-all jar.

Since I also had the bundle javax.ws.rs:javax.ws.rs-api running in OSGi, ServletContainerBridge used the Request class (and the classloader) from this JAR, which obviously could not find the RuntimeDelegateImpl. After removing javax.ws.rs:javax.ws.rs-api, ServletContainerBridge used the Request class and the classloader from jersey-all, which succeeds loading RuntimeDelegateImpl.

[col-panic]

It seems that in com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge#run() Exceptions are "swallowed" - that is, we get the message Jersey is not yet ready, while there is a different error like e.g.:

org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization.

This ultimately leads to the service not being loaded - resulting in this current behaviour.

[abhishukl]

Is this "Jersey is not ready issue" ever solved ? As I am facing the same problem, I am using jersey-all-2.22.2, publisher-5.3.1, provider-gson-2.3, provider-security-2.2 while exposing AEM OSGi service as rest service.

Interestingly I am getting this error everytime. Is there any solution we have ever got ?

[col-panic]

Just had this problem again. The real exception causing it, is hidden in the call to getServletContainer().init( servletConfig ); and never shown anywhere. In my case java.lang.RuntimeException: java.lang.ClassNotFoundException: org.glassfish.jersey.server.internal.RuntimeDelegateImpl cannot be found by javax.ws.rs_2.0.1.v201504171603as I use Java 11.

We should find a way to at least log this error, instead of saying nothing.

[kallmekunal]

Hello All, Is this issue resolved. I am getting very similar issue. Migrating an VM based karaf application to K8S. Able to resolve all bundles/Components to ACtive. When trying to curl a get http request getting 503 Jersy not ready yet error.

Seems getServletContainer().init() is not initialized and servlet is not yet loaded and this is what may be the cause. Tried debugging the code but its swallowing exception it seems. Intrestingly my rest endpoint is registered in the karaf as http:list is gving me the list of endpoints registered which is having my rest url as well. I am using below dependencies: karaf@root()> list | grep -i jersey 217 | Active | 80 | 2.34.0 | jersey-container-servlet-core 446 | Active | 80 | 2.34.0 | jersey-media-multipart 502 | Active | 80 | 2.34.0 | jersey-core-client 542 | Active | 80 | 2.34.0 | jersey-core-common 576 | Active | 80 | 2.34.0 | jersey-core-server karaf@root()> list | grep -i connector 501 | Active | 80 | 5.3.1.201602281253 | OSGi JAX-RS Connector karaf@root()> list | grep -i annotation 193 | Active | 80 | 2.10.2 | Jackson-annotations 248 | Active | 80 | 4.16.2 | appconfiguration-msv-annotation 258 | Active | 80 | 2.12.2 | Jackson-annotations 262 | Active | 80 | 2.10.2 | Jackson module: JAXB Annotations 288 | Active | 80 | 1.5.8 | swagger-annotations 296 | Active | 80 | 4.14.0 | appconfiguration-msv-annotation 322 | Active | 80 | 1.0.1 | Annotation 1.1 348 | Active | 80 | 1.3 | javax.annotation API 619 | Active | 80 | 10.20.0 | com.ericsson.bss.rm.cpm.cdac.dataenquiry/annotations karaf@root()> list | grep -i jax 239 | Active | 80 | 2.12.2 | Jackson-JAXRS-JSON 262 | Active | 80 | 2.10.2 | Jackson module: JAXB Annotations 294 | Active | 80 | 2.10.2 | Jackson-JAXRS-JSON 332 | Active | 80 | 2.10.2 | Jackson-JAXRS-base 493 | Active | 80 | 2.12.2 | Jackson-JAXRS-base 501 | Active | 80 | 5.3.1.201602281253 | OSGi JAX-RS Connector karaf@root()> list | grep -i javax 324 | Active | 80 | 3.0.0.b56 | javax.xml.ws API v.2.1 348 | Active | 80 | 1.3 | javax.annotation API 382 | Active | 80 | 2.6.1 | javax.inject:1 as OSGi bundle 443 | Active | 80 | 2.1.99.b01 | javax.ws.rs-api 512 | Active | 80 | 1.4.0 | javax.xml.soap API karaf@root()>

Any help and suggestion will be deeply appriciated :)