Re: Discuss: Move Geronimo to Attic
"need" and "in use" does not necessarily translate into community. The need for the geronimo components that have been discussed is not new. As far as I can tell, so far, that has not translated into a community. If we want to continue the project, demonstrate the community that is needed for the project to continue. As I stated previously, a good starting point: create a new charter for the project, identify active PMC members/committers, and obtain board approval. On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg wrote: > Hi Alan! > > There are quite a few things which fit into this scenario imo. > > I think we really miss some 'toolbox project' for EE components at the ASF. > There was a tendency to make all those projects own TLPs for some time. > But that approach simply doesn't scale, and we end up with the same people > in most of those projects anyway. > So moving the ones with lower activity into a common TLP would solve this > problem. Geronimo could probably become this project. > > There are a lot old EE folks around which have tremendous knowledge. And > there are certain technologies which are really cool, but have the > classical EE-lifecycle up-down in terms of activity. > That + the already existing components could be a great chance. > > As you already said yourself: the terms of the big fat EE servers is over. > But nevertheless the technology and requirement behind most of the single > parts is still valid and often unbeaten. > But nowadays it's more about making it easy to plug & play those > technology libs together more freely as they are needed. Thus moving the > focus on maintaining the components and not the server could be really > appreciated by the community. > > You said there will be community if there is a need. I fully agree, and > even more I see a need for those parts. > > LieGrue, > strub > > > Am 12.03.2017 um 19:15 schrieb Alan Cabrera : > > > > After a good night’s sleep, I re-read this thread and I’ll respond > without trying to guide you in where and how you decide to go with your > efforts; thanks in advance for letting me reboot my reply. :) > > > > Any pivot that this community decides upon, will have to be justified to > the ASF board. We will need to explain what will be different and justify > how it will generate sustainable community activity. With regards to that, > I have two general concerns: > > • Will this this specific endeavor generate any new sustainable > community activity? > > • Will any new activity of this specific endeavor represent > activity that is unique to Geronimo or are we doing the chores of other > projects to provide the appearance of activity? > > The current level activity, is due to spec maintenance for downstream > dependencies and we must admit that it is quite low. Being an upstream > “aggregator” does not provide appreciable added value at the cost of the > doubled administration. The specter of duplicate work will, in reality, > never arise; this de facto efficiency is due to the awesomeness of the ASL > 2.0 license. The case for being an aggregator weakens even more given the > fact that there just isn't a lot of work involved in maintaining specs. > > > > Things aren’t much better for the shared sub-systems. If there was > something compelling that needed to be done on the shared sub-systems, it > would have been begun already; given the industry’s penchant for greenfield > development (NIH) I doubt they will ever be revamped. > > > > This is why I went on my “need” soapbox. Some new need must be found > for Geronimo to provide. > > > > > > Regards, > > Alan > > > > > >> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau > wrote: > >> > >> I have quite a hard time to understand why it is an issue having a > project led by the aggregation of others and not by itself? Assume one sec > we close Geronimo or it doesnt exist, then we'll move the bit of code in > one of the project - let say tomee - and tomee will becomes the exact same > kind of project. The alternative is to split in a lot of small projects but > as mentionned a lot of overlap is in these projects in term of forces and > it doesn't work really better, it just multiply the work load for each > contributor. That's why I think G is not a bad solution as it is today. > Scope surely needs to be refined like Mark started to do and objectives are > clearly a bit different than a project pushing its own server/solution but > I think there is a space for it and for Apache I think it is saner this way. > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > >> > >> 2017-03-09 17:01 GMT+01:00 Alan Cabrera : > >> It has been my personal experience that need is the catalyst for a > vibrant OSS project. The product and community spring forth from that. > Adopting an “if we build it they will come” tactic does not usually result > in success. Rather than rummaging through the trunk to see what bits > peo
Re: Discuss: Move Geronimo to Attic
I've been on vacation, so this was an interesting conversation to come home to... :-) I'm not a member of the Geronimo PMC, but I've been monitoring the activity with Geronimo for years. Thus, I have no "voting" capability, but I do have an interest... I like the analysis that Mark started with who is dependent on the various parts of Geronimo -- specs, apis, impls. We probably need to expand on that to include external dependencies as well. For example, David mentioned that IBM is currently using the Yoko orb. Not that it should matter if an external entity has a dependency, but it might demonstrate some potential community involvement. I like the idea of an "ee-commons" type of project to contain the pieces of Geronimo that are currently in use by other projects. I suppose another idea is to just move these common pieces of code to the respective projects. For example, move the JPA specs to OpenJPA. I'm also surprised that TomEE isn't more active in this conversation. I would guess that they have several dependencies on various pieces of Geronimo. I suppose that's another idea -- maybe the common pieces of code could be moved to TomEE? Not trying to dump on that project, but they might be the most active project using these pieces. Just my two cents worth... Kevin On Sun, Mar 12, 2017 at 2:01 PM, Mark Struberg wrote: > Hi Alan! > > There are quite a few things which fit into this scenario imo. > > I think we really miss some 'toolbox project' for EE components at the ASF. > There was a tendency to make all those projects own TLPs for some time. > But that approach simply doesn't scale, and we end up with the same people > in most of those projects anyway. > So moving the ones with lower activity into a common TLP would solve this > problem. Geronimo could probably become this project. > > There are a lot old EE folks around which have tremendous knowledge. And > there are certain technologies which are really cool, but have the > classical EE-lifecycle up-down in terms of activity. > That + the already existing components could be a great chance. > > As you already said yourself: the terms of the big fat EE servers is over. > But nevertheless the technology and requirement behind most of the single > parts is still valid and often unbeaten. > But nowadays it's more about making it easy to plug & play those > technology libs together more freely as they are needed. Thus moving the > focus on maintaining the components and not the server could be really > appreciated by the community. > > You said there will be community if there is a need. I fully agree, and > even more I see a need for those parts. > > LieGrue, > strub > > > Am 12.03.2017 um 19:15 schrieb Alan Cabrera : > > > > After a good night’s sleep, I re-read this thread and I’ll respond > without trying to guide you in where and how you decide to go with your > efforts; thanks in advance for letting me reboot my reply. :) > > > > Any pivot that this community decides upon, will have to be justified to > the ASF board. We will need to explain what will be different and justify > how it will generate sustainable community activity. With regards to that, > I have two general concerns: > > • Will this this specific endeavor generate any new sustainable > community activity? > > • Will any new activity of this specific endeavor represent > activity that is unique to Geronimo or are we doing the chores of other > projects to provide the appearance of activity? > > The current level activity, is due to spec maintenance for downstream > dependencies and we must admit that it is quite low. Being an upstream > “aggregator” does not provide appreciable added value at the cost of the > doubled administration. The specter of duplicate work will, in reality, > never arise; this de facto efficiency is due to the awesomeness of the ASL > 2.0 license. The case for being an aggregator weakens even more given the > fact that there just isn't a lot of work involved in maintaining specs. > > > > Things aren’t much better for the shared sub-systems. If there was > something compelling that needed to be done on the shared sub-systems, it > would have been begun already; given the industry’s penchant for greenfield > development (NIH) I doubt they will ever be revamped. > > > > This is why I went on my “need” soapbox. Some new need must be found > for Geronimo to provide. > > > > > > Regards, > > Alan > > > > > >> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau > wrote: > >> > >> I have quite a hard time to understand why it is an issue having a > project led by the aggregation of others and not by itself? Assume one sec > we close Geronimo or it doesnt exist, then we'll move the bit of code in > one of the project - let say tomee - and tomee will becomes the exact same > kind of project. The alternative is to split in a lot of small projects but > as mentionned a lot of overlap is in these projects in term of forces and > it doesn't
[GitHub] geronimo-specs pull request #5: GERONIMO-6560 make use of geronimo-osgi-loca...
Github user stefanseifert closed the pull request at: https://github.com/apache/geronimo-specs/pull/5 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GERONIMO-6560) JSON spec jar is not able to load provider in an OSGi environment
[
https://issues.apache.org/jira/browse/GERONIMO-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907531#comment-15907531
]
ASF GitHub Bot commented on GERONIMO-6560:
--
Github user stefanseifert closed the pull request at:
https://github.com/apache/geronimo-specs/pull/5
> JSON spec jar is not able to load provider in an OSGi environment
> -
>
> Key: GERONIMO-6560
> URL: https://issues.apache.org/jira/browse/GERONIMO-6560
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Robert Munteanu
>
> I am trying to use
> org.apache.geronimo.specs:geronimo-json_1.0_spec:1.0-alpha-1 together with
> Apache Johnzon in a minimal OSGi environment ( see
> https://lists.apache.org/thread.html/52ecda6f7b859fa9cdd4d9fb64d6f7a3b54f29f971e5536e844d9150@%3Cdev.johnzon.apache.org%3E
> for more details ).
> Looking at the manifest of the JSON spec I can see it has no way of loading
> classes from another jar, and it fails at runtime:
> {noformat}javax.json.JsonException: org.apache.johnzon.core.JsonProviderImpl
> not
> found
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
> at javax.json.Json.createGenerator(Json.java:48)
> at
> ro.lmn.routeradmin.web.impl.AdminServlet.doGet(AdminServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(Servl
> etHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(I
> nvocationChain.java:79)
> at
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispat
> cher.java:124)
> at
> org.apache.felix.http.base.internal.DispatcherServlet.service(Dispatche
> rServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:5
> 83)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler
> .java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler
> .java:1174)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:51
> 1)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.
> java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.
> java:1106)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.jav
> a:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Contex
> tHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.j
> ava:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:524)
> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:
> 253)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(Abstract
> Connection.java:273)
> at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.
> java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executePro
> duceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceCon
> sume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(Execut
> eProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.
> java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.j
> ava:589)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.johnzon.core.JsonProviderImpl
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:129)
> ... 32 more{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GERONIMO-6560) JSON spec jar is not able to load provider in an OSGi environment
[
https://issues.apache.org/jira/browse/GERONIMO-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907155#comment-15907155
]
Stefan Seifert commented on GERONIMO-6560:
--
i've created a new PR for this issue following the OSGi spec-compliant way. it
currently targets only json_1.0_spec but should be applied to json_1.1_spec
later as well.
https://github.com/apache/geronimo-specs/pull/6
the major changes:
* add the appropriate bundle headers
* replace the custom implementation to parse {{META-INF/services/}} files with
the JDK standard way by using the Java ServiceLoader API
* remove the reflection based code for OSGi support which did not work anyway
to make it working three things have to play together:
# deploy json_1.0 spec jar with the fix from this PR
# deploy updated johnzon-core 1.0.x jar with the fix from JOHNZON-108
# additionally deploy the bundles and make sure they are loaded before the
others via OSGi bundle startlevel (as described
[here|http://aries.apache.org/modules/spi-fly.html]):
** {{org.apache.aries.spifly:org.apache.aries.spifly.dynamic.bundle:1.0.8}}
** {{org.apache.aries:org.apache.aries.util:1.1.1}}
** {{org.ow2.asm:asm-all:5.0.4}}
then johnzon works as expected via javax.json API from other OSGi bundles.
> JSON spec jar is not able to load provider in an OSGi environment
> -
>
> Key: GERONIMO-6560
> URL: https://issues.apache.org/jira/browse/GERONIMO-6560
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Robert Munteanu
>
> I am trying to use
> org.apache.geronimo.specs:geronimo-json_1.0_spec:1.0-alpha-1 together with
> Apache Johnzon in a minimal OSGi environment ( see
> https://lists.apache.org/thread.html/52ecda6f7b859fa9cdd4d9fb64d6f7a3b54f29f971e5536e844d9150@%3Cdev.johnzon.apache.org%3E
> for more details ).
> Looking at the manifest of the JSON spec I can see it has no way of loading
> classes from another jar, and it fails at runtime:
> {noformat}javax.json.JsonException: org.apache.johnzon.core.JsonProviderImpl
> not
> found
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
> at javax.json.Json.createGenerator(Json.java:48)
> at
> ro.lmn.routeradmin.web.impl.AdminServlet.doGet(AdminServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(Servl
> etHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(I
> nvocationChain.java:79)
> at
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispat
> cher.java:124)
> at
> org.apache.felix.http.base.internal.DispatcherServlet.service(Dispatche
> rServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:5
> 83)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler
> .java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler
> .java:1174)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:51
> 1)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.
> java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.
> java:1106)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.jav
> a:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Contex
> tHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.j
> ava:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:524)
> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:
> 253)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(Abstract
> Connection.java:273)
> at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.
> java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executePro
> duceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceCon
> sume(ExecuteProduceConsume.java
[jira] [Commented] (GERONIMO-6560) JSON spec jar is not able to load provider in an OSGi environment
[
https://issues.apache.org/jira/browse/GERONIMO-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907147#comment-15907147
]
ASF GitHub Bot commented on GERONIMO-6560:
--
GitHub user stefanseifert opened a pull request:
https://github.com/apache/geronimo-specs/pull/6
GERONIMO-6560 JSON spec jar is not able to load provider in an OSGi
environment
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/stefanseifert/geronimo-specs
feature/GERONIMO-6560-json-osgi-serviceloader
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/geronimo-specs/pull/6.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 #6
commit af5b9c47a7ba03a8cc1b824af5949411eac54943
Author: sseifert
Date: 2017-03-13T10:09:26Z
GERONIMO-6560 add Require-Capability header for OSGi ServiceLoader support
commit 04aef91eae1edd266ef4150bdd38f52e2ade3ccc
Author: sseifert
Date: 2017-03-13T10:23:15Z
GERONIMO-6560 switch to ServiceLoader implementation instead of parsing
META-INF/services/ files manually
remove reflection-based OSGi support code which did not work anyway
> JSON spec jar is not able to load provider in an OSGi environment
> -
>
> Key: GERONIMO-6560
> URL: https://issues.apache.org/jira/browse/GERONIMO-6560
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Robert Munteanu
>
> I am trying to use
> org.apache.geronimo.specs:geronimo-json_1.0_spec:1.0-alpha-1 together with
> Apache Johnzon in a minimal OSGi environment ( see
> https://lists.apache.org/thread.html/52ecda6f7b859fa9cdd4d9fb64d6f7a3b54f29f971e5536e844d9150@%3Cdev.johnzon.apache.org%3E
> for more details ).
> Looking at the manifest of the JSON spec I can see it has no way of loading
> classes from another jar, and it fails at runtime:
> {noformat}javax.json.JsonException: org.apache.johnzon.core.JsonProviderImpl
> not
> found
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
> at javax.json.Json.createGenerator(Json.java:48)
> at
> ro.lmn.routeradmin.web.impl.AdminServlet.doGet(AdminServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(Servl
> etHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(I
> nvocationChain.java:79)
> at
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispat
> cher.java:124)
> at
> org.apache.felix.http.base.internal.DispatcherServlet.service(Dispatche
> rServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:5
> 83)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler
> .java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler
> .java:1174)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:51
> 1)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.
> java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.
> java:1106)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.jav
> a:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Contex
> tHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.j
> ava:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:524)
> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:
> 253)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(Abstract
> Connection.java:273)
> at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.
> java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executePro
> duceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceCon
>
[GitHub] geronimo-specs pull request #6: GERONIMO-6560 JSON spec jar is not able to l...
GitHub user stefanseifert opened a pull request: https://github.com/apache/geronimo-specs/pull/6 GERONIMO-6560 JSON spec jar is not able to load provider in an OSGi environment You can merge this pull request into a Git repository by running: $ git pull https://github.com/stefanseifert/geronimo-specs feature/GERONIMO-6560-json-osgi-serviceloader Alternatively you can review and apply these changes as the patch at: https://github.com/apache/geronimo-specs/pull/6.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 #6 commit af5b9c47a7ba03a8cc1b824af5949411eac54943 Author: sseifert Date: 2017-03-13T10:09:26Z GERONIMO-6560 add Require-Capability header for OSGi ServiceLoader support commit 04aef91eae1edd266ef4150bdd38f52e2ade3ccc Author: sseifert Date: 2017-03-13T10:23:15Z GERONIMO-6560 switch to ServiceLoader implementation instead of parsing META-INF/services/ files manually remove reflection-based OSGi support code which did not work anyway --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GERONIMO-6560) JSON spec jar is not able to load provider in an OSGi environment
[
https://issues.apache.org/jira/browse/GERONIMO-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906988#comment-15906988
]
Stefan Seifert commented on GERONIMO-6560:
--
after some experiments and discussion in
https://github.com/apache/geronimo-specs/pull/5 i think the "old geronimo osgi
support" way is perhaps not the best (with "SPI-Provider" header and some extra
classes embedded in the spec jar).
i will try the osgi spec complient way in combination with aries spyfly and
report back here.
> JSON spec jar is not able to load provider in an OSGi environment
> -
>
> Key: GERONIMO-6560
> URL: https://issues.apache.org/jira/browse/GERONIMO-6560
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Robert Munteanu
>
> I am trying to use
> org.apache.geronimo.specs:geronimo-json_1.0_spec:1.0-alpha-1 together with
> Apache Johnzon in a minimal OSGi environment ( see
> https://lists.apache.org/thread.html/52ecda6f7b859fa9cdd4d9fb64d6f7a3b54f29f971e5536e844d9150@%3Cdev.johnzon.apache.org%3E
> for more details ).
> Looking at the manifest of the JSON spec I can see it has no way of loading
> classes from another jar, and it fails at runtime:
> {noformat}javax.json.JsonException: org.apache.johnzon.core.JsonProviderImpl
> not
> found
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
> at javax.json.Json.createGenerator(Json.java:48)
> at
> ro.lmn.routeradmin.web.impl.AdminServlet.doGet(AdminServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(Servl
> etHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(I
> nvocationChain.java:79)
> at
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispat
> cher.java:124)
> at
> org.apache.felix.http.base.internal.DispatcherServlet.service(Dispatche
> rServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:5
> 83)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler
> .java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler
> .java:1174)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:51
> 1)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.
> java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.
> java:1106)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.jav
> a:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Contex
> tHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.j
> ava:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:524)
> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:
> 253)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(Abstract
> Connection.java:273)
> at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.
> java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executePro
> duceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceCon
> sume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(Execut
> eProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.
> java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.j
> ava:589)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.johnzon.core.JsonProviderImpl
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
