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 <arne.limb...@openknowledge.de> 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" <strub...@yahoo.de.INVALID>:
>
> 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<T> extends
> javax.enterprise.inject.spi.Bean<T>,
jakarta.enterprise.inject.spi.Bean<T> {
> > …
> > }
> > 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<javax.enterprise.inject.spi.InjectionPoint> and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set<jakarta.enterprise.inject.spi.InjectionPoint>. In an ideal world our
> common interface would return a
Set<org.apache.openwebbeans.InjectionPoint>
> 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 <https://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 <
> https://www.openknowledge.de/event/java-forum-nord/>
> >
> > Nächste Akademie:
> >
> > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019<
> https://www.openknowledge.de/event/at-api-und-microservises-summit/>
> >
> > Treffen Sie uns auf weiteren Konferenzen,
> > Summits und Events:
> >
> > Zu unseren weiteren Events<https://www.openknowledge.de/event/>
> >
> >
> >
> >
>
>
>
>
