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/> > > > > > > > > > > > >
