Re: Injection point for qualified points without @inject?
Well, it is not that I dont like it, I just dont see such a SPI once we have qualifier feature or what it would bring. Do you have an example? That said adding a service and extracting that code is not super costly but semantically/design-ly not sure how to defend it yet. Le mer. 8 mai 2019 à 20:41, Gerhard Petracek a écrit : > hi romain, > > it was just a hint - that there would be a chance to make owb even > more plugable and maybe to refactor an existing spi to an even more > useful spi. > i'm fine with it, if you don't like to take such a chance. the overall > use-case isn't that important to start a long/er discussion. > > regards, > gerhard > > > > Am Mo., 6. Mai 2019 um 23:24 Uhr schrieb Romain Manni-Bucau > : > > > > Le lun. 6 mai 2019 à 22:51, Gerhard Petracek a > > écrit : > > > > > my point was just to add a spi similar to the resource-injection spi... > > > or maybe we can even unify the spi for all types of injections. > > > > > > > Using qualifier - even through extensions - it does then so maybe we csn > > drop spi > > > > > > > regards, > > > gerhard > > > > > > > > > > > > Am Mo., 6. Mai 2019 um 20:43 Uhr schrieb Romain Manni-Bucau > > > : > > > > > > > > Well im happy with the spi option but since it would be in impl not > sure > > > we > > > > need to slow down the boot instead of hardcoding it. Or did you mean > in > > > > term of codepath but still bypassing service loader? > > > > > > > > Side note: we should align reflection on xbean which supports meta > > > > annotation and potentially aliasing, this is a bug between scanning > and > > > > runtime model we have today - see @Meta or @Metaroot support in > xbean. > > > That > > > > said it is another topic ;). > > > > > > > > Le lun. 6 mai 2019 à 15:45, Mark Struberg > a > > > > écrit : > > > > > > > > > Hmm, nah, too memory intense and slower than the other solution I'd > > > say. > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > Am 06.05.2019 um 14:41 schrieb Arne Limburg < > > > > > arne.limb...@openknowledge.de>: > > > > > > > > > > > > Hmm, > > > > > > thinking more of it: > > > > > > Shouldn't it be just an Extension that adds an @Inject > Annotation to > > > > > every Field and Method parameter that has a qualifier? > > > > > > > > > > > > Cheers, > > > > > > Arne > > > > > > > > > > > > -- > > > > > > Arne Limburg – Enterprise Architect > > > > > > > > > > > > > > > > > > > > > > > > OPEN KNOWLEDGE GmbH > > > > > > Poststraße 1, 26122 Oldenburg > > > > > > Mobil: +49 151 - 108 22 942 > > > > > > Tel: +49 441 - 4082-154 > > > > > > Fax: +49 441 - 4082-111 > > > > > > arne.limb...@openknowledge.de > > > > > > www.openknowledge.de > > > > > > > > > > > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > > > > > > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > > > > > > > > > > Nächste Konferenz: > > > > > > > > > > > > Java Forum Nord | Hannover | 24. September 2019 > > > > > > > > > > > > Nächste Akademie: > > > > > > > > > > > > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019 > > > > > > > > > > > > Treffen Sie uns auf weiteren Konferenzen, > > > > > > Summits und Events: > > > > > > > > > > > > Zu unseren weiteren Events > > > > > > > > > > > > > > > > > > > > > > > > Am 06.05.19, 14:06 schrieb "Gerhard Petracek" < > gpetra...@apache.org > > > >: > > > > > > > > > > > >hi romain, > > > > > > > > > > > >some years ago i tried to do something similar (afair with owb > > > 1.0.x) > > > > > >based on our plugin-spi. > > > > > >back then it was just possible via a plugin for > resource-injection > > > > > >(and it was a bit "tricky"). > > > > > >if nothing changed in the meantime, we should take the chance > to > > > add a > > > > > >more powerful injection-spi (to allow multiple plugins which > can > > > > > >participate in the "injection-lifecycle"). > > > > > >-> your approach would be one of many plugins users can add > (e.g. > > > with > > > > > >auto. activation...). > > > > > > > > > > > >regards, > > > > > >gerhard > > > > > > > > > > > >Am So., 5. Mai 2019 um 22:09 Uhr schrieb Romain Manni-Bucau > > > > > >: > > > > > >> > > > > > >> Good catch! > > > > > >> > > > > > >> If no objection i can push a first version like on friday I > think. > > > > > >> > > > > > >> Le dim. 5 mai 2019 à 21:58, Mark Struberg > > > > a > > > > > >> écrit : > > > > > >> > > > > > >>> And NO @Produces > > > > > >>> > > > > > >>> LieGrue, > > > > > >>> Strub > > > > > >>> > > > > > Am 05.05.2019 um 20:07 schrieb Arne Limburg < > > > > > >>> arne.limb...@openknowledge.de>: > > > > > > > > > > I > > > > > OPEN KNOWLEDGE GmbH > > > > > Poststraße 1, 26122 Oldenburg > > > > > Mobil: +49 151 - 108 22 942 > > > > > Tel: +49 441 - 4082-154 > > > > > Fax: +49 441 - 4082-111 > > > > > arne.limb...@openknowledge.de > > > > > www.openknowledge.de > > > > > > > > > >
Re: Injection point for qualified points without @inject?
hi romain, it was just a hint - that there would be a chance to make owb even more plugable and maybe to refactor an existing spi to an even more useful spi. i'm fine with it, if you don't like to take such a chance. the overall use-case isn't that important to start a long/er discussion. regards, gerhard Am Mo., 6. Mai 2019 um 23:24 Uhr schrieb Romain Manni-Bucau : > > Le lun. 6 mai 2019 à 22:51, Gerhard Petracek a > écrit : > > > my point was just to add a spi similar to the resource-injection spi... > > or maybe we can even unify the spi for all types of injections. > > > > Using qualifier - even through extensions - it does then so maybe we csn > drop spi > > > > regards, > > gerhard > > > > > > > > Am Mo., 6. Mai 2019 um 20:43 Uhr schrieb Romain Manni-Bucau > > : > > > > > > Well im happy with the spi option but since it would be in impl not sure > > we > > > need to slow down the boot instead of hardcoding it. Or did you mean in > > > term of codepath but still bypassing service loader? > > > > > > Side note: we should align reflection on xbean which supports meta > > > annotation and potentially aliasing, this is a bug between scanning and > > > runtime model we have today - see @Meta or @Metaroot support in xbean. > > That > > > said it is another topic ;). > > > > > > Le lun. 6 mai 2019 à 15:45, Mark Struberg a > > > écrit : > > > > > > > Hmm, nah, too memory intense and slower than the other solution I'd > > say. > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > Am 06.05.2019 um 14:41 schrieb Arne Limburg < > > > > arne.limb...@openknowledge.de>: > > > > > > > > > > Hmm, > > > > > thinking more of it: > > > > > Shouldn't it be just an Extension that adds an @Inject Annotation to > > > > every Field and Method parameter that has a qualifier? > > > > > > > > > > Cheers, > > > > > Arne > > > > > > > > > > -- > > > > > Arne Limburg – Enterprise Architect > > > > > > > > > > > > > > > > > > > > OPEN KNOWLEDGE GmbH > > > > > Poststraße 1, 26122 Oldenburg > > > > > Mobil: +49 151 - 108 22 942 > > > > > Tel: +49 441 - 4082-154 > > > > > Fax: +49 441 - 4082-111 > > > > > arne.limb...@openknowledge.de > > > > > www.openknowledge.de > > > > > > > > > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > > > > > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > > > > > > > > Nächste Konferenz: > > > > > > > > > > Java Forum Nord | Hannover | 24. September 2019 > > > > > > > > > > Nächste Akademie: > > > > > > > > > > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019 > > > > > > > > > > Treffen Sie uns auf weiteren Konferenzen, > > > > > Summits und Events: > > > > > > > > > > Zu unseren weiteren Events > > > > > > > > > > > > > > > > > > > > Am 06.05.19, 14:06 schrieb "Gerhard Petracek" > >: > > > > > > > > > >hi romain, > > > > > > > > > >some years ago i tried to do something similar (afair with owb > > 1.0.x) > > > > >based on our plugin-spi. > > > > >back then it was just possible via a plugin for resource-injection > > > > >(and it was a bit "tricky"). > > > > >if nothing changed in the meantime, we should take the chance to > > add a > > > > >more powerful injection-spi (to allow multiple plugins which can > > > > >participate in the "injection-lifecycle"). > > > > >-> your approach would be one of many plugins users can add (e.g. > > with > > > > >auto. activation...). > > > > > > > > > >regards, > > > > >gerhard > > > > > > > > > >Am So., 5. Mai 2019 um 22:09 Uhr schrieb Romain Manni-Bucau > > > > >: > > > > >> > > > > >> Good catch! > > > > >> > > > > >> If no objection i can push a first version like on friday I think. > > > > >> > > > > >> Le dim. 5 mai 2019 à 21:58, Mark Struberg > > a > > > > >> écrit : > > > > >> > > > > >>> And NO @Produces > > > > >>> > > > > >>> LieGrue, > > > > >>> Strub > > > > >>> > > > > Am 05.05.2019 um 20:07 schrieb Arne Limburg < > > > > >>> arne.limb...@openknowledge.de>: > > > > > > > > I > > > > OPEN KNOWLEDGE GmbH > > > > Poststraße 1, 26122 Oldenburg > > > > Mobil: +49 151 - 108 22 942 > > > > Tel: +49 441 - 4082-154 > > > > Fax: +49 441 - 4082-111 > > > > arne.limb...@openknowledge.de > > > > www.openknowledge.de > > > > > > > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > > > > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > > > > > > Nächste Konferenz: > > > > > > > > Jax | Mainz | 6. - 10. Mai 2019 > > > > > > > > Nächste Akademie: > > > > > > > > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019 > > > > > > > > Treffen Sie uns auf weiteren Konferenzen, > > > > Summits und Events: > > > > > > > > Zu unseren weiteren Events > > > > > > > > > > > > > > > > am fine with that. I even thought of that before, when I wanted > > to add > > > > >>> @PersistenceContext as qualifier to implement
Re: javax vs. jakarta
Please dont branch - except in sandbox mode - before the sed option is
right, in terms of maintenance this is not what we want and we always
failed synching branches properly in most ee project but tomcat which does
it very right.
Le mer. 8 mai 2019 à 18:13, Arne Limburg a
écrit :
> Oh yes, in JSF it would be hard to support both, because there is so much
> impl in the spec.
> But JSF is a good example where it isn't needed.
>
> In the the JSF applications I know there are not much javax.faces imports,
> probably only Converters and Validators.
> It's getting hard when it comes to custom components.
>
> Probably for JSF-implementations it would not be a good idea to support
> both packages.
> So there may be different strategies for impls of different specs.
>
> --
> Arne Limburg – Enterprise Architect
>
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Nächste Konferenz:
>
> Java Forum Nord | Hannover | 24. September 2019
>
> Nächste Akademie:
>
> API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
>
> Treffen Sie uns auf weiteren Konferenzen,
> Summits und Events:
>
> Zu unseren weiteren Events
>
>
>
> Am 08.05.19, 18:04 schrieb "Thomas Andraschko" <
> andraschko.tho...@gmail.com>:
>
> Not sure about OWB but MyFaces would be alot of work or even not
> possible.
> So hopefully no impl >must< support both
>
> Arne Limburg schrieb am Mi., 8. Mai
> 2019,
> 17:48:
>
> > Mark,
> >
> > I'll take your branch and check, how much effort it would be to
> support
> > both packages at the same time.
> >
> > --
> > Arne Limburg – Enterprise Architect
> >
> >
> >
> > OPEN KNOWLEDGE GmbH
> > Poststraße 1, 26122 Oldenburg
> > Mobil: +49 151 - 108 22 942
> > Tel: +49 441 - 4082-154
> > Fax: +49 441 - 4082-111
> > arne.limb...@openknowledge.de
> > www.openknowledge.de
> >
> > Registergericht: Amtsgericht Oldenburg, HRB 4670
> > Geschäftsführer: Lars Röwekamp, Jens Schumann
> >
> > Nächste Konferenz:
> >
> > Java Forum Nord | Hannover | 24. September 2019
> >
> > Nächste Akademie:
> >
> > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
> >
> > Treffen Sie uns auf weiteren Konferenzen,
> > Summits und Events:
> >
> > Zu unseren weiteren Events
> >
> >
> >
> > Am 08.05.19, 17:38 schrieb "Mark Struberg" >:
> >
> > I'd say we do branches and continue with jakarta.*.
> > The current OWB release is very stable and fast. So I don't
> expect
> > many changes.
> >
> >
> >
> >
> https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
> >
> > Done that on last friday already :)
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 08.05.2019 um 14:21 schrieb Arne Limburg <
> > arne.limb...@openknowledge.de>:
> > >
> > > Hi all,
> > >
> > > Being at the JAX conference now, I am quite oftenly confronted
> with
> > the javax vs. Jakarta discussion.
> > > Besides that it is not clear how to handle that at the API
> level
> > (btw. Good blog entries, David and Mark), I am thinking of how it
> could be
> > handled at implementation level.
> > > My preferred solution would be the complete separation of Java
> EE
> > APIs (with javax packages) and Jakarta EE APIs (with jakarta
> packages)
> > > and having the implementation support both. The question is,
> are we
> > able to handle this without much code change?
> > >
> > > My first idea was to define an own set of interfaces like
> > > public interface Bean extends
> > javax.enterprise.inject.spi.Bean,
> jakarta.enterprise.inject.spi.Bean {
> > > …
> > > }
> > > We could then use this interface as return value for or
> interfaces
> > whereever Bean is the return value in specification interfaces.
> > >
> > > The only problem I see with this approach seems to be with
> > Collection return values and generics, i.e.
> > javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> > Set and
> > jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return
> a
> > Set. In an ideal world
> our
> > common interface would return a
> Set
> > where org.apache.openwebbeans.InjectionPoint extends the other
> > InjectionPoints. But that does not work for generics.
> > > Regarding parameters the solution would be to have both
> methods and
> > call one from the other, wrapping the parameter,
Re: javax vs. jakarta
Oh yes, in JSF it would be hard to support both, because there is so much impl
in the spec.
But JSF is a good example where it isn't needed.
In the the JSF applications I know there are not much javax.faces imports,
probably only Converters and Validators.
It's getting hard when it comes to custom components.
Probably for JSF-implementations it would not be a good idea to support both
packages.
So there may be different strategies for impls of different specs.
--
Arne Limburg – Enterprise Architect
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limb...@openknowledge.de
www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Nächste Konferenz:
Java Forum Nord | Hannover | 24. September 2019
Nächste Akademie:
API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
Treffen Sie uns auf weiteren Konferenzen,
Summits und Events:
Zu unseren weiteren Events
Am 08.05.19, 18:04 schrieb "Thomas Andraschko" :
Not sure about OWB but MyFaces would be alot of work or even not possible.
So hopefully no impl >must< support both
Arne Limburg schrieb am Mi., 8. Mai 2019,
17:48:
> Mark,
>
> I'll take your branch and check, how much effort it would be to support
> both packages at the same time.
>
> --
> Arne Limburg – Enterprise Architect
>
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Nächste Konferenz:
>
> Java Forum Nord | Hannover | 24. September 2019
>
> Nächste Akademie:
>
> API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
>
> Treffen Sie uns auf weiteren Konferenzen,
> Summits und Events:
>
> Zu unseren weiteren Events
>
>
>
> Am 08.05.19, 17:38 schrieb "Mark Struberg" :
>
> I'd say we do branches and continue with jakarta.*.
> The current OWB release is very stable and fast. So I don't expect
> many changes.
>
>
>
>
https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
>
> Done that on last friday already :)
>
> LieGrue,
> strub
>
>
>
> > Am 08.05.2019 um 14:21 schrieb Arne Limburg <
> arne.limb...@openknowledge.de>:
> >
> > Hi all,
> >
> > Being at the JAX conference now, I am quite oftenly confronted with
> the javax vs. Jakarta discussion.
> > Besides that it is not clear how to handle that at the API level
> (btw. Good blog entries, David and Mark), I am thinking of how it could be
> handled at implementation level.
> > My preferred solution would be the complete separation of Java EE
> APIs (with javax packages) and Jakarta EE APIs (with jakarta packages)
> > and having the implementation support both. The question is, are we
> able to handle this without much code change?
> >
> > My first idea was to define an own set of interfaces like
> > public interface Bean extends
> javax.enterprise.inject.spi.Bean,
jakarta.enterprise.inject.spi.Bean {
> > …
> > }
> > We could then use this interface as return value for or interfaces
> whereever Bean is the return value in specification interfaces.
> >
> > The only problem I see with this approach seems to be with
> Collection return values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set. In an ideal world our
> common interface would return a
Set
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> > Regarding parameters the solution would be to have both methods and
> call one from the other, wrapping the parameter, which most probably
should
> work out.
> >
> > Any ideas/opinions on that?
> >
> > Cheers,
> > Arne
> >
> > --
> > Arne Limburg – Enterprise Architect
> >
> >
> > OPEN KNOWLEDGE GmbH
> > Poststraße 1, 26122 Oldenburg
> > Mobil: +49 151 - 108 22 942
> > Tel: +49 441 - 4082-154
> > Fax: +49 441 - 4082-111
> > arne.limb...@openknowledge.de
> > www.openknowledge.de
Re: javax vs. jakarta
Not sure about OWB but MyFaces would be alot of work or even not possible.
So hopefully no impl >must< support both
Arne Limburg schrieb am Mi., 8. Mai 2019,
17:48:
> Mark,
>
> I'll take your branch and check, how much effort it would be to support
> both packages at the same time.
>
> --
> Arne Limburg – Enterprise Architect
>
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Nächste Konferenz:
>
> Java Forum Nord | Hannover | 24. September 2019
>
> Nächste Akademie:
>
> API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
>
> Treffen Sie uns auf weiteren Konferenzen,
> Summits und Events:
>
> Zu unseren weiteren Events
>
>
>
> Am 08.05.19, 17:38 schrieb "Mark Struberg" :
>
> I'd say we do branches and continue with jakarta.*.
> The current OWB release is very stable and fast. So I don't expect
> many changes.
>
>
>
> https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
>
> Done that on last friday already :)
>
> LieGrue,
> strub
>
>
>
> > Am 08.05.2019 um 14:21 schrieb Arne Limburg <
> arne.limb...@openknowledge.de>:
> >
> > Hi all,
> >
> > Being at the JAX conference now, I am quite oftenly confronted with
> the javax vs. Jakarta discussion.
> > Besides that it is not clear how to handle that at the API level
> (btw. Good blog entries, David and Mark), I am thinking of how it could be
> handled at implementation level.
> > My preferred solution would be the complete separation of Java EE
> APIs (with javax packages) and Jakarta EE APIs (with jakarta packages)
> > and having the implementation support both. The question is, are we
> able to handle this without much code change?
> >
> > My first idea was to define an own set of interfaces like
> > public interface Bean extends
> javax.enterprise.inject.spi.Bean, jakarta.enterprise.inject.spi.Bean {
> > …
> > }
> > We could then use this interface as return value for or interfaces
> whereever Bean is the return value in specification interfaces.
> >
> > The only problem I see with this approach seems to be with
> Collection return values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set. In an ideal world our
> common interface would return a Set
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> > Regarding parameters the solution would be to have both methods and
> call one from the other, wrapping the parameter, which most probably should
> work out.
> >
> > Any ideas/opinions on that?
> >
> > Cheers,
> > Arne
> >
> > --
> > Arne Limburg – Enterprise Architect
> >
> >
> > OPEN KNOWLEDGE GmbH
> > Poststraße 1, 26122 Oldenburg
> > Mobil: +49 151 - 108 22 942
> > Tel: +49 441 - 4082-154
> > Fax: +49 441 - 4082-111
> > arne.limb...@openknowledge.de
> > www.openknowledge.de
Re: javax vs. jakarta
Mark,
I'll take your branch and check, how much effort it would be to support both
packages at the same time.
--
Arne Limburg – Enterprise Architect
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limb...@openknowledge.de
www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Nächste Konferenz:
Java Forum Nord | Hannover | 24. September 2019
Nächste Akademie:
API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
Treffen Sie uns auf weiteren Konferenzen,
Summits und Events:
Zu unseren weiteren Events
Am 08.05.19, 17:38 schrieb "Mark Struberg" :
I'd say we do branches and continue with jakarta.*.
The current OWB release is very stable and fast. So I don't expect many
changes.
https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
Done that on last friday already :)
LieGrue,
strub
> Am 08.05.2019 um 14:21 schrieb Arne Limburg
:
>
> Hi all,
>
> Being at the JAX conference now, I am quite oftenly confronted with the
javax vs. Jakarta discussion.
> Besides that it is not clear how to handle that at the API level (btw.
Good blog entries, David and Mark), I am thinking of how it could be handled at
implementation level.
> My preferred solution would be the complete separation of Java EE APIs
(with javax packages) and Jakarta EE APIs (with jakarta packages)
> and having the implementation support both. The question is, are we able
to handle this without much code change?
>
> My first idea was to define an own set of interfaces like
> public interface Bean extends javax.enterprise.inject.spi.Bean,
jakarta.enterprise.inject.spi.Bean {
> …
> }
> We could then use this interface as return value for or interfaces
whereever Bean is the return value in specification interfaces.
>
> The only problem I see with this approach seems to be with Collection
return values and generics, i.e.
javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
Set and
jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
Set. In an ideal world our common
interface would return a Set where
org.apache.openwebbeans.InjectionPoint extends the other InjectionPoints. But
that does not work for generics.
> Regarding parameters the solution would be to have both methods and call
one from the other, wrapping the parameter, which most probably should work out.
>
> Any ideas/opinions on that?
>
> Cheers,
> Arne
>
> --
> Arne Limburg – Enterprise Architect
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
Re: javax vs. jakarta
You are right, that we don't need to do anything. But thinking about the
possibilities of the implementations maybe can give a good input to the API
discussion.
When we would come to the conclusion that it would be no problem for any
Java-EE-Implementation to support both package names at the same time,
the discussion would probably go into another direction.
IF every implementation could support both packages without much effort it
probably would be the cleanest way for both users and implementors to
completely separate both APIs. The old code would keep on working and users
could migrate whenever they want, at least since they want to use new features.
But maybe is CDI the wrong example to explore that, because on the one hand
there will be no new spec version in the short future and on the other hand it
is mainly interface- and annotation-based. So probably it would be easier for
CDI implementations to support both packages than for other implementations.
Cheers,
Arne
--
Arne Limburg – Enterprise Architect
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limb...@openknowledge.de
www.openknowledge.de
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Nächste Konferenz:
Java Forum Nord | Hannover | 24. September 2019
Nächste Akademie:
API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
Treffen Sie uns auf weiteren Konferenzen,
Summits und Events:
Zu unseren weiteren Events
Am 08.05.19, 14:47 schrieb "Romain Manni-Bucau" :
Personally i would expect a kind of proxy based impl since CDI is mostly
interface based so it would always work and enable to switch between models
when needed.
Now I also dont expect we do it before CDI 3 arrives which can be never -
we dont know today.
So do we need anything? Probably not.
Probably let's wait we clarify clearly the status before doing anything.
Today the "vs" sounds emotionnal to me because the option to enrich javax
is still valid and the sanest for users and the community (what would mean
the first message of jakarta being "we drop everything" whereas goal is
long term investment at the end).
Le mer. 8 mai 2019 à 14:21, Arne Limburg a
écrit :
> Hi all,
>
> Being at the JAX conference now, I am quite oftenly confronted with the
> javax vs. Jakarta discussion.
> Besides that it is not clear how to handle that at the API level (btw.
> Good blog entries, David and Mark), I am thinking of how it could be
> handled at implementation level.
> My preferred solution would be the complete separation of Java EE APIs
> (with javax packages) and Jakarta EE APIs (with jakarta packages)
> and having the implementation support both. The question is, are we able
> to handle this without much code change?
>
> My first idea was to define an own set of interfaces like
> public interface Bean extends javax.enterprise.inject.spi.Bean,
> jakarta.enterprise.inject.spi.Bean {
>…
> }
> We could then use this interface as return value for or interfaces
> whereever Bean is the return value in specification interfaces.
>
> The only problem I see with this approach seems to be with Collection
> return values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set. In an ideal world our
> common interface would return a
Set
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> Regarding parameters the solution would be to have both methods and call
> one from the other, wrapping the parameter, which most probably should
work
> out.
>
> Any ideas/opinions on that?
>
> Cheers,
> Arne
>
> --
> Arne Limburg – Enterprise Architect
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
Re: javax vs. jakarta
I'd say we do branches and continue with jakarta.*.
The current OWB release is very stable and fast. So I don't expect many changes.
https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
Done that on last friday already :)
LieGrue,
strub
> Am 08.05.2019 um 14:21 schrieb Arne Limburg :
>
> Hi all,
>
> Being at the JAX conference now, I am quite oftenly confronted with the javax
> vs. Jakarta discussion.
> Besides that it is not clear how to handle that at the API level (btw. Good
> blog entries, David and Mark), I am thinking of how it could be handled at
> implementation level.
> My preferred solution would be the complete separation of Java EE APIs (with
> javax packages) and Jakarta EE APIs (with jakarta packages)
> and having the implementation support both. The question is, are we able to
> handle this without much code change?
>
> My first idea was to define an own set of interfaces like
> public interface Bean extends javax.enterprise.inject.spi.Bean,
> jakarta.enterprise.inject.spi.Bean {
> …
> }
> We could then use this interface as return value for or interfaces whereever
> Bean is the return value in specification interfaces.
>
> The only problem I see with this approach seems to be with Collection return
> values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set. In an ideal world our
> common interface would return a Set
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> Regarding parameters the solution would be to have both methods and call one
> from the other, wrapping the parameter, which most probably should work out.
>
> Any ideas/opinions on that?
>
> Cheers,
> Arne
>
> --
> Arne Limburg – Enterprise Architect
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
Re: javax vs. jakarta
Personally i would expect a kind of proxy based impl since CDI is mostly
interface based so it would always work and enable to switch between models
when needed.
Now I also dont expect we do it before CDI 3 arrives which can be never -
we dont know today.
So do we need anything? Probably not.
Probably let's wait we clarify clearly the status before doing anything.
Today the "vs" sounds emotionnal to me because the option to enrich javax
is still valid and the sanest for users and the community (what would mean
the first message of jakarta being "we drop everything" whereas goal is
long term investment at the end).
Le mer. 8 mai 2019 à 14:21, Arne Limburg a
écrit :
> Hi all,
>
> Being at the JAX conference now, I am quite oftenly confronted with the
> javax vs. Jakarta discussion.
> Besides that it is not clear how to handle that at the API level (btw.
> Good blog entries, David and Mark), I am thinking of how it could be
> handled at implementation level.
> My preferred solution would be the complete separation of Java EE APIs
> (with javax packages) and Jakarta EE APIs (with jakarta packages)
> and having the implementation support both. The question is, are we able
> to handle this without much code change?
>
> My first idea was to define an own set of interfaces like
> public interface Bean extends javax.enterprise.inject.spi.Bean,
> jakarta.enterprise.inject.spi.Bean {
>…
> }
> We could then use this interface as return value for or interfaces
> whereever Bean is the return value in specification interfaces.
>
> The only problem I see with this approach seems to be with Collection
> return values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set. In an ideal world our
> common interface would return a Set
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> Regarding parameters the solution would be to have both methods and call
> one from the other, wrapping the parameter, which most probably should work
> out.
>
> Any ideas/opinions on that?
>
> Cheers,
> Arne
>
> --
> Arne Limburg – Enterprise Architect
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de
javax vs. jakarta
Hi all,
Being at the JAX conference now, I am quite oftenly confronted with the javax
vs. Jakarta discussion.
Besides that it is not clear how to handle that at the API level (btw. Good
blog entries, David and Mark), I am thinking of how it could be handled at
implementation level.
My preferred solution would be the complete separation of Java EE APIs (with
javax packages) and Jakarta EE APIs (with jakarta packages)
and having the implementation support both. The question is, are we able to
handle this without much code change?
My first idea was to define an own set of interfaces like
public interface Bean extends javax.enterprise.inject.spi.Bean,
jakarta.enterprise.inject.spi.Bean {
…
}
We could then use this interface as return value for or interfaces whereever
Bean is the return value in specification interfaces.
The only problem I see with this approach seems to be with Collection return
values and generics, i.e. javax.enterprise.inject.spi.Bean#getInjectionPoints()
returns a Set and
jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
Set. In an ideal world our common
interface would return a Set where
org.apache.openwebbeans.InjectionPoint extends the other InjectionPoints. But
that does not work for generics.
Regarding parameters the solution would be to have both methods and call one
from the other, wrapping the parameter, which most probably should work out.
Any ideas/opinions on that?
Cheers,
Arne
--
Arne Limburg – Enterprise Architect
OPEN KNOWLEDGE GmbH
Poststraße 1, 26122 Oldenburg
Mobil: +49 151 - 108 22 942
Tel: +49 441 - 4082-154
Fax: +49 441 - 4082-111
arne.limb...@openknowledge.de
www.openknowledge.de
