You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by James Carman <ja...@carmanconsulting.com> on 2017/06/24 04:47:55 UTC
Non-CDI johnzon-jsonb jar?
I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
Import-Package:
javax.enterprise.context.spi;version="[1.0,2)",javax.enterprise.event;version="[1.0,2)",javax.enterprise.inject.spi;version="[1.0,2)"...
While it's nice that it supports CDI and all, I think that's too
heavy-handed for general purpose usage. I don't want to have to load up
CDI just to be able to load Johnzon into my OSGi container. Perhaps we can
break the CDI support into a separate jar?
James
Re: Non-CDI johnzon-jsonb jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think so as well but pby the way to go.
Le 24 juin 2017 15:55, "James Carman" <ja...@carmanconsulting.com> a écrit :
Yep, just confirmed, the Geronimo bundle will fallback to using
ServiceLoader, so we get the same exception.
karaf@root()> list
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
29 │ Active │ 80 │ 4.1.1 │ Apache Karaf :: OSGi Services ::
Event
53 │ Active │ 80 │ 1.0.0 │ Apache Geronimo JSON Spec 1.1
54 │ Active │ 80 │ 1.0.0 │ Apache Geronimo JSON Binding Spec
1.0
55 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: Core
108 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: Mapper
109 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: JSON-B Implementation
110 │ Resolved │ 80 │ 0.3.0.SNAPSHOT │ Microbule :: JSON-B :: Test
So, looks like we'll have to update Geronimo in order to get things loading
in OSGi properly. :(
On Sat, Jun 24, 2017 at 9:46 AM James Carman <ja...@carmanconsulting.com>
wrote:
> It looks like the Geronimo version of JsonbProvider tries to use the
> "org.apache.geronimo.osgi.locator.ProviderLocator" class via reflection,
> but that's not available. The JAX-RS bundle from Geronimo (and the
> javamail) look like they just include that inside themselves. Should we do
> that for JSON-B?
>
> On Sat, Jun 24, 2017 at 9:39 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> hmm weird, did you try with geronimo API? Not sure it has the full OSGi
>> integration but it doesn't fallback on yasson at least.
>>
>> This spi fly support has been contributed for karaf but if it doesnt work
>> we can enhance it. In geronimo we tend to use OSGi registry to find
>> provider, we can go this way if saner.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-06-24 15:34 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>>
>> > I'm trying to get the following BundleActivator to work in a simple
>> bundle:
>> >
>> > public class JsonbActivator implements BundleActivator {
>> >
>> > private static final Logger LOGGER =
>> > LoggerFactory.getLogger(JsonbActivator.class);
>> >
>> > @Override
>> > public void start(BundleContext context) throws Exception {
>> > LOGGER.info(JsonbBuilder.create().toJson(new Person("Apache",
>> > "Johnzon")));
>> > }
>> >
>> > @Override
>> > public void stop(BundleContext context) throws Exception {
>> >
>> > }
>> >
>> > public static class Person {
>> >
>> > private final String firstName;
>> > private final String lastName;
>> >
>> > public Person(String firstName, String lastName) {
>> > this.firstName = firstName;
>> > this.lastName = lastName;
>> > }
>> >
>> > public String getFirstName() {
>> > return firstName;
>> > }
>> >
>> > public String getLastName() {
>> > return lastName;
>> > }
>> > }
>> > }
>> >
>> >
>> > After loading Spi-Fly, JSON-P, and JSON-B (after fixing its dependency
>> on
>> > an internal package of mapper), I get the following exception:
>> >
>> > 2017-06-24T09:21:55,111 | ERROR | Karaf local console user karaf |
>> > ShellUtil | 43 - org.apache.karaf.shell.core -
>> 4.1.1
>> > | Exception caught while executing command
>> > org.apache.karaf.shell.support.MultiException: Error executing command
>> on
>> > bundles:
>> > Error starting bundle 110: Activator start error in bundle
>> > org.microbule.jsonb-test [110].
>> > at
>> >
>> org.apache.karaf.shell.support.MultiException.
throwIf(MultiException.java:
>> > 61)
>> > ~[43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:67)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > execute(BundlesCommand.java:52)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.action.command.ActionCommand.
>> > execute(ActionCommand.java:84)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.
SecuredCommand.execute(
>> > SecuredCommand.java:68)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.
SecuredCommand.execute(
>> > SecuredCommand.java:86)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
>> > Closure.java:486)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor.runWorker(
>> > ThreadPoolExecutor.java:1142)
>> > [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> > ThreadPoolExecutor.java:617)
>> > [?:?]
>> > at java.lang.Thread.run(Thread.java:745) [?:?]
>> > Suppressed: java.lang.Exception: Error starting bundle 110: Activator
>> start
>> > error in bundle org.microbule.jsonb-test [110].
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:64)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > execute(BundlesCommand.java:52)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.action.command.ActionCommand.
>> > execute(ActionCommand.java:84)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.
SecuredCommand.execute(
>> > SecuredCommand.java:68)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.
SecuredCommand.execute(
>> > SecuredCommand.java:86)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
>> > Closure.java:486)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor.runWorker(
>> > ThreadPoolExecutor.java:1142)
>> > [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> > ThreadPoolExecutor.java:617)
>> > [?:?]
>> > at java.lang.Thread.run(Thread.java:745) [?:?]
>> > Caused by: org.osgi.framework.BundleException: Activator start error in
>> > bundle org.microbule.jsonb-test [110].
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> > Caused by: javax.json.bind.JsonbException: JSON Binding provider
>> > org.eclipse.yasson.JsonBindingProvider not found
>> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:120)
>> > ~[?:?]
>> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
>> > at org.microbule.jsonb.test.JsonbActivator.start(
JsonbActivator.java:24)
>> > ~[?:?]
>> > at
>> >
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
>> > java:697)
>> > ~[?:?]
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> > Caused by: java.lang.ClassNotFoundException:
>> > org.eclipse.yasson.JsonBindingProvider not found by javax.json.bind-api
>> > [108]
>> > at
>> >
>> org.apache.felix.framework.BundleWiringImpl.
findClassOrResourceByDelegatio
>> > n(BundleWiringImpl.java:1550)
>> > ~[?:?]
>> > at
>> > org.apache.felix.framework.BundleWiringImpl.access$200(
>> > BundleWiringImpl.java:79)
>> > ~[?:?]
>> > at
>> > org.apache.felix.framework.BundleWiringImpl$
BundleClassLoader.loadClass(
>> > BundleWiringImpl.java:1958)
>> > ~[?:?]
>> > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
>> > at java.lang.Class.forName0(Native Method) ~[?:?]
>> > at java.lang.Class.forName(Class.java:264) ~[?:?]
>> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:117)
>> > ~[?:?]
>> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
>> > at org.microbule.jsonb.test.JsonbActivator.start(
JsonbActivator.java:24)
>> > ~[?:?]
>> > at
>> >
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
>> > java:697)
>> > ~[?:?]
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> >
>> > In order to use Spi-Fly to load services, I think we need some bundles
>> to
>> > add the following MANIFEST.MF entries:
>> >
>> > osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)"
>> > osgi.serviceloader;
>> > filter:="(osgi.serviceloader=javax.json.bind.spi.
>> > JsonbProvider)";cardinality:=multiple
>> >
>> > However, even after adding that to my bundle (perhaps it needs to be on
>> the
>> > json.bind-api bundle instead), I still get the error.
>> >
>> >
>> > On Sat, Jun 24, 2017 at 8:25 AM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> > > Ok so just checked and all the cdi API usage is not mandatory at
>> runtime
>> > so
>> > > if loading fails it is skipped making it OSGi compatible updating
>> > metadata.
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> > > <https://javaeefactory-rmannibucau.rhcloud.com>
>> > >
>> > > 2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>> > >
>> > > > Well, it looks like we appear to attempt to use reflection. The
>> > > > BeanManager is typed as Object. However, the CDIs class has a hard
>> > > > reference to the BeanManager class, so that goes right out the
>> window.
>> > :(
>> > > >
>> > > >
>> > > > On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <
>> > > rmannibucau@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Should be done by reflection - think we do for cdi 1.1 but we
>> surefy
>> > > > didnt
>> > > > > for 1.0 - to detect it then we can have a cdi instance provider
>> with
>> > > the
>> > > > > api being optional
>> > > > >
>> > > > > Le 24 juin 2017 14:03, "James Carman" <james@carmanconsulting.com
>
>> a
>> > > > > écrit :
>> > > > >
>> > > > > > Unfortunately, the JohnzonBuilder class appears to use the CDI
>> > stuff
>> > > > > > in-line. Merely marking it optional won't work I don't think
>> (so
>> > > much
>> > > > > for
>> > > > > > my PR). :(
>> > > > > >
>> > > > > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
>> > > > > rmannibucau@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > We can just make it optional in the manifest. We shouldnt
have
>> > cdi
>> > > > > being
>> > > > > > > mandatory even for the standalone case.
>> > > > > > >
>> > > > > > > Le 24 juin 2017 06:48, "James Carman" <
>> > james@carmanconsulting.com>
>> > > a
>> > > > > > > écrit :
>> > > > > > >
>> > > > > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we
>> > have:
>> > > > > > > >
>> > > > > > > > Import-Package:
>> > > > > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
>> > > > > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
>> > > > > > > > spi;version="[1.0,2)"...
>> > > > > > > >
>> > > > > > > > While it's nice that it supports CDI and all, I think
that's
>> > too
>> > > > > > > > heavy-handed for general purpose usage. I don't want to
>> have
>> > to
>> > > > load
>> > > > > > up
>> > > > > > > > CDI just to be able to load Johnzon into my OSGi container.
>> > > > Perhaps
>> > > > > we
>> > > > > > > can
>> > > > > > > > break the CDI support into a separate jar?
>> > > > > > > >
>> > > > > > > > James
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Non-CDI johnzon-jsonb jar?
Posted by James Carman <ja...@carmanconsulting.com>.
Yep, just confirmed, the Geronimo bundle will fallback to using
ServiceLoader, so we get the same exception.
karaf@root()> list
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
29 │ Active │ 80 │ 4.1.1 │ Apache Karaf :: OSGi Services ::
Event
53 │ Active │ 80 │ 1.0.0 │ Apache Geronimo JSON Spec 1.1
54 │ Active │ 80 │ 1.0.0 │ Apache Geronimo JSON Binding Spec
1.0
55 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: Core
108 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: Mapper
109 │ Active │ 80 │ 1.1.2.SNAPSHOT │ Johnzon :: JSON-B Implementation
110 │ Resolved │ 80 │ 0.3.0.SNAPSHOT │ Microbule :: JSON-B :: Test
So, looks like we'll have to update Geronimo in order to get things loading
in OSGi properly. :(
On Sat, Jun 24, 2017 at 9:46 AM James Carman <ja...@carmanconsulting.com>
wrote:
> It looks like the Geronimo version of JsonbProvider tries to use the
> "org.apache.geronimo.osgi.locator.ProviderLocator" class via reflection,
> but that's not available. The JAX-RS bundle from Geronimo (and the
> javamail) look like they just include that inside themselves. Should we do
> that for JSON-B?
>
> On Sat, Jun 24, 2017 at 9:39 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> hmm weird, did you try with geronimo API? Not sure it has the full OSGi
>> integration but it doesn't fallback on yasson at least.
>>
>> This spi fly support has been contributed for karaf but if it doesnt work
>> we can enhance it. In geronimo we tend to use OSGi registry to find
>> provider, we can go this way if saner.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-06-24 15:34 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>>
>> > I'm trying to get the following BundleActivator to work in a simple
>> bundle:
>> >
>> > public class JsonbActivator implements BundleActivator {
>> >
>> > private static final Logger LOGGER =
>> > LoggerFactory.getLogger(JsonbActivator.class);
>> >
>> > @Override
>> > public void start(BundleContext context) throws Exception {
>> > LOGGER.info(JsonbBuilder.create().toJson(new Person("Apache",
>> > "Johnzon")));
>> > }
>> >
>> > @Override
>> > public void stop(BundleContext context) throws Exception {
>> >
>> > }
>> >
>> > public static class Person {
>> >
>> > private final String firstName;
>> > private final String lastName;
>> >
>> > public Person(String firstName, String lastName) {
>> > this.firstName = firstName;
>> > this.lastName = lastName;
>> > }
>> >
>> > public String getFirstName() {
>> > return firstName;
>> > }
>> >
>> > public String getLastName() {
>> > return lastName;
>> > }
>> > }
>> > }
>> >
>> >
>> > After loading Spi-Fly, JSON-P, and JSON-B (after fixing its dependency
>> on
>> > an internal package of mapper), I get the following exception:
>> >
>> > 2017-06-24T09:21:55,111 | ERROR | Karaf local console user karaf |
>> > ShellUtil | 43 - org.apache.karaf.shell.core -
>> 4.1.1
>> > | Exception caught while executing command
>> > org.apache.karaf.shell.support.MultiException: Error executing command
>> on
>> > bundles:
>> > Error starting bundle 110: Activator start error in bundle
>> > org.microbule.jsonb-test [110].
>> > at
>> >
>> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:
>> > 61)
>> > ~[43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:67)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > execute(BundlesCommand.java:52)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.action.command.ActionCommand.
>> > execute(ActionCommand.java:84)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
>> > SecuredCommand.java:68)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
>> > SecuredCommand.java:86)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
>> > Closure.java:486)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor.runWorker(
>> > ThreadPoolExecutor.java:1142)
>> > [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> > ThreadPoolExecutor.java:617)
>> > [?:?]
>> > at java.lang.Thread.run(Thread.java:745) [?:?]
>> > Suppressed: java.lang.Exception: Error starting bundle 110: Activator
>> start
>> > error in bundle org.microbule.jsonb-test [110].
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:64)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > execute(BundlesCommand.java:52)
>> > [22:org.apache.karaf.bundle.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.action.command.ActionCommand.
>> > execute(ActionCommand.java:84)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
>> > SecuredCommand.java:68)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at
>> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
>> > SecuredCommand.java:86)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
>> > Closure.java:486)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
>> > [43:org.apache.karaf.shell.core:4.1.1]
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor.runWorker(
>> > ThreadPoolExecutor.java:1142)
>> > [?:?]
>> > at
>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> > ThreadPoolExecutor.java:617)
>> > [?:?]
>> > at java.lang.Thread.run(Thread.java:745) [?:?]
>> > Caused by: org.osgi.framework.BundleException: Activator start error in
>> > bundle org.microbule.jsonb-test [110].
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> > Caused by: javax.json.bind.JsonbException: JSON Binding provider
>> > org.eclipse.yasson.JsonBindingProvider not found
>> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:120)
>> > ~[?:?]
>> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
>> > at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
>> > ~[?:?]
>> > at
>> >
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
>> > java:697)
>> > ~[?:?]
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> > Caused by: java.lang.ClassNotFoundException:
>> > org.eclipse.yasson.JsonBindingProvider not found by javax.json.bind-api
>> > [108]
>> > at
>> >
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegatio
>> > n(BundleWiringImpl.java:1550)
>> > ~[?:?]
>> > at
>> > org.apache.felix.framework.BundleWiringImpl.access$200(
>> > BundleWiringImpl.java:79)
>> > ~[?:?]
>> > at
>> > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(
>> > BundleWiringImpl.java:1958)
>> > ~[?:?]
>> > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
>> > at java.lang.Class.forName0(Native Method) ~[?:?]
>> > at java.lang.Class.forName(Class.java:264) ~[?:?]
>> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:117)
>> > ~[?:?]
>> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
>> > at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
>> > ~[?:?]
>> > at
>> >
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
>> > java:697)
>> > ~[?:?]
>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
>> ~[?:?]
>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
>> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>> ~[?:?]
>> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
>> > ~[?:?]
>> > at
>> > org.apache.karaf.bundle.command.BundlesCommand.
>> > doExecute(BundlesCommand.java:62)
>> > ~[?:?]
>> > ... 14 more
>> >
>> > In order to use Spi-Fly to load services, I think we need some bundles
>> to
>> > add the following MANIFEST.MF entries:
>> >
>> > osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)"
>> > osgi.serviceloader;
>> > filter:="(osgi.serviceloader=javax.json.bind.spi.
>> > JsonbProvider)";cardinality:=multiple
>> >
>> > However, even after adding that to my bundle (perhaps it needs to be on
>> the
>> > json.bind-api bundle instead), I still get the error.
>> >
>> >
>> > On Sat, Jun 24, 2017 at 8:25 AM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> > > Ok so just checked and all the cdi API usage is not mandatory at
>> runtime
>> > so
>> > > if loading fails it is skipped making it OSGi compatible updating
>> > metadata.
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> > > <https://javaeefactory-rmannibucau.rhcloud.com>
>> > >
>> > > 2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>> > >
>> > > > Well, it looks like we appear to attempt to use reflection. The
>> > > > BeanManager is typed as Object. However, the CDIs class has a hard
>> > > > reference to the BeanManager class, so that goes right out the
>> window.
>> > :(
>> > > >
>> > > >
>> > > > On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <
>> > > rmannibucau@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Should be done by reflection - think we do for cdi 1.1 but we
>> surefy
>> > > > didnt
>> > > > > for 1.0 - to detect it then we can have a cdi instance provider
>> with
>> > > the
>> > > > > api being optional
>> > > > >
>> > > > > Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com>
>> a
>> > > > > écrit :
>> > > > >
>> > > > > > Unfortunately, the JohnzonBuilder class appears to use the CDI
>> > stuff
>> > > > > > in-line. Merely marking it optional won't work I don't think
>> (so
>> > > much
>> > > > > for
>> > > > > > my PR). :(
>> > > > > >
>> > > > > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
>> > > > > rmannibucau@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > We can just make it optional in the manifest. We shouldnt have
>> > cdi
>> > > > > being
>> > > > > > > mandatory even for the standalone case.
>> > > > > > >
>> > > > > > > Le 24 juin 2017 06:48, "James Carman" <
>> > james@carmanconsulting.com>
>> > > a
>> > > > > > > écrit :
>> > > > > > >
>> > > > > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we
>> > have:
>> > > > > > > >
>> > > > > > > > Import-Package:
>> > > > > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
>> > > > > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
>> > > > > > > > spi;version="[1.0,2)"...
>> > > > > > > >
>> > > > > > > > While it's nice that it supports CDI and all, I think that's
>> > too
>> > > > > > > > heavy-handed for general purpose usage. I don't want to
>> have
>> > to
>> > > > load
>> > > > > > up
>> > > > > > > > CDI just to be able to load Johnzon into my OSGi container.
>> > > > Perhaps
>> > > > > we
>> > > > > > > can
>> > > > > > > > break the CDI support into a separate jar?
>> > > > > > > >
>> > > > > > > > James
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Non-CDI johnzon-jsonb jar?
Posted by James Carman <ja...@carmanconsulting.com>.
It looks like the Geronimo version of JsonbProvider tries to use the
"org.apache.geronimo.osgi.locator.ProviderLocator" class via reflection,
but that's not available. The JAX-RS bundle from Geronimo (and the
javamail) look like they just include that inside themselves. Should we do
that for JSON-B?
On Sat, Jun 24, 2017 at 9:39 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> hmm weird, did you try with geronimo API? Not sure it has the full OSGi
> integration but it doesn't fallback on yasson at least.
>
> This spi fly support has been contributed for karaf but if it doesnt work
> we can enhance it. In geronimo we tend to use OSGi registry to find
> provider, we can go this way if saner.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-24 15:34 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>
> > I'm trying to get the following BundleActivator to work in a simple
> bundle:
> >
> > public class JsonbActivator implements BundleActivator {
> >
> > private static final Logger LOGGER =
> > LoggerFactory.getLogger(JsonbActivator.class);
> >
> > @Override
> > public void start(BundleContext context) throws Exception {
> > LOGGER.info(JsonbBuilder.create().toJson(new Person("Apache",
> > "Johnzon")));
> > }
> >
> > @Override
> > public void stop(BundleContext context) throws Exception {
> >
> > }
> >
> > public static class Person {
> >
> > private final String firstName;
> > private final String lastName;
> >
> > public Person(String firstName, String lastName) {
> > this.firstName = firstName;
> > this.lastName = lastName;
> > }
> >
> > public String getFirstName() {
> > return firstName;
> > }
> >
> > public String getLastName() {
> > return lastName;
> > }
> > }
> > }
> >
> >
> > After loading Spi-Fly, JSON-P, and JSON-B (after fixing its dependency on
> > an internal package of mapper), I get the following exception:
> >
> > 2017-06-24T09:21:55,111 | ERROR | Karaf local console user karaf |
> > ShellUtil | 43 - org.apache.karaf.shell.core -
> 4.1.1
> > | Exception caught while executing command
> > org.apache.karaf.shell.support.MultiException: Error executing command on
> > bundles:
> > Error starting bundle 110: Activator start error in bundle
> > org.microbule.jsonb-test [110].
> > at
> >
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:
> > 61)
> > ~[43:org.apache.karaf.shell.core:4.1.1]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > doExecute(BundlesCommand.java:67)
> > [22:org.apache.karaf.bundle.core:4.1.1]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > execute(BundlesCommand.java:52)
> > [22:org.apache.karaf.bundle.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.action.command.ActionCommand.
> > execute(ActionCommand.java:84)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> > SecuredCommand.java:68)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> > SecuredCommand.java:86)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
> > Closure.java:486)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > [?:?]
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > [?:?]
> > at java.lang.Thread.run(Thread.java:745) [?:?]
> > Suppressed: java.lang.Exception: Error starting bundle 110: Activator
> start
> > error in bundle org.microbule.jsonb-test [110].
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > doExecute(BundlesCommand.java:64)
> > [22:org.apache.karaf.bundle.core:4.1.1]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > execute(BundlesCommand.java:52)
> > [22:org.apache.karaf.bundle.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.action.command.ActionCommand.
> > execute(ActionCommand.java:84)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> > SecuredCommand.java:68)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> > SecuredCommand.java:86)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.executeStatement(
> > Closure.java:486)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> > [43:org.apache.karaf.shell.core:4.1.1]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > [?:?]
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > [?:?]
> > at java.lang.Thread.run(Thread.java:745) [?:?]
> > Caused by: org.osgi.framework.BundleException: Activator start error in
> > bundle org.microbule.jsonb-test [110].
> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288)
> ~[?:?]
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> ~[?:?]
> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> > ~[?:?]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > doExecute(BundlesCommand.java:62)
> > ~[?:?]
> > ... 14 more
> > Caused by: javax.json.bind.JsonbException: JSON Binding provider
> > org.eclipse.yasson.JsonBindingProvider not found
> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:120)
> > ~[?:?]
> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
> > at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
> > ~[?:?]
> > at
> > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
> > java:697)
> > ~[?:?]
> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
> ~[?:?]
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> ~[?:?]
> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> > ~[?:?]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > doExecute(BundlesCommand.java:62)
> > ~[?:?]
> > ... 14 more
> > Caused by: java.lang.ClassNotFoundException:
> > org.eclipse.yasson.JsonBindingProvider not found by javax.json.bind-api
> > [108]
> > at
> >
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegatio
> > n(BundleWiringImpl.java:1550)
> > ~[?:?]
> > at
> > org.apache.felix.framework.BundleWiringImpl.access$200(
> > BundleWiringImpl.java:79)
> > ~[?:?]
> > at
> > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(
> > BundleWiringImpl.java:1958)
> > ~[?:?]
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> > at java.lang.Class.forName0(Native Method) ~[?:?]
> > at java.lang.Class.forName(Class.java:264) ~[?:?]
> > at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:117)
> > ~[?:?]
> > at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
> > at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
> > ~[?:?]
> > at
> > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
> > java:697)
> > ~[?:?]
> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238)
> ~[?:?]
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> ~[?:?]
> > at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> > ~[?:?]
> > at
> > org.apache.karaf.bundle.command.BundlesCommand.
> > doExecute(BundlesCommand.java:62)
> > ~[?:?]
> > ... 14 more
> >
> > In order to use Spi-Fly to load services, I think we need some bundles to
> > add the following MANIFEST.MF entries:
> >
> > osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)"
> > osgi.serviceloader;
> > filter:="(osgi.serviceloader=javax.json.bind.spi.
> > JsonbProvider)";cardinality:=multiple
> >
> > However, even after adding that to my bundle (perhaps it needs to be on
> the
> > json.bind-api bundle instead), I still get the error.
> >
> >
> > On Sat, Jun 24, 2017 at 8:25 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Ok so just checked and all the cdi API usage is not mandatory at
> runtime
> > so
> > > if loading fails it is skipped making it OSGi compatible updating
> > metadata.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> > >
> > > > Well, it looks like we appear to attempt to use reflection. The
> > > > BeanManager is typed as Object. However, the CDIs class has a hard
> > > > reference to the BeanManager class, so that goes right out the
> window.
> > :(
> > > >
> > > >
> > > > On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Should be done by reflection - think we do for cdi 1.1 but we
> surefy
> > > > didnt
> > > > > for 1.0 - to detect it then we can have a cdi instance provider
> with
> > > the
> > > > > api being optional
> > > > >
> > > > > Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com>
> a
> > > > > écrit :
> > > > >
> > > > > > Unfortunately, the JohnzonBuilder class appears to use the CDI
> > stuff
> > > > > > in-line. Merely marking it optional won't work I don't think (so
> > > much
> > > > > for
> > > > > > my PR). :(
> > > > > >
> > > > > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > We can just make it optional in the manifest. We shouldnt have
> > cdi
> > > > > being
> > > > > > > mandatory even for the standalone case.
> > > > > > >
> > > > > > > Le 24 juin 2017 06:48, "James Carman" <
> > james@carmanconsulting.com>
> > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we
> > have:
> > > > > > > >
> > > > > > > > Import-Package:
> > > > > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > > > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > > > > > > spi;version="[1.0,2)"...
> > > > > > > >
> > > > > > > > While it's nice that it supports CDI and all, I think that's
> > too
> > > > > > > > heavy-handed for general purpose usage. I don't want to have
> > to
> > > > load
> > > > > > up
> > > > > > > > CDI just to be able to load Johnzon into my OSGi container.
> > > > Perhaps
> > > > > we
> > > > > > > can
> > > > > > > > break the CDI support into a separate jar?
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hmm weird, did you try with geronimo API? Not sure it has the full OSGi
integration but it doesn't fallback on yasson at least.
This spi fly support has been contributed for karaf but if it doesnt work
we can enhance it. In geronimo we tend to use OSGi registry to find
provider, we can go this way if saner.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-24 15:34 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> I'm trying to get the following BundleActivator to work in a simple bundle:
>
> public class JsonbActivator implements BundleActivator {
>
> private static final Logger LOGGER =
> LoggerFactory.getLogger(JsonbActivator.class);
>
> @Override
> public void start(BundleContext context) throws Exception {
> LOGGER.info(JsonbBuilder.create().toJson(new Person("Apache",
> "Johnzon")));
> }
>
> @Override
> public void stop(BundleContext context) throws Exception {
>
> }
>
> public static class Person {
>
> private final String firstName;
> private final String lastName;
>
> public Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
>
> public String getFirstName() {
> return firstName;
> }
>
> public String getLastName() {
> return lastName;
> }
> }
> }
>
>
> After loading Spi-Fly, JSON-P, and JSON-B (after fixing its dependency on
> an internal package of mapper), I get the following exception:
>
> 2017-06-24T09:21:55,111 | ERROR | Karaf local console user karaf |
> ShellUtil | 43 - org.apache.karaf.shell.core - 4.1.1
> | Exception caught while executing command
> org.apache.karaf.shell.support.MultiException: Error executing command on
> bundles:
> Error starting bundle 110: Activator start error in bundle
> org.microbule.jsonb-test [110].
> at
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:
> 61)
> ~[43:org.apache.karaf.shell.core:4.1.1]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> doExecute(BundlesCommand.java:67)
> [22:org.apache.karaf.bundle.core:4.1.1]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> execute(BundlesCommand.java:52)
> [22:org.apache.karaf.bundle.core:4.1.1]
> at
> org.apache.karaf.shell.impl.action.command.ActionCommand.
> execute(ActionCommand.java:84)
> [43:org.apache.karaf.shell.core:4.1.1]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> SecuredCommand.java:68)
> [43:org.apache.karaf.shell.core:4.1.1]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> SecuredCommand.java:86)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.executeStatement(
> Closure.java:486)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> [43:org.apache.karaf.shell.core:4.1.1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Suppressed: java.lang.Exception: Error starting bundle 110: Activator start
> error in bundle org.microbule.jsonb-test [110].
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> doExecute(BundlesCommand.java:64)
> [22:org.apache.karaf.bundle.core:4.1.1]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> execute(BundlesCommand.java:52)
> [22:org.apache.karaf.bundle.core:4.1.1]
> at
> org.apache.karaf.shell.impl.action.command.ActionCommand.
> execute(ActionCommand.java:84)
> [43:org.apache.karaf.shell.core:4.1.1]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> SecuredCommand.java:68)
> [43:org.apache.karaf.shell.core:4.1.1]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(
> SecuredCommand.java:86)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.executeStatement(
> Closure.java:486)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> [43:org.apache.karaf.shell.core:4.1.1]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> [43:org.apache.karaf.shell.core:4.1.1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle org.microbule.jsonb-test [110].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288) ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
> at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> ~[?:?]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> doExecute(BundlesCommand.java:62)
> ~[?:?]
> ... 14 more
> Caused by: javax.json.bind.JsonbException: JSON Binding provider
> org.eclipse.yasson.JsonBindingProvider not found
> at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:120)
> ~[?:?]
> at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
> at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
> ~[?:?]
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
> java:697)
> ~[?:?]
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238) ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
> at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> ~[?:?]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> doExecute(BundlesCommand.java:62)
> ~[?:?]
> ... 14 more
> Caused by: java.lang.ClassNotFoundException:
> org.eclipse.yasson.JsonBindingProvider not found by javax.json.bind-api
> [108]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegatio
> n(BundleWiringImpl.java:1550)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(
> BundleWiringImpl.java:79)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(
> BundleWiringImpl.java:1958)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at java.lang.Class.forName0(Native Method) ~[?:?]
> at java.lang.Class.forName(Class.java:264) ~[?:?]
> at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:117)
> ~[?:?]
> at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
> at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
> ~[?:?]
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.
> java:697)
> ~[?:?]
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238) ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
> at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> ~[?:?]
> at
> org.apache.karaf.bundle.command.BundlesCommand.
> doExecute(BundlesCommand.java:62)
> ~[?:?]
> ... 14 more
>
> In order to use Spi-Fly to load services, I think we need some bundles to
> add the following MANIFEST.MF entries:
>
> osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)"
> osgi.serviceloader;
> filter:="(osgi.serviceloader=javax.json.bind.spi.
> JsonbProvider)";cardinality:=multiple
>
> However, even after adding that to my bundle (perhaps it needs to be on the
> json.bind-api bundle instead), I still get the error.
>
>
> On Sat, Jun 24, 2017 at 8:25 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Ok so just checked and all the cdi API usage is not mandatory at runtime
> so
> > if loading fails it is skipped making it OSGi compatible updating
> metadata.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> >
> > > Well, it looks like we appear to attempt to use reflection. The
> > > BeanManager is typed as Object. However, the CDIs class has a hard
> > > reference to the BeanManager class, so that goes right out the window.
> :(
> > >
> > >
> > > On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Should be done by reflection - think we do for cdi 1.1 but we surefy
> > > didnt
> > > > for 1.0 - to detect it then we can have a cdi instance provider with
> > the
> > > > api being optional
> > > >
> > > > Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com> a
> > > > écrit :
> > > >
> > > > > Unfortunately, the JohnzonBuilder class appears to use the CDI
> stuff
> > > > > in-line. Merely marking it optional won't work I don't think (so
> > much
> > > > for
> > > > > my PR). :(
> > > > >
> > > > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > We can just make it optional in the manifest. We shouldnt have
> cdi
> > > > being
> > > > > > mandatory even for the standalone case.
> > > > > >
> > > > > > Le 24 juin 2017 06:48, "James Carman" <
> james@carmanconsulting.com>
> > a
> > > > > > écrit :
> > > > > >
> > > > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we
> have:
> > > > > > >
> > > > > > > Import-Package:
> > > > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > > > > > spi;version="[1.0,2)"...
> > > > > > >
> > > > > > > While it's nice that it supports CDI and all, I think that's
> too
> > > > > > > heavy-handed for general purpose usage. I don't want to have
> to
> > > load
> > > > > up
> > > > > > > CDI just to be able to load Johnzon into my OSGi container.
> > > Perhaps
> > > > we
> > > > > > can
> > > > > > > break the CDI support into a separate jar?
> > > > > > >
> > > > > > > James
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by James Carman <ja...@carmanconsulting.com>.
I'm trying to get the following BundleActivator to work in a simple bundle:
public class JsonbActivator implements BundleActivator {
private static final Logger LOGGER =
LoggerFactory.getLogger(JsonbActivator.class);
@Override
public void start(BundleContext context) throws Exception {
LOGGER.info(JsonbBuilder.create().toJson(new Person("Apache",
"Johnzon")));
}
@Override
public void stop(BundleContext context) throws Exception {
}
public static class Person {
private final String firstName;
private final String lastName;
public Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public String getFirstName() {
return firstName;
}
public String getLastName() {
return lastName;
}
}
}
After loading Spi-Fly, JSON-P, and JSON-B (after fixing its dependency on
an internal package of mapper), I get the following exception:
2017-06-24T09:21:55,111 | ERROR | Karaf local console user karaf |
ShellUtil | 43 - org.apache.karaf.shell.core - 4.1.1
| Exception caught while executing command
org.apache.karaf.shell.support.MultiException: Error executing command on
bundles:
Error starting bundle 110: Activator start error in bundle
org.microbule.jsonb-test [110].
at
org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
~[43:org.apache.karaf.shell.core:4.1.1]
at
org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:67)
[22:org.apache.karaf.bundle.core:4.1.1]
at
org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:52)
[22:org.apache.karaf.bundle.core:4.1.1]
at
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
[43:org.apache.karaf.shell.core:4.1.1]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
[43:org.apache.karaf.shell.core:4.1.1]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
[43:org.apache.karaf.shell.core:4.1.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Suppressed: java.lang.Exception: Error starting bundle 110: Activator start
error in bundle org.microbule.jsonb-test [110].
at
org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:64)
[22:org.apache.karaf.bundle.core:4.1.1]
at
org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:52)
[22:org.apache.karaf.bundle.core:4.1.1]
at
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
[43:org.apache.karaf.shell.core:4.1.1]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
[43:org.apache.karaf.shell.core:4.1.1]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
[43:org.apache.karaf.shell.core:4.1.1]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
[43:org.apache.karaf.shell.core:4.1.1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: org.osgi.framework.BundleException: Activator start error in
bundle org.microbule.jsonb-test [110].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2288) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
~[?:?]
at
org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:62)
~[?:?]
... 14 more
Caused by: javax.json.bind.JsonbException: JSON Binding provider
org.eclipse.yasson.JsonBindingProvider not found
at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:120) ~[?:?]
at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
~[?:?]
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
~[?:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
~[?:?]
at
org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:62)
~[?:?]
... 14 more
Caused by: java.lang.ClassNotFoundException:
org.eclipse.yasson.JsonBindingProvider not found by javax.json.bind-api
[108]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Class.java:264) ~[?:?]
at javax.json.bind.spi.JsonbProvider.provider(JsonbProvider.java:117) ~[?:?]
at javax.json.bind.JsonbBuilder.create(JsonbBuilder.java:108) ~[?:?]
at org.microbule.jsonb.test.JsonbActivator.start(JsonbActivator.java:24)
~[?:?]
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
~[?:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2238) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) ~[?:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
at org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
~[?:?]
at
org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:62)
~[?:?]
... 14 more
In order to use Spi-Fly to load services, I think we need some bundles to
add the following MANIFEST.MF entries:
osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)"
osgi.serviceloader;
filter:="(osgi.serviceloader=javax.json.bind.spi.JsonbProvider)";cardinality:=multiple
However, even after adding that to my bundle (perhaps it needs to be on the
json.bind-api bundle instead), I still get the error.
On Sat, Jun 24, 2017 at 8:25 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Ok so just checked and all the cdi API usage is not mandatory at runtime so
> if loading fails it is skipped making it OSGi compatible updating metadata.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
>
> > Well, it looks like we appear to attempt to use reflection. The
> > BeanManager is typed as Object. However, the CDIs class has a hard
> > reference to the BeanManager class, so that goes right out the window. :(
> >
> >
> > On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Should be done by reflection - think we do for cdi 1.1 but we surefy
> > didnt
> > > for 1.0 - to detect it then we can have a cdi instance provider with
> the
> > > api being optional
> > >
> > > Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com> a
> > > écrit :
> > >
> > > > Unfortunately, the JohnzonBuilder class appears to use the CDI stuff
> > > > in-line. Merely marking it optional won't work I don't think (so
> much
> > > for
> > > > my PR). :(
> > > >
> > > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > We can just make it optional in the manifest. We shouldnt have cdi
> > > being
> > > > > mandatory even for the standalone case.
> > > > >
> > > > > Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com>
> a
> > > > > écrit :
> > > > >
> > > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
> > > > > >
> > > > > > Import-Package:
> > > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > > > > spi;version="[1.0,2)"...
> > > > > >
> > > > > > While it's nice that it supports CDI and all, I think that's too
> > > > > > heavy-handed for general purpose usage. I don't want to have to
> > load
> > > > up
> > > > > > CDI just to be able to load Johnzon into my OSGi container.
> > Perhaps
> > > we
> > > > > can
> > > > > > break the CDI support into a separate jar?
> > > > > >
> > > > > > James
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok so just checked and all the cdi API usage is not mandatory at runtime so
if loading fails it is skipped making it OSGi compatible updating metadata.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-24 14:18 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> Well, it looks like we appear to attempt to use reflection. The
> BeanManager is typed as Object. However, the CDIs class has a hard
> reference to the BeanManager class, so that goes right out the window. :(
>
>
> On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Should be done by reflection - think we do for cdi 1.1 but we surefy
> didnt
> > for 1.0 - to detect it then we can have a cdi instance provider with the
> > api being optional
> >
> > Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com> a
> > écrit :
> >
> > > Unfortunately, the JohnzonBuilder class appears to use the CDI stuff
> > > in-line. Merely marking it optional won't work I don't think (so much
> > for
> > > my PR). :(
> > >
> > > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > We can just make it optional in the manifest. We shouldnt have cdi
> > being
> > > > mandatory even for the standalone case.
> > > >
> > > > Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com> a
> > > > écrit :
> > > >
> > > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
> > > > >
> > > > > Import-Package:
> > > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > > > spi;version="[1.0,2)"...
> > > > >
> > > > > While it's nice that it supports CDI and all, I think that's too
> > > > > heavy-handed for general purpose usage. I don't want to have to
> load
> > > up
> > > > > CDI just to be able to load Johnzon into my OSGi container.
> Perhaps
> > we
> > > > can
> > > > > break the CDI support into a separate jar?
> > > > >
> > > > > James
> > > > >
> > > >
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by James Carman <ja...@carmanconsulting.com>.
Well, it looks like we appear to attempt to use reflection. The
BeanManager is typed as Object. However, the CDIs class has a hard
reference to the BeanManager class, so that goes right out the window. :(
On Sat, Jun 24, 2017 at 8:14 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Should be done by reflection - think we do for cdi 1.1 but we surefy didnt
> for 1.0 - to detect it then we can have a cdi instance provider with the
> api being optional
>
> Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com> a
> écrit :
>
> > Unfortunately, the JohnzonBuilder class appears to use the CDI stuff
> > in-line. Merely marking it optional won't work I don't think (so much
> for
> > my PR). :(
> >
> > On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > We can just make it optional in the manifest. We shouldnt have cdi
> being
> > > mandatory even for the standalone case.
> > >
> > > Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com> a
> > > écrit :
> > >
> > > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
> > > >
> > > > Import-Package:
> > > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > > spi;version="[1.0,2)"...
> > > >
> > > > While it's nice that it supports CDI and all, I think that's too
> > > > heavy-handed for general purpose usage. I don't want to have to load
> > up
> > > > CDI just to be able to load Johnzon into my OSGi container. Perhaps
> we
> > > can
> > > > break the CDI support into a separate jar?
> > > >
> > > > James
> > > >
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Should be done by reflection - think we do for cdi 1.1 but we surefy didnt
for 1.0 - to detect it then we can have a cdi instance provider with the
api being optional
Le 24 juin 2017 14:03, "James Carman" <ja...@carmanconsulting.com> a écrit :
> Unfortunately, the JohnzonBuilder class appears to use the CDI stuff
> in-line. Merely marking it optional won't work I don't think (so much for
> my PR). :(
>
> On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > We can just make it optional in the manifest. We shouldnt have cdi being
> > mandatory even for the standalone case.
> >
> > Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com> a
> > écrit :
> >
> > > I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
> > >
> > > Import-Package:
> > > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > > spi;version="[1.0,2)"...
> > >
> > > While it's nice that it supports CDI and all, I think that's too
> > > heavy-handed for general purpose usage. I don't want to have to load
> up
> > > CDI just to be able to load Johnzon into my OSGi container. Perhaps we
> > can
> > > break the CDI support into a separate jar?
> > >
> > > James
> > >
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by James Carman <ja...@carmanconsulting.com>.
Unfortunately, the JohnzonBuilder class appears to use the CDI stuff
in-line. Merely marking it optional won't work I don't think (so much for
my PR). :(
On Sat, Jun 24, 2017 at 3:21 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> We can just make it optional in the manifest. We shouldnt have cdi being
> mandatory even for the standalone case.
>
> Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com> a
> écrit :
>
> > I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
> >
> > Import-Package:
> > javax.enterprise.context.spi;version="[1.0,2)",javax.
> > enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> > spi;version="[1.0,2)"...
> >
> > While it's nice that it supports CDI and all, I think that's too
> > heavy-handed for general purpose usage. I don't want to have to load up
> > CDI just to be able to load Johnzon into my OSGi container. Perhaps we
> can
> > break the CDI support into a separate jar?
> >
> > James
> >
>
Re: Non-CDI johnzon-jsonb jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
We can just make it optional in the manifest. We shouldnt have cdi being
mandatory even for the standalone case.
Le 24 juin 2017 06:48, "James Carman" <ja...@carmanconsulting.com> a écrit :
> I noticed in the MANIFEST.MF file for johnzon-jsonb that we have:
>
> Import-Package:
> javax.enterprise.context.spi;version="[1.0,2)",javax.
> enterprise.event;version="[1.0,2)",javax.enterprise.inject.
> spi;version="[1.0,2)"...
>
> While it's nice that it supports CDI and all, I think that's too
> heavy-handed for general purpose usage. I don't want to have to load up
> CDI just to be able to load Johnzon into my OSGi container. Perhaps we can
> break the CDI support into a separate jar?
>
> James
>