Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Not fighting, just for the benefits of the both tomcat and owb, this is
duplicate effort both in owb and tomcat.

if you feel the best to stay in owb, no problem but I thought that if it is
in tomcat, it is natural to download via tomcat, no need to have
configration,  more community, and do more innovation with more users

And also I am not sure that tomcat community will accept that proposal :)



On 1 Jul 2020 Wed at 14:53 Romain Manni-Bucau  wrote:

> This module has some users - don't know if tomcat-owb has, maybe Rémy you
> have some insights?  - but these last years we got most users moving to
> tomee or meecrowave cause it is better integrated, ready to run and has
> modern flavors (embedded vs standalone tomcat) enabling modern deployments
> (thinking strongly to k8s + CDS).
> Only remaining case is bare metal tomcat where tomee takes most users these
> days because it is well tooled - maven, gradle and testing. So at the end
> this module is mainly for historical advanced users.
> Concretely this module has ~300 downloads/month (to compare to the 20k of
> owb-impl module).
>
> In any case, I don't think Tomcat will not promote CDI and any CDI/OWB
> support will likely be redirected here at some point so moving is an
> useless indirection.
> Also why Tomcat is so popular is that it is a servlet container (a bit more
> but just to share the idea), so it is used by everyone, if you get more you
> will get the exact same issue than with a full EE container: "it is too
> much for me, let's grab something else".
> Microprofile proves that: it does not even need a servlet layer at all
> theoretically.
> In that regard TomEE would be a better home but it is not the goal of the
> project to do this light integration today - and we have a few alternative
> at apache.
> It is also highly consistent with meecrowave to have @owb. While we
> maintain meecrowave we maintain this module sounds like a very fair
> assumption.
>
> @Gurkan Erdogdu  can you clarify why you fight so
> strongly to drop that module we own since years and not jetty one for
> example? I totally fail to see the point.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 1 juil. 2020 à 13:03, Gurkan Erdogdu  a
> écrit :
>
> > All other specs at the moment consumes or will consume CDI core. Even if
> > not, it must be. CDI is somebit different from other specs (especially I
> am
> > talking about the injection part) and now your observation may not be
> true
> > anymore. (As you said CDI consumes servlet but not the other way).
> >
> > I am not agree with that when Tomcat embeds CDI , it also support EJB,
> > Security etc. No, it is not .
> >
> > Who currently uses our tomcat7 module? Do you know its popularity? I
> > suspect that is large enough community on this. I started to wrote this
> > tomcat7 module years years ago because, CDI is not in the same state as
> it
> > is currently.
> >
> > But within Tomcat, it can reach and develop further community. One can
> use
> > Tomcat without external configration and update (like owb did) and on top
> > of that they can extend Tomcat naturally. With single download of Tomcat,
> > you also get fantastic CDI platform.
> >
> >  I think this is really a great idea.
> >
> > Gurkan
> >
> > On 1 Jul 2020 Wed at 13:35 Mark Struberg 
> > wrote:
> >
> > > As long as Tomcat doesn't release the integration as part of their core
> > > build we can stop the whole discussion!
> > >
> > > -1 on dropping webbeans-tomcat7
> > >
> > >
> > > Once there is a good alternative in the main build in tomcat we can
> > > discuss this again.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > > Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > >> CDI is the core spec for all other Jakarta EE specifications. I
> really
> > > dont
> > > >> know why Tomcat does not include it naturally. I think the home
> > > >> fo

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

All other specs at the moment consumes or will consume CDI core. Even if
not, it must be. CDI is somebit different from other specs (especially I am
talking about the injection part) and now your observation may not be true
anymore. (As you said CDI consumes servlet but not the other way).

I am not agree with that when Tomcat embeds CDI , it also support EJB,
Security etc. No, it is not .

Who currently uses our tomcat7 module? Do you know its popularity? I
suspect that is large enough community on this. I started to wrote this
tomcat7 module years years ago because, CDI is not in the same state as it
is currently.

But within Tomcat, it can reach and develop further community. One can use
Tomcat without external configration and update (like owb did) and on top
of that they can extend Tomcat naturally. With single download of Tomcat,
you also get fantastic CDI platform.

 I think this is really a great idea.

Gurkan

On 1 Jul 2020 Wed at 13:35 Mark Struberg  wrote:

> As long as Tomcat doesn't release the integration as part of their core
> build we can stop the whole discussion!
>
> -1 on dropping webbeans-tomcat7
>
>
> Once there is a good alternative in the main build in tomcat we can
> discuss this again.
>
> LieGrue,
> strub
>
>
>
> > Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau  >:
> >
> > Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu 
> a
> > écrit :
> >
> >> CDI is the core spec for all other Jakarta EE specifications. I really
> dont
> >> know why Tomcat does not include it naturally. I think the home
> >> for such natural integration will be Tomcat. But, not under the modules,
> >> but integrated into the Tomcat core and release monthyl with Tomcat
> release
> >>
> >
> > Nop, EE always built each spec independently of the IoC - which is wrong
> I
> > agree but it is what has been done and why you have at least 5 concurrent
> > IoC in EE.
> > If we follow your reasoning, tomcat should also include EJB, JAXRS,
> > javax.security etc, not sure it would be sane and you just move the issue
> > which is that once you trivially integrated servlet+cdi you must
> integrate
> > servlet+cdi+security, then +jaxrs etc (Pareto law applies well there).
> > So at the end, CDI is based on servlet spec - since it is spec-ed like
> that
> > cause servlet spec rejected CDI integration at that time - then CDI is
> > built on top on tomcat and not the opposite and in terms of build
> > dependency, OWB consumes servlet spec, not the opposite so strictly
> > speaking it is more logical to keep it in OWB.
> > Lastly you still ignore that we integrate with jetty too and if we keep
> > jetty we must keep tomcat for consistency of our deliveries and user
> facing
> > artifacts so IMHO there is no need to only do half of the discussion
> which
> > can only lead to half a decision which means it would not be applicable
> at
> > the end IMHO.
> >
> >
> >>
> >> Remy,
> >> Is it possible to open a discussion in tomcat dev list to discuss more
> on
> >> this topic?
> >>
> >> Gurkan
> >>
> >> On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau 
> >> wrote:
> >>
> >>> Hmm, sounds close to what we deliver (
> >>> http://openwebbeans.apache.org/owbsetup_tomcat.html ).
> >>> I agree we Gurkan we should be able to converge but today I don't see
> why
> >>> Tomcat is a saner home, factually it is worse since it is not ready to
> >> use
> >>> for end user compared to owb distro and fact it is in tomcat/modules is
> >> not
> >>> that encouraging to me (and I assume tomcat will not release it in its
> >>> monthly release, right?).
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>
> >>>
> >>>
> >>> Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu  >
> >> a
> >>> écrit :
> >>>
> >>>> Thanks Remy.
> >>>> Is it possible to merge these 2 efforts to single one under Tomcat
> >>> coebase?
> >>>> I dont see any reason to maintain two different imp

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

CDI is the core spec for all other Jakarta EE specifications. I really dont
know why Tomcat does not include it naturally. I think the home
for such natural integration will be Tomcat. But, not under the modules,
but integrated into the Tomcat core and release monthyl with Tomcat release

Remy,
Is it possible to open a discussion in tomcat dev list to discuss more on
this topic?

Gurkan

On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau  wrote:

> Hmm, sounds close to what we deliver (
> http://openwebbeans.apache.org/owbsetup_tomcat.html ).
> I agree we Gurkan we should be able to converge but today I don't see why
> Tomcat is a saner home, factually it is worse since it is not ready to use
> for end user compared to owb distro and fact it is in tomcat/modules is not
> that encouraging to me (and I assume tomcat will not release it in its
> monthly release, right?).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu  a
> écrit :
>
> > Thanks Remy.
> > Is it possible to merge these 2 efforts to single one under Tomcat
> coebase?
> > I dont see any reason to maintain two different implementation with the
> > same aim
> >
> >
> >
> > On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
> >
> > > On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com>
> > > wrote:
> > >
> > > > Sorry but not understand why both Tomcat and OWB doing the same think
> > > with
> > > > nearly same classes
> > > >
> > > > @Remy
> > > > Just wonder why did you introduce such a module in tomcat modules? Do
> > you
> > > > have any specific purpose?
> > > >
> > >
> > > The idea is to provide a different packaging, with specific easy to
> > follow
> > > instructions that allow adding CDI support to the Tomcat container.
> > >
> > > Rémy
> > >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Thanks Remy.
Is it possible to merge these 2 efforts to single one under Tomcat coebase?
I dont see any reason to maintain two different implementation with the
same aim



On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:

> On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu 
> wrote:
>
> > Sorry but not understand why both Tomcat and OWB doing the same think
> with
> > nearly same classes
> >
> > @Remy
> > Just wonder why did you introduce such a module in tomcat modules? Do you
> > have any specific purpose?
> >
>
> The idea is to provide a different packaging, with specific easy to follow
> instructions that allow adding CDI support to the Tomcat container.
>
> Rémy
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Sorry but not understand why both Tomcat and OWB doing the same think with
nearly same classes

@Remy
Just wonder why did you introduce such a module in tomcat modules? Do you
have any specific purpose?



On 30 Jun 2020 Tue at 11:24 Romain Manni-Bucau 
wrote:

> Hmm, I'm not following, spoke of websockets, not async requests and as an
> user I expect a tomcat-owb integration module to make both working together
> otherwise it is pointless to have an integration module not integrating
> technologies.
> Now the spec mentions it is supported in an EE world - we are not there but
> I guess we should be consistent with it in such a module:
>
> https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class-
>
> I suspect tomcat could use by itself the instance manager to avoid this
> integration need but then it would leak the "release" call - it must be
> compensated by another mechanism since the websocket spec does not give it.
>
> Anyway, we can open a new thread on the impl, didn't intend to hijack this
> one.
>
> Le mar. 30 juin 2020 à 09:59, Mark Struberg  a
> écrit :
>
> > It means we support @RequestScoped and ApplicationScoped beans in Async
> > Requests and events as required by the spec.
> >
> > The rest is afaik not portable.
> >
> > Happy to be proven wrong ;)
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > If does support means you can write websocket code, sure.
> > > If it means "works with cdi beans" then I think we miss this class:
> > >
> >
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 30 juin 2020 à 09:29, Mark Struberg  >
> > a
> > > écrit :
> > >
> > >> our tomcat integration does support websockets afair.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >>> :
> > >>>
> > >>> @Gurkan Erdogdu   the first reason to keep
> > >> tomcat
> > >>> module is that we release it whereas o.a.tomcat:tomcat-owb does not
> > exist
> > >>> for end users today ("you can build from source" is not an option
> IMHO
> > >> and
> > >>> justifies to fork in most cases). The main difference in terms of
> code
> > is
> > >>> the fact tomcat integration provides a valve for the principal
> whereas
> > we
> > >>> only use a filter but I guess it is enough since valve will prevent
> to
> > >>> position the filter - = capture of the principal - in the filter
> chain
> > >> and
> > >>> can therefore break apps even if it is tempting to make it always win
> > (we
> > >>> shouldn't use a thread local but we don't have much options there).
> > Both
> > >>> impl miss websocket integration - tomee has it - so it looks like
> > >>> tomcat-owb is a fork of our module today, not much so release point
> is
> > a
> > >>> blocker for me.
> > >>>
> > >>> With jakarta I guess we can maybe ask tomcat+jetty to get an official
> > >>> servlet components injections and drop all specific code.
> > >>>
> > >>> Last point about the consistency for jetty AND tomcat is also key for
> > me,
> > >>> there is no reason to favor jetty and not tomcat.
> > >>>
> > >>> +1 to drop the version from the module though, it does not make sense
> > >>> anymore - was for 6 -> 7 move IIRC.
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >>>

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Hi Remy

> I would think you should keep "tomcat7" too, it's not really the same idea
> as modules/owb.
>
I have looked at both implementations and both are the same purpose,
injection into  Servlet related classes and get the current Principal from
the request. In Tomcat/OWB module, its integration is more natural than the
Tomcat7 module.
What is the benefit of using Tomcat7 in OWB?
Regards.
Gurkan


On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat  wrote:

> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau 
> wrote:
>
> > +1 to drop jms module, never saw any usage of it
> > -0.5 for tomcat7, rational being that if we want to do it, we should (at
> > the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> > think) + released properly and not just a sandbox and 2. drop jetty
> > integration too (which can be envisioned since we worked to integrate OWB
> > in jetty itself) but dropping tomcat7 module without these two conditions
> > looks like an user regression to me.
> >
>
> I would think you should keep "tomcat7" too, it's not really the same idea
> as modules/owb. The main problem is using a version number in the module
> name, that creates confusion in the long run and gives the impression it is
> outdated. Tomcat 7 will be eoled "soon", for example.
>
> Rémy
>
>
> >
> > I guess ee modules can move to tomee too - any other consumer - with the
> > relevant adaptations to our codebase?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > Hi folks
> > > I would like to discuss to remove the following modules from the OWB
> code
> > > base.
> > >
> > >- webbeans-jms : We introduced this module years ago for JMS but
> > frankly
> > >never see any usage. Also, it was not completed.
> > >    - webbeans-tomcat7 : We introduced this modules for Tomcat7
> > integration
> > >but now it is useless and Tomcat already includes this integration
> > with
> > >more natural way (
> > >https://github.com/apache/tomcat/tree/master/modules/owb)
> > >
> > > WDYT? Any objection?
> > > Regards.
> > > Gurkan
> > >
> >
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Remove of Useless Maven Projects

[Gurkan Erdogdu]

Hi folks
I would like to discuss to remove the following modules from the OWB code
base.

   - webbeans-jms : We introduced this module years ago for JMS but frankly
   never see any usage. Also, it was not completed.
   - webbeans-tomcat7 : We introduced this modules for Tomcat7 integration
   but now it is useless and Tomcat already includes this integration with
   more natural way (
   https://github.com/apache/tomcat/tree/master/modules/owb)

WDYT? Any objection?
Regards.
Gurkan

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

>
> This is wrong, what does make you think that? I know you left for a very
> long time and missed quite a lot of things

I have been following most of the mailing lists even if I am not able to
contribute.


but typically most of xbean is
> not decided by these 3 people but was decided way earlier and we get like
> 5-6 people interacting regularly intercommunities (thinking to ee but
> osgi/karaf and standlaone too). Not huge but clearly not a one man project.
>
I am not just talking about something special to XBean. General observation.

Side note here is that it is not the right list to discuss that and not the
> right thread too probably (we shouldnt mix topics in threads IMHO).

Thank you for the advice.

I do not want to continue the discussion. You are always having to say
something.
Good luck to you on these projects even in OWB.
Cheers
Gurkan


On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau 
wrote:

> Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu  a
> écrit :
>
> > If you want to revert , you can...
> > But Xbean method returns null and throwing NPE is not a good way to go...
> >
>
> Contract makes it respected. If you run in another env you setup another
> impl.
> Side note being ignoring silently an error is worse IMO.
>
>
>
> > From my understanding looking to those projects and even OWB, most of the
> > decisions in these projects are only decided by one or two
> persons(probably
> > internally) but not with the community, this is not the Apache way of
> > managing projects.
> >
>
> This is wrong, what does make you think that? I know you left for a very
> long time and missed quite a lot of things but typically most of xbean is
> not decided by these 3 people but was decided way earlier and we get like
> 5-6 people interacting regularly intercommunities (thinking to ee but
> osgi/karaf and standlaone too). Not huge but clearly not a one man project.
>
> Side note here is that it is not the right list to discuss that and not the
> right thread too probably (we shouldnt mix topics in threads IMHO).
>
>
> > It is impossible for me to contribute such projects which are handled
> this
> > way...
> >
> > Cheers
> >
> > Gurkan
> >
> > On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
> > wrote:
> >
> > > Don't want to look mad or bad but I personally have a hard time to
> > convert
> > > such statement to action Gurkan.
> > > Basically most of this code is not that complex so self explanatory for
> > me
> > > - but also true I never read comments when contributing to project I'm
> > not
> > > committer in cause they generally brings you in a wrong direction IMHO.
> > > Are you missing some architecture design doc maybe?
> > >
> > > Side note: back on this commit, if it is linked to the ticket I
> > commented,
> > > it should be reverted right?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > Hi
> > > > I am looking at projects in Apache Geronimo and OWB side such as
> XBean,
> > > > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > > > I have observed that most of the source code has very small code
> > comments
> > > > and most of them are driven by a very small group of contributors.
> > > > It is really hard to contribute to these projects without some bit of
> > > > understanding of the source code. The important key idea behind the
> > > Apache
> > > > Projects are community and projects need to be driven by the
> community.
> > > To
> > > > extend the community around projects, we need to more care about the
> > > > source codes, documentation, guides etc.
> > > > I know that this type of stuff is time consuming but also important.
> > > > I just want to share my observations around these very cool projects.
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 9:5

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

If you want to revert , you can...
But Xbean method returns null and throwing NPE is not a good way to go...

>From my understanding looking to those projects and even OWB, most of the
decisions in these projects are only decided by one or two persons(probably
internally) but not with the community, this is not the Apache way of
managing projects.

It is impossible for me to contribute such projects which are handled this
way...

Cheers

Gurkan

On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
wrote:

> Don't want to look mad or bad but I personally have a hard time to convert
> such statement to action Gurkan.
> Basically most of this code is not that complex so self explanatory for me
> - but also true I never read comments when contributing to project I'm not
> committer in cause they generally brings you in a wrong direction IMHO.
> Are you missing some architecture design doc maybe?
>
> Side note: back on this commit, if it is linked to the ticket I commented,
> it should be reverted right?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu  a
> écrit :
>
> > Hi
> > I am looking at projects in Apache Geronimo and OWB side such as XBean,
> > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > I have observed that most of the source code has very small code comments
> > and most of them are driven by a very small group of contributors.
> > It is really hard to contribute to these projects without some bit of
> > understanding of the source code. The important key idea behind the
> Apache
> > Projects are community and projects need to be driven by the community.
> To
> > extend the community around projects, we need to more care about the
> > source codes, documentation, guides etc.
> > I know that this type of stuff is time consuming but also important.
> > I just want to share my observations around these very cool projects.
> > Regards.
> > Gurkan
> >
> >
> >
> > On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hmm,
> > >
> > > Have to admit I always use maven to run TCK and I use Intellij so not
> > that
> > > sure.
> > > Maybe something you can give a try is to only open tck module and close
> > > other modules to ensure eclipse m2 resolves it through the m2 repo but
> > > without any guarantee :s.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 10 juin 2020 à 08:38, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > Hi Romain
> > > > I will look into geronimo-xbean.
> > > > In the mean time, I have a question:
> > > > I try to run TestNG plugin in Eclipse but because of javax -> jakarta
> > > maven
> > > > shading, I am not able to launch the tests via this plugin. It throws
> > > > errors like
> > > >
> > > > INFO: CDI-TCK Specification version: null
> > > > java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
> > > >
> > > > Do you have any experience on this? I like to use this plugin to see
> > > > visually the tests
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Gurkan,
> > > > >
> > > > > Any way to test it and maybe harness it in geronimo xbean?
> > > > > Typically it can only happen if the URL is wrongly formatted (means
> > we
> > > > > should port a fix in xbean too) or the protocol is not supported
> > > (likely
> > > > 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

Hi
I am looking at projects in Apache Geronimo and OWB side such as XBean,
Meecrowave, Microprofile, Arthur etc. to contribute more.
I have observed that most of the source code has very small code comments
and most of them are driven by a very small group of contributors.
It is really hard to contribute to these projects without some bit of
understanding of the source code. The important key idea behind the Apache
Projects are community and projects need to be driven by the community. To
extend the community around projects, we need to more care about the
source codes, documentation, guides etc.
I know that this type of stuff is time consuming but also important.
I just want to share my observations around these very cool projects.
Regards.
Gurkan



On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau 
wrote:

> Hmm,
>
> Have to admit I always use maven to run TCK and I use Intellij so not that
> sure.
> Maybe something you can give a try is to only open tck module and close
> other modules to ensure eclipse m2 resolves it through the m2 repo but
> without any guarantee :s.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 10 juin 2020 à 08:38, Gurkan Erdogdu  a
> écrit :
>
> > Hi Romain
> > I will look into geronimo-xbean.
> > In the mean time, I have a question:
> > I try to run TestNG plugin in Eclipse but because of javax -> jakarta
> maven
> > shading, I am not able to launch the tests via this plugin. It throws
> > errors like
> >
> > INFO: CDI-TCK Specification version: null
> > java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
> >
> > Do you have any experience on this? I like to use this plugin to see
> > visually the tests
> > Regards.
> > Gurkan
> >
> >
> > On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi Gurkan,
> > >
> > > Any way to test it and maybe harness it in geronimo xbean?
> > > Typically it can only happen if the URL is wrongly formatted (means we
> > > should port a fix in xbean too) or the protocol is not supported
> (likely
> > > means a missing exclusion or new protocol handling in xbean).
> > > I saw some issues with .so in the past in tests but never managed to
> > > reproduce it  and I know jrt brings a new protocol but thought we
> > excluded
> > > it by default so if can confirm this case and if you have a few
> pointers
> > it
> > > would be great, I would be happy to do the work in xbean about it.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > -- Forwarded message -
> > > De : 
> > > Date: mer. 10 juin 2020 à 07:11
> > > Subject: [openwebbeans] branch master updated: OWB-1328 NPE in
> > > AbstractMetaDataFactory
> > > To: comm...@openwebbeans.apache.org 
> > >
> > >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > gerdogdu pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >  new b812c6f  OWB-1328 NPE in AbstractMetaDataFactory
> > >  new ff4c809  Merge branch 'master' of
> > > https://github.com/apache/openwebbeans
> > > b812c6f <https://github.com/apache/openwebbeansb812c6f> is described
> > below
> > >
> > > commit b812c6ff7db69723d692efa1efd4dca00fd73c2a
> > > Author: Gurkan Erdogdu 
> > > AuthorDate: Wed Jun 10 08:10:54 2020 +0300
> > >
> > > OWB-1328 NPE in AbstractMetaDataFactory
> > > ---
> > >  .../corespi/scanner/AbstractMetaDataDiscovery.java| 

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> When required we'll do, today there is really nothing justifying it.

If one integrates the OWB via POM dependency in his jakarta project, it is
a problem to see javax.* everywhere in OWB POM files. He needs to solve
problems via some exotic POM operations.  For example, I did not able to
run TEstNG
Probably, you will do it shortly because Jakarta EE 10 will start
Anyway, keep the good work. Also, we need to extend the community around
OWB. Community projects grow with community and decisions are made by the
community.
Gurkan


On Wed, Jun 10, 2020 at 12:08 PM Romain Manni-Bucau 
wrote:

> Le mer. 10 juin 2020 à 09:55, Gurkan Erdogdu  a
> écrit :
>
> > This javax to jakarta has already created problems in running for example
> > TestNG tests in eclipse :)
> > Also, keep in mind that OWB also depends on several Geronimo EE APIs and
> > must be sure that there is no String usage of javax. in any of these
> APIs.
> >
>
> We did :)
>
>
> > I am still not convinced of using shaded artifacts. For me the best thing
> > is to do one big single conversion from javax. to jakarta. and create a
> > branch and also using Jakarta EE APIs. I don't see any reason to use
> > Geronimo APIs. (except some simple OSGI artifacts)
> >
>
> Well in front of that I can say "I don't see any reason to use jakarta
> artifacts".
> Both are true except we control G ones, we don't control jakarta one and it
> happens they have bugs.
> We - at asf - also generally run with G ones so it is better to harness G
> ones than jakarta ones.
> It is not a big +1 for G but a +0.1 and -0.1 for jakarta.
> Finally, since we don't really provide these artifacts in owb itself it
> does not change anything but we do in meecrowave (an owb project - and here
> it is not a choice since we must have the right defaults) so it is
> consistent to use the same accross projects of the same family IMHO.
>
>
> > As I see, there are no other opinions, I will not create a VOTE for this
> > and keep this way. But, it will finally need to be done.
> >
>
> When required we'll do, today there is really nothing justifying it.
>
>
> > Gurkan
> >
> >
> > On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> > > Nice work romain!
> > >
> > > Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > >
> > > > FYI we run jakarta tck now with
> > > > https://issues.apache.org/jira/browse/OWB-1327
> > > > As expected it works fine
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 8 juin 2020 à 08:33, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > > >
> > > > >
> > > > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com>
> > > a
> > > > > écrit :
> > > > >
> > > > >> > Not, it is not correct Gurkan ;).
> > > > >> > jakarta does NOT support OSGi properly, it does it the old way
> and
> > > > break
> > > > >> > several rules. For instance last CDI spec jar contains:
> > > > >>
> > > > >> As I said in my previous email, I am not an OSGI expert. But,
> what I
> > > can
> > > > >> do
> > > > >> is that I can ping the CDI team in EE4J to add features to support
> > > > >> OWB-OSGI
> > > > >> or other ASF projects? Could you explain in detail?
> > > > >>
> > > > >
> > > > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > > > It is mainly the metadata.
> > > > > Point is we already contacted the spec leaders, even for
> Microprofile
> > > if
> > > > > you want to get the full story (same people more or less) and it
> > didn't
> > > > go
> > > > > well eno

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

This javax to jakarta has already created problems in running for example
TestNG tests in eclipse :)
Also, keep in mind that OWB also depends on several Geronimo EE APIs and
must be sure that there is no String usage of javax. in any of these APIs.
I am still not convinced of using shaded artifacts. For me the best thing
is to do one big single conversion from javax. to jakarta. and create a
branch and also using Jakarta EE APIs. I don't see any reason to use
Geronimo APIs. (except some simple OSGI artifacts)
As I see, there are no other opinions, I will not create a VOTE for this
and keep this way. But, it will finally need to be done.
Gurkan


On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
andraschko.tho...@gmail.com> wrote:

> Nice work romain!
>
> Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > FYI we run jakarta tck now with
> > https://issues.apache.org/jira/browse/OWB-1327
> > As expected it works fine
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 8 juin 2020 à 08:33, Romain Manni-Bucau 
> a
> > écrit :
> >
> > >
> > >
> > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu 
> a
> > > écrit :
> > >
> > >> > Not, it is not correct Gurkan ;).
> > >> > jakarta does NOT support OSGi properly, it does it the old way and
> > break
> > >> > several rules. For instance last CDI spec jar contains:
> > >>
> > >> As I said in my previous email, I am not an OSGI expert. But, what I
> can
> > >> do
> > >> is that I can ping the CDI team in EE4J to add features to support
> > >> OWB-OSGI
> > >> or other ASF projects? Could you explain in detail?
> > >>
> > >
> > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > It is mainly the metadata.
> > > Point is we already contacted the spec leaders, even for Microprofile
> if
> > > you want to get the full story (same people more or less) and it didn't
> > go
> > > well enough even if people were willing to do it.
> > > So factually today it is saner to keep it here and it is not an issue
> for
> > > G project anyway since we do it for years and we will keep doing it for
> > > defaults at least.
> > > Once again not an OWB discussion and decision had been taken already on
> > > this one so don't want to loop on the same topic again and again, in
> > > particular from the wrong list ;).
> > >
> > >
> > >>
> > >> Regards.
> > >> Gurkan
> > >>
> > >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > >> wrote:
> > >>
> > >> > So to conclude on this point not belonging to OWB, we still need our
> > >> fork
> > >> >> and eclipse always answered saying "yes we want OSGi [but we don't
> > >> really
> > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> > don't
> > >> >> work on that factually so OSGi is done at minimal cost.
> > >> >
> > >> > OK thanks for the clarification. I am not an OSGI expert.
> > >> >
> > >> > Ok Gurkan, let's be concrete, do you - you as you personally -
> accept
> > >> and
> > >> >> commit yourself to port any commit to one of the two branches to
> the
> > >> other
> > >> >> for all the time the project is at apache?
> > >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> > >> facts)
> > >> >> work.
> > >> >
> > >> > :=)
> > >> > Hey, I'm just proposing  what I think about. If nobody cares about
> it
> > or
> > >> > is not beneficial, it is ok, and also there is no need to VOTE (This
> > is
> > >> why
> > >> > I'd like to get more opinions on it). But look at Weld, they did the
> > >> > update, https://github.com/weld and full of updating their pom to
> use
> > >> > jakarta

[jira] [Commented] (OWB-1328) NPE in AbstractMetaDataFactory

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130279#comment-17130279
 ] 

Gurkan Erdogdu commented on OWB-1328:
-

[~Thihup] What kind of URL you get a NPE? Can you attach a simple example which 
shows the problem?

> NPE in AbstractMetaDataFactory
> --
>
> Key: OWB-1328
> URL: https://issues.apache.org/jira/browse/OWB-1328
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>        Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 2.0.18
>
>
> [https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java#L286]
>  
> If we have an URL that doesn't resolve to a File, we get a NPE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

Hi Romain
I will look into geronimo-xbean.
In the mean time, I have a question:
I try to run TestNG plugin in Eclipse but because of javax -> jakarta maven
shading, I am not able to launch the tests via this plugin. It throws
errors like

INFO: CDI-TCK Specification version: null
java.lang.NoClassDefFoundError: javax/el/ExpressionFactory

Do you have any experience on this? I like to use this plugin to see
visually the tests
Regards.
Gurkan


On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau 
wrote:

> Hi Gurkan,
>
> Any way to test it and maybe harness it in geronimo xbean?
> Typically it can only happen if the URL is wrongly formatted (means we
> should port a fix in xbean too) or the protocol is not supported (likely
> means a missing exclusion or new protocol handling in xbean).
> I saw some issues with .so in the past in tests but never managed to
> reproduce it  and I know jrt brings a new protocol but thought we excluded
> it by default so if can confirm this case and if you have a few pointers it
> would be great, I would be happy to do the work in xbean about it.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -- Forwarded message -
> De : 
> Date: mer. 10 juin 2020 à 07:11
> Subject: [openwebbeans] branch master updated: OWB-1328 NPE in
> AbstractMetaDataFactory
> To: comm...@openwebbeans.apache.org 
>
>
> This is an automated email from the ASF dual-hosted git repository.
>
> gerdogdu pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new b812c6f  OWB-1328 NPE in AbstractMetaDataFactory
>  new ff4c809  Merge branch 'master' of
> https://github.com/apache/openwebbeans
> b812c6f <https://github.com/apache/openwebbeansb812c6f> is described below
>
> commit b812c6ff7db69723d692efa1efd4dca00fd73c2a
> Author: Gurkan Erdogdu 
> AuthorDate: Wed Jun 10 08:10:54 2020 +0300
>
> OWB-1328 NPE in AbstractMetaDataFactory
> ---
>  .../corespi/scanner/AbstractMetaDataDiscovery.java| 15
> ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git
>
> a/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java
>
> b/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java
> index 44febe9..c011670 100644
> ---
>
> a/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java
> +++
>
> b/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java
> @@ -43,6 +43,8 @@ import org.apache.xbean.finder.util.Files;
>
>  import javax.decorator.Decorator;
>  import javax.interceptor.Interceptor;
> +
> +import java.io.File;
>  import java.io.IOException;
>  import java.lang.annotation.Annotation;
>  import java.net.URL;
> @@ -283,11 +285,14 @@ public abstract class AbstractMetaDataDiscovery
> implements BdaScannerService
>  else
>  {
>  // we could check for
> META-INF/maven/org.apache.geronimo.specs presence there but this is faster
> -final String filename = Files.toFile(url).getName();
> -if (filename.startsWith("geronimo-") &&
> filename.contains("_spec"))
> -{
> -it.remove();
> -}
> +File file = Files.toFile(url);
> +if(file!= null && file.exists()) {
> +final String filename = file.getName();
> +if (filename.startsWith("geronimo-") &&
> filename.contains("_spec"))
> +{
> +it.remove();
> +}
> +}
>  }
>  }
>  }
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[jira] [Closed] (OWB-1328) NPE in AbstractMetaDataFactory

[Gurkan Erdogdu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-1328.
---

> NPE in AbstractMetaDataFactory
> --
>
> Key: OWB-1328
> URL: https://issues.apache.org/jira/browse/OWB-1328
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>        Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 2.0.18
>
>
> [https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java#L286]
>  
> If we have an URL that doesn't resolve to a File, we get a NPE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OWB-1328) NPE in AbstractMetaDataFactory

[Gurkan Erdogdu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu resolved OWB-1328.
-
Fix Version/s: 2.0.18
   Resolution: Fixed

Fixed.

> NPE in AbstractMetaDataFactory
> --
>
> Key: OWB-1328
> URL: https://issues.apache.org/jira/browse/OWB-1328
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>        Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 2.0.18
>
>
> [https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java#L286]
>  
> If we have an URL that doesn't resolve to a File, we get a NPE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1328) NPE in AbstractMetaDataFactory

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130077#comment-17130077
 ] 

Gurkan Erdogdu commented on OWB-1328:
-

Thanks for reporting. This issue is now fixed in trunk.

> NPE in AbstractMetaDataFactory
> --
>
> Key: OWB-1328
> URL: https://issues.apache.org/jira/browse/OWB-1328
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>Priority: Minor
>
> [https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java#L286]
>  
> If we have an URL that doesn't resolve to a File, we get a NPE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release Apache OpenWebBeans-2.0.17

[Gurkan Erdogdu]

+1

On Mon, Jun 8, 2020 at 9:36 AM Romain Manni-Bucau 
wrote:

> +1
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 8 juin 2020 à 00:46, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> a écrit :
>
> > +1
> > --
> >
> > *Daniel Dias dos Santos*
> > Java Developer
> > SouJava & JCP Member
> > GitHub: https://github.com/Daniel-Dos
> > Linkedin: www.linkedin.com/in/danieldiasjava
> > Twitter: http://twitter.com/danieldiasjava
> >
> >
> > Em dom., 7 de jun. de 2020 às 18:30, Mark Struberg
> >  escreveu:
> >
> > > hi!
> > >
> > > I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.17
> > >
> > > The following tickets have been resolved:
> > >
> > > Bug
> > >
> > > [OWB-1214 <https://issues.apache.org/jira/browse/OWB-1214>] - Package
> > > annotation access is fragile
> > > Task
> > >
> > > [OWB-1322 <https://issues.apache.org/jira/browse/OWB-1322>] - SLF4J
> > > integration workaround for log4j2-slf4j implementation which can fail
> in
> > > NPE on java >= 9
> > > [OWB-1323 <https://issues.apache.org/jira/browse/OWB-1323>] - Upgrade
> to
> > > asm8
> > > [OWB-1324 <https://issues.apache.org/jira/browse/OWB-1324>] - Support
> > > maven shade 3.2.3
> > > [OWB-1325 <https://issues.apache.org/jira/browse/OWB-1325>] - Provide
> a
> > > spy flavor of ClassDefiningService
> > > [OWB-1326 <https://issues.apache.org/jira/browse/OWB-1326>] -
> > > Bean#isNullable is ignored since CDI-1.1.
> > >
> > >
> > >
> > > The staging repo is
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/
> > > <
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/
> > > >
> > >
> > > commit in our repo is 20d2b83390996007873abb2338a8b1fb61a55ceb
> > >
> > > The source release can be found in
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
> > > <
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
> > > >
> > >
> > > sha1 is 192bd3654375640ac5ceb365e728bba67bed16b4
> > >
> > > Please VOTE:
> > > [+1] let's ship it
> > > [0] meh, don't care
> > > [-1] stop there is a ${showstopper}
> > >
> > > The VOTE is open for 72h
> > >
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> >
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[jira] [Assigned] (OWB-1328) NPE in AbstractMetaDataFactory

[Gurkan Erdogdu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OWB-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu reassigned OWB-1328:
---

Assignee: Gurkan Erdogdu

> NPE in AbstractMetaDataFactory
> --
>
> Key: OWB-1328
> URL: https://issues.apache.org/jira/browse/OWB-1328
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Thiago Henrique Hupner
>        Assignee: Gurkan Erdogdu
>Priority: Minor
>
> [https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/corespi/scanner/AbstractMetaDataDiscovery.java#L286]
>  
> If we have an URL that doesn't resolve to a File, we get a NPE



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

There are some string literals in source code using javax.*. for example,
in BeansDeployer, public static final String JAVAX_ENTERPRISE_PACKAGE =
"javax.enterprise.";.
How is the shading plugin fixes these?
Regards.
Gurkan

On Sun, Jun 7, 2020 at 10:55 PM Gurkan Erdogdu 
wrote:

> They also impled the bda differently than us making it only usable for
>> single bda apps and created arc@quarkus which violates that, so not sure
>> we
>> should copy what others do. I tend to prefer to add thinking on top of
>> that
>> in the context of our project which is diff than the RI (by design and by
>> workforce).
>>
> This is not copying but not going into discussion more.
>
>
>> I can agree that in one year we reverse the pattern, shade becoming javax.
>> But since we cant enforce anyone to do the sync between branches and due
>> to
>> past years contributions stats, we must not go that way IMHO, it would
>> either make us expose 2 bad branches or kill our resources for no user
>> gains. Indeed that is my opinion but from the stats i have today it is my
>> conclusion.
>
> You have concerns about the community, understanding.
>
> Please discuss it on G, it does not impact OWB - and btw this is not what
>> had been said ;).
>>
> Thanks for the pointer
>
> Regards.
> Gurkan
>
> On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau 
> wrote:
>
>> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu  a
>> écrit :
>>
>> > >
>> > > So to conclude on this point not belonging to OWB, we still need our
>> fork
>> > > and eclipse always answered saying "yes we want OSGi [but we don't
>> really
>> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they
>> don't
>> > > work on that factually so OSGi is done at minimal cost.
>> >
>> > OK thanks for the clarification. I am not an OSGI expert.
>> >
>> > Ok Gurkan, let's be concrete, do you - you as you personally - accept
>> and
>> > > commit yourself to port any commit to one of the two branches to the
>> > other
>> > > for all the time the project is at apache?
>> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
>> > facts)
>> > > work.
>> >
>> > :=)
>> > Hey, I'm just proposing  what I think about. If nobody cares about it
>> or is
>> > not beneficial, it is ok, and also there is no need to VOTE (This is why
>> > I'd like to get more opinions on it).
>>
>>
>> It is fine, just wanted to emphasis the consequence and what it means for
>> the project.
>>
>> But look at Weld, they did the
>> > update, https://github.com/weld and full of updating their pom to use
>> > jakarta.*
>> >
>>
>> They also impled the bda differently than us making it only usable for
>> single bda apps and created arc@quarkus which violates that, so not sure
>> we
>> should copy what others do. I tend to prefer to add thinking on top of
>> that
>> in the context of our project which is diff than the RI (by design and by
>> workforce).
>>
>>
>>
>> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
>> > geronimo-...specs which depend on javax.*.  Today or tomorrow, we will
>> > eventually move to jakarta.* namespace.  Instead of working with such
>> > shading plugin stuff as a workaround, I just offer to take the master to
>> > jakarta.* and update all  OWB modules' dependency from javax.* to
>> jakarta.*
>> > official APIS. This is not related to who will maintain the branches.
>> You
>> > know that ASF works as a voluntary based approach. You can not push
>> anybody
>> > to work on anything as in commercial companies.
>> >
>>
>> I can agree that in one year we reverse the pattern, shade becoming javax.
>> But since we cant enforce anyone to do the sync between branches and due
>> to
>> past years contributions stats, we must not go that way IMHO, it would
>> either make us expose 2 bad branches or kill our resources for no user
>> gains. Indeed that is my opinion but from the stats i have today it is my
>> conclusion.
>>
>>
>> > Also, regarding the cost and energy you mention to maintain the branch,
>> via
>> > Geronimo specs, you will need to update all of the Geronimo Specs and
>> > maintain them. I think this is not rational because now, jakarta.*
>> official
>> > API license is EPL and Apache friendly. Why do I need to m

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> They also impled the bda differently than us making it only usable for
> single bda apps and created arc@quarkus which violates that, so not sure
> we
> should copy what others do. I tend to prefer to add thinking on top of that
> in the context of our project which is diff than the RI (by design and by
> workforce).
>
This is not copying but not going into discussion more.


> I can agree that in one year we reverse the pattern, shade becoming javax.
> But since we cant enforce anyone to do the sync between branches and due to
> past years contributions stats, we must not go that way IMHO, it would
> either make us expose 2 bad branches or kill our resources for no user
> gains. Indeed that is my opinion but from the stats i have today it is my
> conclusion.

You have concerns about the community, understanding.

Please discuss it on G, it does not impact OWB - and btw this is not what
> had been said ;).
>
Thanks for the pointer

Regards.
Gurkan

On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau 
wrote:

> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu  a
> écrit :
>
> > >
> > > So to conclude on this point not belonging to OWB, we still need our
> fork
> > > and eclipse always answered saying "yes we want OSGi [but we don't
> really
> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> > > work on that factually so OSGi is done at minimal cost.
> >
> > OK thanks for the clarification. I am not an OSGI expert.
> >
> > Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> > > commit yourself to port any commit to one of the two branches to the
> > other
> > > for all the time the project is at apache?
> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
> > facts)
> > > work.
> >
> > :=)
> > Hey, I'm just proposing  what I think about. If nobody cares about it or
> is
> > not beneficial, it is ok, and also there is no need to VOTE (This is why
> > I'd like to get more opinions on it).
>
>
> It is fine, just wanted to emphasis the consequence and what it means for
> the project.
>
> But look at Weld, they did the
> > update, https://github.com/weld and full of updating their pom to use
> > jakarta.*
> >
>
> They also impled the bda differently than us making it only usable for
> single bda apps and created arc@quarkus which violates that, so not sure
> we
> should copy what others do. I tend to prefer to add thinking on top of that
> in the context of our project which is diff than the RI (by design and by
> workforce).
>
>
>
> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> > geronimo-...specs which depend on javax.*.  Today or tomorrow, we will
> > eventually move to jakarta.* namespace.  Instead of working with such
> > shading plugin stuff as a workaround, I just offer to take the master to
> > jakarta.* and update all  OWB modules' dependency from javax.* to
> jakarta.*
> > official APIS. This is not related to who will maintain the branches. You
> > know that ASF works as a voluntary based approach. You can not push
> anybody
> > to work on anything as in commercial companies.
> >
>
> I can agree that in one year we reverse the pattern, shade becoming javax.
> But since we cant enforce anyone to do the sync between branches and due to
> past years contributions stats, we must not go that way IMHO, it would
> either make us expose 2 bad branches or kill our resources for no user
> gains. Indeed that is my opinion but from the stats i have today it is my
> conclusion.
>
>
> > Also, regarding the cost and energy you mention to maintain the branch,
> via
> > Geronimo specs, you will need to update all of the Geronimo Specs and
> > maintain them. I think this is not rational because now, jakarta.*
> official
> > API license is EPL and Apache friendly. Why do I need to maintain for
> > example Geronimo EL?
> >
>
> Please discuss it on G, it does not impact OWB - and btw this is not what
> had been said ;).
>
>
>
> > Regards.
> > Gurkan
> >
> >
> >
> >
> >
> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu 
> a
> > > écrit :
> > >
> > > > Hi David
> > > >
> > > > I’m not sure exactly how it impacts this decision, but IIUC the
> > geronimo
> > > > > cdi spec jar is rather essential for some uses as it has OSGI
> support
> > > > > whereas IIUC the ec

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

> Not, it is not correct Gurkan ;).
> jakarta does NOT support OSGi properly, it does it the old way and break
> several rules. For instance last CDI spec jar contains:

As I said in my previous email, I am not an OSGI expert. But, what I can do
is that I can ping the CDI team in EE4J to add features to support OWB-OSGI
or other ASF projects? Could you explain in detail?

Regards.
Gurkan

On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu 
wrote:

> So to conclude on this point not belonging to OWB, we still need our fork
>> and eclipse always answered saying "yes we want OSGi [but we don't really
>> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
>> work on that factually so OSGi is done at minimal cost.
>
> OK thanks for the clarification. I am not an OSGI expert.
>
> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
>> commit yourself to port any commit to one of the two branches to the other
>> for all the time the project is at apache?
>> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
>> work.
>
> :=)
> Hey, I'm just proposing  what I think about. If nobody cares about it or
> is not beneficial, it is ok, and also there is no need to VOTE (This is why
> I'd like to get more opinions on it). But look at Weld, they did the
> update, https://github.com/weld and full of updating their pom to use
> jakarta.*
>
> Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> geronimo-...specs which depend on javax.*.  Today or tomorrow, we will
> eventually move to jakarta.* namespace.  Instead of working with such
> shading plugin stuff as a workaround, I just offer to take the master to
> jakarta.* and update all  OWB modules' dependency from javax.* to jakarta.*
> official APIS. This is not related to who will maintain the branches. You
> know that ASF works as a voluntary based approach. You can not push anybody
> to work on anything as in commercial companies.
>
> Also, regarding the cost and energy you mention to maintain the branch,
> via Geronimo specs, you will need to update all of the Geronimo Specs and
> maintain them. I think this is not rational because now, jakarta.* official
> API license is EPL and Apache friendly. Why do I need to maintain for
> example Geronimo EL?
>
> Regards.
> Gurkan
>
>
>
>
>
> On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau 
> wrote:
>
>> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  a
>> écrit :
>>
>> > Hi David
>> >
>> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
>> > > cdi spec jar is rather essential for some uses as it has OSGI support
>> > > whereas IIUC the eclipse/jakarta one doesn’t.
>> > >
>> > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
>> > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
>> and
>> > build. It has OSGI enabled MANIFEST.MF file.
>> >
>>
>> Not, it is not correct Gurkan ;).
>> jakarta does NOT support OSGi properly, it does it the old way and break
>> several rules. For instance last CDI spec jar contains:
>>
>> Manifest-Version: 1.0
>> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
>>  r Java)
>> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
>> Bundle-SymbolicName: jakarta.enterprise.cdi-api
>> Built-By: default
>> Bnd-LastModified: 1590678420932
>> Bundle-ManifestVersion: 2
>> Bundle-DocURL: https://jboss.org
>> Bundle-Vendor: JBoss by Red Hat, Inc.
>> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
>>  3)",jakarta.interceptor;version="[2.0,3)"
>> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>> Tool: Bnd-2.4.1.201501161923
>> Originally-Created-By: Apache Maven Bundle Plugin
>> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
>>  ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
>>  nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
>>  sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
>>  arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
>>  rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
>>  ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
>>  til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
>>  se

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> So to conclude on this point not belonging to OWB, we still need our fork
> and eclipse always answered saying "yes we want OSGi [but we don't really
> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> work on that factually so OSGi is done at minimal cost.

OK thanks for the clarification. I am not an OSGI expert.

Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> commit yourself to port any commit to one of the two branches to the other
> for all the time the project is at apache?
> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
> work.

:=)
Hey, I'm just proposing  what I think about. If nobody cares about it or is
not beneficial, it is ok, and also there is no need to VOTE (This is why
I'd like to get more opinions on it). But look at Weld, they did the
update, https://github.com/weld and full of updating their pom to use
jakarta.*

Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
geronimo-...specs which depend on javax.*.  Today or tomorrow, we will
eventually move to jakarta.* namespace.  Instead of working with such
shading plugin stuff as a workaround, I just offer to take the master to
jakarta.* and update all  OWB modules' dependency from javax.* to jakarta.*
official APIS. This is not related to who will maintain the branches. You
know that ASF works as a voluntary based approach. You can not push anybody
to work on anything as in commercial companies.

Also, regarding the cost and energy you mention to maintain the branch, via
Geronimo specs, you will need to update all of the Geronimo Specs and
maintain them. I think this is not rational because now, jakarta.* official
API license is EPL and Apache friendly. Why do I need to maintain for
example Geronimo EL?

Regards.
Gurkan





On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau 
wrote:

> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  a
> écrit :
>
> > Hi David
> >
> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> > > cdi spec jar is rather essential for some uses as it has OSGI support
> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > >
> > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
> > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
> and
> > build. It has OSGI enabled MANIFEST.MF file.
> >
>
> Not, it is not correct Gurkan ;).
> jakarta does NOT support OSGi properly, it does it the old way and break
> several rules. For instance last CDI spec jar contains:
>
> Manifest-Version: 1.0
> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
>  r Java)
> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> Built-By: default
> Bnd-LastModified: 1590678420932
> Bundle-ManifestVersion: 2
> Bundle-DocURL: https://jboss.org
> Bundle-Vendor: JBoss by Red Hat, Inc.
> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
>  3)",jakarta.interceptor;version="[2.0,3)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Tool: Bnd-2.4.1.201501161923
> Originally-Created-By: Apache Maven Bundle Plugin
> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
>  ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
>  nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
>  sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
>  arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
>  rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
>  ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
>  til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
>  ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
>  ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
>  se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
>  arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
>  ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
>  ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
>  .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
>  karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
>  ise.util",jakarta.enterprise.util;version="3.0"
> Bundle-Name: CDI APIs
> Bundle-Version: 3.0.0.M4
> Build-Jdk-Spec: 1.8
> Cre

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

Hi David

I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> cdi spec jar is rather essential for some uses as it has OSGI support
> whereas IIUC the eclipse/jakarta one doesn’t.
>
No, it is not correct. It has OSGI support. GlassFish is an OSGI based
server.You can grap the code from https://github.com/eclipse-ee4j/cdi and
build. It has OSGI enabled MANIFEST.MF file.

Gurkan’s proposal will only add difficulty for developers and probably
> users.
>
What is the difficulty? The change will only affect maintaining the javax.*
branch and fully renamed jakarta.* dependencies in master.

Regards.
Gurkan

On Sun, Jun 7, 2020 at 8:58 PM David Jencks 
wrote:

> I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> cdi spec jar is rather essential for some uses as it has OSGI support
> whereas IIUC the eclipse/jakarta one doesn’t.
>
> Personally I’m afraid I’m totally on Romain’s side so far, AFAICT Gurkan’s
> proposal will only add difficulty for developers and probably users.
> Although I haven’t been active here for years I might even vote.
>
> thanks
> David Jencks
>
> > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu 
> wrote:
> >
> >>
> >> Tomcat works with branches since years without any issue.
> >> All projects we tried to use branches we abandoned branches just after
> >> having done them.
> >> It is fine if the old branch is no more used but here we know we will
> >> maintain javax branch more than jakarta one for some time so I think we
> >> should avoid it while it is not justified or one of the 2 branches
> (javax)
> >> is "almost dead".
> >
> > Working with branches always happens in all open source projects.  And
> > there are times when it is logical to create the branch. Jakarta EE 9 API
> > migration is the best time to create such a branch. Eventually, we will
> > create such a branch in Jakarta EE 10.
> >
> > Fact there will be no more javax is useless IMHO, only question we should
> >> care about is "do we have javax users?"  and should we work on javax
> branch
> >> enough to care about having 2 duplicate branches. Answer is obviously
> yes
> >> and more than jakarta users today, therefore I think for some months
> (maybe
> >> a few years) we should stick to javax as our primary branch and ensure
> the
> >> alignments and bugfixes can trivially - == without any action from dev
> - be
> >> ported. It is what we have today.
> >>
> > What could be more natural than maintaining branches (with backporting
> from
> > master only if necessary). With Jakarta EE 10, we will eventually create
> > the branch for supporting the EE 8. Also, for the release versioning, it
> is
> > nice to have a 3.x release. The community will notice that 3.x is the
> > starting point of Jakarta EE support. Will you release 2.x with the
> > intention of supporting Jakarta EE 9? I am personally not positive on
> this.
> > I think, 3.x release will also get more interest even if the
> functionality
> > and API stay the same. We can prepare the press release for it.
> >
> > Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> >> nor as transitive dep so this change must stay a noop for consumers).
> >>
> > What is the problem of depending on the official Jakarta EE CDI API? It
> is
> > an Apache friendly license. Instead of maintaining the Geronimo CDI API
> > internally, it is more logical to use Jakarta EE official CDI API and
> > maintain this API with EE4J community.
> >
> > would also appreciate if you do a vote if you can point out the breaking
> >> changes - except the package renaming - justifying to fork ourself and
> what
> >> does not work with current solution, can ease the decision/vote.
> >> Today using jakarta/EE9 API is quite easy (
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> ).
> >> We should absolutely enhance the pom experience though but it is
> trivial to
> >> do at maven level - I was envisionning to do it in shade plugin to be
> more
> >> precise.
> >>
> > I know that there will be no functional change. But, I am also against
> > shading for jakarta.*. If there will be no change on Jakarta EE 10, will
> we
> > continue to shade?  What happens when there will be a change in EJB, JMS
> > etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
> > the natural thing to do for the community decision. If the community
> would
> > l

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> Tomcat works with branches since years without any issue.
> All projects we tried to use branches we abandoned branches just after
> having done them.
> It is fine if the old branch is no more used but here we know we will
> maintain javax branch more than jakarta one for some time so I think we
> should avoid it while it is not justified or one of the 2 branches (javax)
> is "almost dead".

Working with branches always happens in all open source projects.  And
there are times when it is logical to create the branch. Jakarta EE 9 API
migration is the best time to create such a branch. Eventually, we will
create such a branch in Jakarta EE 10.

Fact there will be no more javax is useless IMHO, only question we should
> care about is "do we have javax users?"  and should we work on javax branch
> enough to care about having 2 duplicate branches. Answer is obviously yes
> and more than jakarta users today, therefore I think for some months (maybe
> a few years) we should stick to javax as our primary branch and ensure the
> alignments and bugfixes can trivially - == without any action from dev - be
> ported. It is what we have today.
>
What could be more natural than maintaining branches (with backporting from
master only if necessary). With Jakarta EE 10, we will eventually create
the branch for supporting the EE 8. Also, for the release versioning, it is
nice to have a 3.x release. The community will notice that 3.x is the
starting point of Jakarta EE support. Will you release 2.x with the
intention of supporting Jakarta EE 9? I am personally not positive on this.
I think, 3.x release will also get more interest even if the functionality
and API stay the same. We can prepare the press release for it.

Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> nor as transitive dep so this change must stay a noop for consumers).
>
What is the problem of depending on the official Jakarta EE CDI API? It is
an Apache friendly license. Instead of maintaining the Geronimo CDI API
internally, it is more logical to use Jakarta EE official CDI API and
maintain this API with EE4J community.

would also appreciate if you do a vote if you can point out the breaking
> changes - except the package renaming - justifying to fork ourself and what
> does not work with current solution, can ease the decision/vote.
> Today using jakarta/EE9 API is quite easy (
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> ).
> We should absolutely enhance the pom experience though but it is trivial to
> do at maven level - I was envisionning to do it in shade plugin to be more
> precise.
>
I know that there will be no functional change. But, I am also against
shading for jakarta.*. If there will be no change on Jakarta EE 10, will we
continue to shade?  What happens when there will be a change in EJB, JMS
etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
the natural thing to do for the community decision. If the community would
like to keep it as it is via shading, it is fine.

>
> To try to rephrase/clarify my questionning today: you ask for jakarta
> support, we already have it in a dev and project efficient way so why
> should we change since I don't hink there is anything new - once again if
> API starts to fully break discussion is different but github doesnt reflect
> that?
>
This is not just for Jakarta EE 9 support. As we know, there will be no API
(functional) change, only package renaming. But, I want to emphasize that
with such turning points, it is so logical to integrate official Jakarta
CDI API into our master (removing the geronimo-cdi), and release our new
3.x version and let the public know that OWB supports official CDI API
beginning with 3.x release. Yeah, shading is an option for package renaming
but think long term. Also, I am really against the shading. It really
disturbs the users which depend on OWB implementation. For example,
currently Glassfish supports Weld integration but one can also implement
OWB to replace Weld in Glassfish. Therefore, instead of using the shaded
version, it is really important to have the full Jakarta EE CDI API in our
poms. You will still have javax.* dependency in ur POMs even if doing a
shade. This is not good idea to still maintain javax.* in our POM files.

What are other opinions before formal voting?
Regards.
Gurkan



On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau 
wrote:

> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu  a
> écrit :
>
> > Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
> >
>
> Tomcat works with branches since years without any issue.
> All projects we tried to use branches we abandoned branches just after
> having done them.
> It is fine if the old branch is no more used but here we know we will
> maintain

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
sorry but not understand the resistance on this? will you always shade ?
 creating the new master and maintain the 2.x branch, is the best logical
way. there will be no javax.* any more. Tomcat maintains 3  branches and 1
master. only maintains 1 branch and 1 master is totally fine.

I will propose a vote shortly to decide on to create a master with 3.x with
fully support of jakarta with a normal pom dependency with jakarta api.

Regs
Gurkan


On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau  wrote:

> Today we don't need, tomorrow I don't know but while API does not change
> (except the package) we shouldn't fork ourself IMHO (cause it is what you
> propose as a consequence).
> If it becomes necessary let's do it but my vote is to stay lazy on that.
>
>
> side note for G API discussion belongs to dev@G but it is less an issue to
> fork from now since we rarely update the API, the side note here is that
> CDI SE is already fully runnable on ASF stack with jakarta package since
> some weeks or months, we did all the needed releases.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> a écrit :
>
> > AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > As EE9 just changes the namespace, it's perfectly fine.
> >
> > I'm actually also a supporter of doing a hard cut but it's not required
> and
> > we can do it for EE 10.
> >
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > Virenfrei.
> > www.avast.com
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com>:
> >
> > > We need to maintain two branches
> > >
> > > EE 8 for javax.* package 2.x branch
> > > EE 9 for jakarta.* package 3.x master
> > >
> > > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'll probably restate my position on that: if EE 9 brings
> > significatively
> > > > new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> > > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as we
> are
> > I
> > > > think avoiding to maintain two branches we can't merge regularly.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com>
> > a
> > > > écrit :
> > > >
> > > > > Hi
> > > > > After the 2.x release, can we get the master to 3.0.0 to support
> > > upcoming
> > > > > Jakarta EE 9 release with jakarta.* namespace?
> > > > >
> > > > > I also favor to use the Jakarta EE CDI API instead of using the
> > Apache
> > > > > based api.
> > > > > Regards
> > > > > Gurkan
> > > > >
> > > > > --
> > > > > Gurkan Erdogdu
> > > > > http://gurkanerdogdu.blogspot.com
> > > > >
> > > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

We need to maintain two branches

EE 8 for javax.* package 2.x branch
EE 9 for jakarta.* package 3.x master

On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau  wrote:

> Hi,
>
> I'll probably restate my position on that: if EE 9 brings significatively
> new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> missed sthg, looked quite fast. if EE9==EE8 then we can stay as we are I
> think avoiding to maintain two branches we can't merge regularly.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu  a
> écrit :
>
> > Hi
> > After the 2.x release, can we get the master to 3.0.0 to support upcoming
> > Jakarta EE 9 release with jakarta.* namespace?
> >
> > I also favor to use the Jakarta EE CDI API instead of using the Apache
> > based api.
> > Regards
> > Gurkan
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Jakarta EE 9 Support

[Gurkan Erdogdu]

Hi
After the 2.x release, can we get the master to 3.0.0 to support upcoming
Jakarta EE 9 release with jakarta.* namespace?

I also favor to use the Jakarta EE CDI API instead of using the Apache
based api.
Regards
Gurkan

-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Will start with the release tomorrow

[Gurkan Erdogdu]

 Does current master support jakarta.*? What do you mean by comply? Did you
run latest Jakarta EE 9 Cdi TCK?

On 7 Jun 2020 Sun at 11:16 Romain Manni-Bucau  wrote:

> +1 for the release
>
> Let's discuss it in another thread since today we are already compliant and
> just need to setup tck in the build
>
> Le dim. 7 juin 2020 à 10:13, Gurkan Erdogdu  a
> écrit :
>
> > Hi Mark
> > After the release, can we make master 3.0.0 for
> > Jakarta EE 9 and adapting the Jakarta  Cdi API?
> > Regards
> > Gurkan
> >
> > On 6 Jun 2020 Sat at 23:34 Mark Struberg 
> > wrote:
> >
> > > hi folks!
> > >
> > > Gonna start with the OWB release tomorrow.
> > > If there is anything to fix before that then shout.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Will start with the release tomorrow

[Gurkan Erdogdu]

Hi Mark
After the release, can we make master 3.0.0 for
Jakarta EE 9 and adapting the Jakarta  Cdi API?
Regards
Gurkan

On 6 Jun 2020 Sat at 23:34 Mark Struberg  wrote:

> hi folks!
>
> Gonna start with the OWB release tomorrow.
> If there is anything to fix before that then shout.
>
> LieGrue,
> strub
>
> --
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Adding Comments To Source Code

[Gurkan Erdogdu]

>
> We need a release from master before I think then it sounds possible to me.

Sounds good to me. Then we can take the master to jakarta.* and pom version
to 3.0.0

Side note: our jakarta artifacts run well with CDI SE/notEE 2.0
> certification already but were only tested against javax TCK AFAIK.
>
I think the Jakarta EE CDI TCK is ready to use. I will check that.

Regards.
Gurkan

On Fri, Jun 5, 2020 at 4:42 PM Romain Manni-Bucau 
wrote:

> We need a release from master before I think then it sounds possible to me.
>
> Side note: our jakarta artifacts run well with CDI SE/notEE 2.0
> certification already but were only tested against javax TCK AFAIK.
>
> Le ven. 5 juin 2020 à 15:40, Gurkan Erdogdu  a
> écrit :
>
> > OK I agree.
> > Lets focus on improving the OWB.
> > What is the latest status of TCK covering regarding latest Jakarta EE CDI
> > specification?
> > Also, as I remembered Mark created a branch for Jakarta EE API? Can we
> > migrate those to master?
> >
> >
> > On Fri, Jun 5, 2020 at 4:38 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > I agree comments are important but they must not paraphrase the code,
> > look
> > > at the two first comments of this commit:
> > >
> > >
> >
> https://github.com/apache/openwebbeans/commit/c2b07386e2bd9a702a4fab07696e1a0cdcb792c7#diff-75cef79164caacdbcadbd8e8bcc87c3eR48
> > > .
> > > I learn that the construct constructs and the init method intiializes,
> > not
> > > sure it is worth the 6 lines.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 5 juin 2020 à 15:30, Gurkan Erdogdu 
> a
> > > écrit :
> > >
> > > > I again totally agree with you but think about the others. For
> > example, I
> > > > may not be clever to understand what the code is doing without any
> > > comment.
> > > > For me, comments are as important as source code.
> > > >
> > > > On Fri, Jun 5, 2020 at 4:26 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > About classloader proxy:
> > > > >
> > > > > suspect I can need a more precise request - sadly I wrote this
> class
> > > so I
> > > > > understand it :s.
> > > > > But the only thing in this whole class is putting a proxy class in
> a
> > > map
> > > > in
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java#L135
> > > > > .
> > > > > Not sure we need a comment thanks to the class name, or does the
> name
> > > > miss
> > > > > "ClassDefiningService" explicitly?
> > > > >
> > > > > About spring: I hate this kind of codebase, you take way more time
> to
> > > try
> > > > > to read the comment than the code source and I never got luck I
> > assume
> > > > > cause when I spend 5mn on the doc I always end up reading the code
> > > which
> > > > > takes way less time. Writing so much javadoc makes sense when you
> use
> > > the
> > > > > code as an API - our SPI is into this category and we should
> explain
> > > the
> > > > > expectations and requirements - but impl is not in that category at
> > > all.
> > > > If
> > > > > an user uses owb-impl in his project there is an issue. Since we
> > don't
> > > > > publish our impl modules javadoc I think it is saner to keep the
> > > comments
> > > > > for not obvious explanations - for ex
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java#L1424
> > > > > .
> > > > >
> > > > > Hope i

Re: Adding Comments To Source Code

[Gurkan Erdogdu]

OK I agree.
Lets focus on improving the OWB.
What is the latest status of TCK covering regarding latest Jakarta EE CDI
specification?
Also, as I remembered Mark created a branch for Jakarta EE API? Can we
migrate those to master?


On Fri, Jun 5, 2020 at 4:38 PM Romain Manni-Bucau 
wrote:

> I agree comments are important but they must not paraphrase the code, look
> at the two first comments of this commit:
>
> https://github.com/apache/openwebbeans/commit/c2b07386e2bd9a702a4fab07696e1a0cdcb792c7#diff-75cef79164caacdbcadbd8e8bcc87c3eR48
> .
> I learn that the construct constructs and the init method intiializes, not
> sure it is worth the 6 lines.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 5 juin 2020 à 15:30, Gurkan Erdogdu  a
> écrit :
>
> > I again totally agree with you but think about the others. For example, I
> > may not be clever to understand what the code is doing without any
> comment.
> > For me, comments are as important as source code.
> >
> > On Fri, Jun 5, 2020 at 4:26 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > About classloader proxy:
> > >
> > > suspect I can need a more precise request - sadly I wrote this class
> so I
> > > understand it :s.
> > > But the only thing in this whole class is putting a proxy class in a
> map
> > in
> > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java#L135
> > > .
> > > Not sure we need a comment thanks to the class name, or does the name
> > miss
> > > "ClassDefiningService" explicitly?
> > >
> > > About spring: I hate this kind of codebase, you take way more time to
> try
> > > to read the comment than the code source and I never got luck I assume
> > > cause when I spend 5mn on the doc I always end up reading the code
> which
> > > takes way less time. Writing so much javadoc makes sense when you use
> the
> > > code as an API - our SPI is into this category and we should explain
> the
> > > expectations and requirements - but impl is not in that category at
> all.
> > If
> > > an user uses owb-impl in his project there is an issue. Since we don't
> > > publish our impl modules javadoc I think it is saner to keep the
> comments
> > > for not obvious explanations - for ex
> > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java#L1424
> > > .
> > >
> > > Hope it explains a bit where I'm coming from and what I'm hoping we
> > target.
> > >
> > > Le ven. 5 juin 2020 à 15:21, Gurkan Erdogdu 
> a
> > > écrit :
> > >
> > > > Also, for how to write comments, please look at Spring or SpringBoot
> > code
> > > > base.
> > > > Just an example file :
> > > >
> > > >
> > >
> >
> https://github.com/spring-projects/spring-framework/blob/master/spring-beans/src/main/java/org/springframework/beans/BeanUtils.java
> > > >
> > > > On Fri, Jun 5, 2020 at 4:09 PM Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com>
> > > > wrote:
> > > >
> > > > > Look at
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jun 5, 2020 at 12:46 PM Mark Struberg
> > >  > > > >
> > > > > wrote:
> > > > >
> > > > >> We intentionally removed comments which do not add any value.
> > > > >>
> > > > >> Just check the history. We deleted many @inheritdoc without any
> > > > >> additional information.
> > > > >> Or JavaDoc like /** sets the blablub */ for setBlablub();
> > > > >>
> > > > >> It just adds useless lines of code and results in 30% more code
> one
> > > has
> > > > >> to parse wh

Re: Adding Comments To Source Code

[Gurkan Erdogdu]

I again totally agree with you but think about the others. For example, I
may not be clever to understand what the code is doing without any comment.
For me, comments are as important as source code.

On Fri, Jun 5, 2020 at 4:26 PM Romain Manni-Bucau 
wrote:

> About classloader proxy:
>
> suspect I can need a more precise request - sadly I wrote this class so I
> understand it :s.
> But the only thing in this whole class is putting a proxy class in a map in
>
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java#L135
> .
> Not sure we need a comment thanks to the class name, or does the name miss
> "ClassDefiningService" explicitly?
>
> About spring: I hate this kind of codebase, you take way more time to try
> to read the comment than the code source and I never got luck I assume
> cause when I spend 5mn on the doc I always end up reading the code which
> takes way less time. Writing so much javadoc makes sense when you use the
> code as an API - our SPI is into this category and we should explain the
> expectations and requirements - but impl is not in that category at all. If
> an user uses owb-impl in his project there is an issue. Since we don't
> publish our impl modules javadoc I think it is saner to keep the comments
> for not obvious explanations - for ex
>
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/config/BeansDeployer.java#L1424
> .
>
> Hope it explains a bit where I'm coming from and what I'm hoping we target.
>
> Le ven. 5 juin 2020 à 15:21, Gurkan Erdogdu  a
> écrit :
>
> > Also, for how to write comments, please look at Spring or SpringBoot code
> > base.
> > Just an example file :
> >
> >
> https://github.com/spring-projects/spring-framework/blob/master/spring-beans/src/main/java/org/springframework/beans/BeanUtils.java
> >
> > On Fri, Jun 5, 2020 at 4:09 PM Gurkan Erdogdu 
> > wrote:
> >
> > > Look at
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java
> > >
> > >
> > >
> > > On Fri, Jun 5, 2020 at 12:46 PM Mark Struberg
>  > >
> > > wrote:
> > >
> > >> We intentionally removed comments which do not add any value.
> > >>
> > >> Just check the history. We deleted many @inheritdoc without any
> > >> additional information.
> > >> Or JavaDoc like /** sets the blablub */ for setBlablub();
> > >>
> > >> It just adds useless lines of code and results in 30% more code one
> has
> > >> to parse when reading it.
> > >> Of course, javadoc which describes WHY and HOW we do it is highly
> > welcome!
> > >>
> > >> Back in the early 2000 there have been metrics for code which misses
> > >> JavaDocs. This mantra is refuted since a long time.
> > >> I'm sure there are plenty of other tasks which make perfect sense.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> > Am 05.06.2020 um 10:48 schrieb Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com
> > >> >:
> > >> >
> > >> > Hi folks
> > >> > I am reviewing the source code, but there are codes without comments
> > in
> > >> > many places. Please can you review the codes and write comments?I
> know
> > >> this
> > >> > is boring, but commenting is very important. Otherwise, it is not
> > >> possible
> > >> > to understand what is going on in your code.
> > >> > Regards.
> > >> > Gurkan
> > >>
> > >>
> > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: [openwebbeans] branch master updated: adding a test for testing the Typed annotation with wrong value

[Gurkan Erdogdu]

>
> I don't want we start to have this pattern of importing test from elsewhere

I totally agree with that. Let me explain why I added this test case:
When I was trying to pass old TCK suites year ago, I generally created the
tests for exceptional case. Now, I have been reading the updated
Specification Document and again adapting to our code base (Happy to
remember nearly all of them I wrote :))
When I read Typed exception section, looked to source code whether to have
any test for it or not, and wrote to cover it.

In the meantime, when I want to adapt any open source project, I always
start to contribute with test cases. This is really useful practice which I
learn in my 20 years of software engineering experience.

Warm Regards.
Gurkan

On Fri, Jun 5, 2020 at 4:20 PM Romain Manni-Bucau 
wrote:

> Le ven. 5 juin 2020 à 15:02, Gurkan Erdogdu  a
> écrit :
>
> > >
> > > . you basically did nothing for the project until you increase test
> > > covering - and we are not that bad on that already + it can be hard ot
> > > review tck
> > > suite upfront. 
> > >
> > Hey Romain
> > What do you mean by that? I feel like some yelling :)
> >
>
> Feared it looked so but clearly not ;) (#mails :()
>
>
> > I have been a committer and PMC member since founding the project and
> again
> > would like to help. Contributions are always welcome for community
> projects
> > and the most quick adaptation to the any open source project is starting
> > with writing tests and even documentation.
> > As you look at the tests in webbeans-impl, you will see hundreds of tests
> > which were written by us to well cover the source code. We need to
> continue
> > for adding more tests.
> >
>
> I agree, where I disagree is about adding tests by duplicating existing
> ones. TCK are parts of our test coverage, that's a fact so we must consider
> there are there.
> If you fear - as Mark and it is a valid point - that some disappear on the
> spec, we should test on all versions (which should be BTW since it is how
> spec works) and just exclude the ones which were wrong (TCK have bugs too
> ;)).
>
> Don't get me wrong, If you work on a feature and need to duplicate a test
> to work it is fine but I don't want we start to have this pattern of
> importing test from elsewhere if we already run them, it will slow down our
> build, makes our maintenance more complicated and code review more indirect
> than it is already IMHO.
>
>
> > Warm regards.
> > Gurkan
> >
> >
> > On Fri, Jun 5, 2020 at 1:05 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > I'm not fan of that cause we will be really slower, take the time tck
> > > module runs (it is not fast even if we are faster than most impl) and
> > this
> > > is what we should duplicate if we respect that paradigm.
> > > If the "fear" is to loose test with new versions we can have profiles
> for
> > > all versions with some excludes when things changed and just run it on
> > > jenkins, then this makes useful to duplicate anything, no?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 5 juin 2020 à 11:48, Mark Struberg 
> a
> > > écrit :
> > >
> > > > Well, I'm with Gurkan here. The more tests we have internally the
> > better.
> > > > TCK tests are fine, but if we move to a new TCK version then we might
> > > miss
> > > > something.
> > > > The TCKs are also not always perfect.
> > > > We start OWB so fast that it doesn't make much difference.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > > Am 05.06.2020 um 11:39 schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >:
> > > > >
> > > > > Well, it is also bad to x2 the test time cause we duplicated the
> TCK.
> > > > > TCK are part of our test coverage and we must consider it as fully
> > part
> > > > of
> > > > > our harnessing IMHO, in particular for such simple tests, this is
> > why I
&g

Re: Adding Comments To Source Code

[Gurkan Erdogdu]

Also, for how to write comments, please look at Spring or SpringBoot code
base.
Just an example file :
https://github.com/spring-projects/spring-framework/blob/master/spring-beans/src/main/java/org/springframework/beans/BeanUtils.java

On Fri, Jun 5, 2020 at 4:09 PM Gurkan Erdogdu 
wrote:

> Look at
> https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java
>
>
>
> On Fri, Jun 5, 2020 at 12:46 PM Mark Struberg 
> wrote:
>
>> We intentionally removed comments which do not add any value.
>>
>> Just check the history. We deleted many @inheritdoc without any
>> additional information.
>> Or JavaDoc like /** sets the blablub */ for setBlablub();
>>
>> It just adds useless lines of code and results in 30% more code one has
>> to parse when reading it.
>> Of course, javadoc which describes WHY and HOW we do it is highly welcome!
>>
>> Back in the early 2000 there have been metrics for code which misses
>> JavaDocs. This mantra is refuted since a long time.
>> I'm sure there are plenty of other tasks which make perfect sense.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 05.06.2020 um 10:48 schrieb Gurkan Erdogdu > >:
>> >
>> > Hi folks
>> > I am reviewing the source code, but there are codes without comments in
>> > many places. Please can you review the codes and write comments?I know
>> this
>> > is boring, but commenting is very important. Otherwise, it is not
>> possible
>> > to understand what is going on in your code.
>> > Regards.
>> > Gurkan
>>
>>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Adding Comments To Source Code

[Gurkan Erdogdu]

Look at
https://github.com/apache/openwebbeans/blob/master/webbeans-impl/src/main/java/org/apache/webbeans/service/ClassLoaderProxyService.java



On Fri, Jun 5, 2020 at 12:46 PM Mark Struberg 
wrote:

> We intentionally removed comments which do not add any value.
>
> Just check the history. We deleted many @inheritdoc without any additional
> information.
> Or JavaDoc like /** sets the blablub */ for setBlablub();
>
> It just adds useless lines of code and results in 30% more code one has to
> parse when reading it.
> Of course, javadoc which describes WHY and HOW we do it is highly welcome!
>
> Back in the early 2000 there have been metrics for code which misses
> JavaDocs. This mantra is refuted since a long time.
> I'm sure there are plenty of other tasks which make perfect sense.
>
> LieGrue,
> strub
>
>
> > Am 05.06.2020 um 10:48 schrieb Gurkan Erdogdu  >:
> >
> > Hi folks
> > I am reviewing the source code, but there are codes without comments in
> > many places. Please can you review the codes and write comments?I know
> this
> > is boring, but commenting is very important. Otherwise, it is not
> possible
> > to understand what is going on in your code.
> > Regards.
> > Gurkan
>
>

-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: [openwebbeans] branch master updated: adding comments and cosmetic changes

[Gurkan Erdogdu]

I have removed these @inheritdoc updates.

On Fri, Jun 5, 2020 at 4:02 PM Gurkan Erdogdu 
wrote:

> OK  fine to remove @InherticDocs
> Regards.
> Gurkan
>
> On Fri, Jun 5, 2020 at 12:55 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> BIG -1 for @inherticdoc and docu like "Initialise the instance" for a
>> method called "ini"
>>
>> <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>> >
>> Virenfrei.
>> www.avast.com
>> <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>> >
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> Am Fr., 5. Juni 2020 um 11:48 Uhr schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>>
>> > -1, there is no doc in there and we dont expose the javadoc and it is
>> > actually wrong:
>> >
>> > +/**
>> > + * Auto initialization class for servers supporting
>> > + * the {@link ServletContainerInitializer}
>> > + */
>> >
>> > This is actually not the case, it is just implicit setup of OWB. Maybe
>> we
>> > should add a word in the doc about btw more than the code since it is a
>> > setup thing and not a dev thing in most cases.
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> >
>> >
>> > -- Forwarded message -
>> > De : 
>> > Date: ven. 5 juin 2020 à 11:40
>> > Subject: [openwebbeans] branch master updated: adding comments and
>> cosmetic
>> > changes
>> > To: comm...@openwebbeans.apache.org 
>> >
>> >
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > gerdogdu pushed a commit to branch master
>> > in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
>> >
>> >
>> > The following commit(s) were added to refs/heads/master by this push:
>> >  new c2b0738  adding comments and cosmetic changes
>> > c2b0738 is described below
>> >
>> > commit c2b07386e2bd9a702a4fab07696e1a0cdcb792c7
>> > Author: Gurkan Erdogdu 
>> > AuthorDate: Fri Jun 5 12:39:50 2020 +0300
>> >
>> > adding comments and cosmetic changes
>> > ---
>> >  .../se/DefaultApplicationBoundaryService.java  | 25
>> > --
>> >  .../apache/webbeans/spi/DefiningClassService.java  | 17 ---
>> >  .../servlet/WebBeansConfigurationListener.java | 22
>> > +++
>> >  3 files changed, 54 insertions(+), 10 deletions(-)
>> >
>> > diff --git
>> >
>> >
>> a/webbeans-impl/src/main/java/org/apache/webbeans/corespi/se/DefaultApplicationBoundaryService.java
>> >
>> >
>> b/webbeans-impl/src/main/java/org/apache/webbeans/corespi/se/DefaultApplicationBoundaryService.java
>> > index c2e9295..9c39d69 100644
>> > ---
>> >
>> >
>> a/webbeans-impl/src/main/java/org/apache/webbeans/corespi/se/DefaultApplicationBoundaryService.java
>> > +++
>> >
>> >
>> b/webbeans-impl/src/main/java/org/apache/webbeans/corespi/se/DefaultApplicationBoundaryService.java
>> > @@ -45,15 +45,22 @@ public class DefaultApplicationBoundaryService
>> > implements ApplicationBoundarySer
>> >   */
>> >  private Set parentClassLoaders;
>> >
>> > +/**
>> > + * Contructs a new {@link DefaultApplicationBoundaryService}
>> > + */
>> >  public DefaultApplicationBoundaryService()
>> >  {
>> >  init();
>> >  }
>> >
>> > +/**
>> > + * Initialise the instance.
>> > + */
>> >  protected void init()
>> >  {
>> >  applicationClassLoader =
>> BeanManagerImpl.class.getClassLoader();
>> >  parentClassLoaders = new HashSet<>();
>> > +
>> >  ClassLoader cl = applicationClassLoader;
>> > 

Re: [openwebbeans] branch master updated: adding a test for testing the Typed annotation with wrong value

[Gurkan Erdogdu]

>
> . you basically did nothing for the project until you increase test
> covering - and we are not that bad on that already + it can be hard ot
> review tck
> suite upfront. 
>
Hey Romain
What do you mean by that? I feel like some yelling :)
I have been a committer and PMC member since founding the project and again
would like to help. Contributions are always welcome for community projects
and the most quick adaptation to the any open source project is starting
with writing tests and even documentation.
As you look at the tests in webbeans-impl, you will see hundreds of tests
which were written by us to well cover the source code. We need to continue
for adding more tests.
Warm regards.
Gurkan


On Fri, Jun 5, 2020 at 1:05 PM Romain Manni-Bucau 
wrote:

> I'm not fan of that cause we will be really slower, take the time tck
> module runs (it is not fast even if we are faster than most impl) and this
> is what we should duplicate if we respect that paradigm.
> If the "fear" is to loose test with new versions we can have profiles for
> all versions with some excludes when things changed and just run it on
> jenkins, then this makes useful to duplicate anything, no?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 5 juin 2020 à 11:48, Mark Struberg  a
> écrit :
>
> > Well, I'm with Gurkan here. The more tests we have internally the better.
> > TCK tests are fine, but if we move to a new TCK version then we might
> miss
> > something.
> > The TCKs are also not always perfect.
> > We start OWB so fast that it doesn't make much difference.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 05.06.2020 um 11:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Well, it is also bad to x2 the test time cause we duplicated the TCK.
> > > TCK are part of our test coverage and we must consider it as fully part
> > of
> > > our harnessing IMHO, in particular for such simple tests, this is why I
> > > think we shouldnt generalize this practise.
> > >
> > > You last comment also makes me realizing we don't have an onboarding
> page
> > > on our website (we just have
> > https://openwebbeans.apache.org/community.html
> > > right?).
> > > I'm not sure writing a test is welcoming, in particular we our testing
> > > stack.
> > > I also know as a starter it is very frustrating to do so because you
> > > basically did nothing for the project until you increase test covering
> -
> > > and we are not that bad on that already + it can be hard ot review tck
> > > suite upfront. It is also something you can trivially do on your github
> > (or
> > > locally) to play with the project these days.
> > > We should probably try to define some guidelines around how to help.
> > > Out of my head I know doc can be something help would be very welcomed,
> > SPI
> > > doc can be enhanced a lot in particular, ecosystem integrations and doc
> > are
> > > things we can be better (for instance it is not obvious we run on
> > graalvm -
> > > even if there are some limitations). And we should probably flag/tag
> some
> > > jira ticket as "beginner-friendly" (or a better named tag). This
> sounds a
> > > better welcoming path to me, like "contribute something real" and "make
> > the
> > > project move forward".
> > >
> > > wdyt?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 5 juin 2020 à 10:38, Gurkan Erdogdu 
> a
> > > écrit :
> > >
> > >> One more thing: All new incomers to the project are invited to start
> > with
> > >> adding a simple test like this.
> > >>
> > >> On Fri, Jun 5, 2020 at 11:

Adding Comments To Source Code

[Gurkan Erdogdu]

Hi folks
I am reviewing the source code, but there are codes without comments in
many places. Please can you review the codes and write comments?I know this
is boring, but commenting is very important. Otherwise, it is not possible
to understand what is going on in your code.
Regards.
Gurkan

Re: [openwebbeans] branch master updated: adding a test for testing the Typed annotation with wrong value

[Gurkan Erdogdu]

One more thing: All new incomers to the project are invited to start with
adding a simple test like this.

On Fri, Jun 5, 2020 at 11:34 AM Gurkan Erdogdu 
wrote:

> Hey Romain
> In fact, this is our internal test suite not the TCK. So, it is a good
> idea to have internal tests to cover lots of spec requirements.
> Regards.
> Gurkan
>
> On Fri, Jun 5, 2020 at 8:52 AM Romain Manni-Bucau 
> wrote:
>
>> For what is worth: this is tested in TCK already
>> (RestrictedManagedBeanTest I
>> think) in an user facing way - i e CDI exception, not our internal OWB one
>> which does not have to be stable.
>> Don't know if we need to duplicate it - guess this one is fine cause fast
>> but thought I should mention it.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> -- Forwarded message -
>> De : 
>> Date: jeu. 4 juin 2020 à 22:57
>> Subject: [openwebbeans] branch master updated: adding a test for testing
>> the Typed annotation with wrong value
>> To: comm...@openwebbeans.apache.org 
>>
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> gerdogdu pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 6de6f20  adding a test for testing the Typed annotation with
>> wrong
>> value
>> 6de6f20 is described below
>>
>> commit 6de6f200f0817fc8028017800e5fdcf490496a9a
>> Author: Gurkan Erdogdu 
>> AuthorDate: Thu Jun 4 23:57:26 2020 +0300
>>
>> adding a test for testing the Typed annotation with wrong value
>> ---
>>  .../webbeans/test/injection/typed/NotInTyped.java  | 26 +
>>  .../test/injection/typed/NotInTypedTest.java   | 34
>> ++
>>  2 files changed, 60 insertions(+)
>>
>> diff --git
>>
>> a/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
>>
>> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
>> new file mode 100644
>> index 000..d5d265e
>> --- /dev/null
>> +++
>>
>> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
>> @@ -0,0 +1,26 @@
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one
>> + * or more contributor license agreements.  See the NOTICE file
>> + * distributed with this work for additional information
>> + * regarding copyright ownership.  The ASF licenses this file
>> + * to you under the Apache License, Version 2.0 (the
>> + * "License"); you may not use this file except in compliance
>> + * with the License.  You may obtain a copy of the License at
>> + *
>> + * http://www.apache.org/licenses/LICENSE-2.0
>> + *
>> + * Unless required by applicable law or agreed to in writing,
>> + * software distributed under the License is distributed on an
>> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> + * KIND, either express or implied.  See the License for the
>> + * specific language governing permissions and limitations
>> + * under the License.
>> + */
>> +package org.apache.webbeans.test.injection.typed;
>> +
>> +import javax.enterprise.inject.Typed;
>> +
>> +@Typed(Raven.class)
>> +public class NotInTyped implements Bird{
>> +
>> +}
>> diff --git
>>
>> a/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
>>
>> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
>> new file mode 100644
>> index 000..97cbdb3
>> --- /dev/null
>> +++
>>
>> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
>> @@ -0,0 +1,34 @@
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one
>> + * or more contributor license agreements.  See the NOTICE file
>> + * distributed with this work for additional information
>> + * regarding copyright ownership.  The ASF licenses this file
>> + * to you under the Apa

Re: [openwebbeans] branch master updated: adding a test for testing the Typed annotation with wrong value

[Gurkan Erdogdu]

Hey Romain
In fact, this is our internal test suite not the TCK. So, it is a good idea
to have internal tests to cover lots of spec requirements.
Regards.
Gurkan

On Fri, Jun 5, 2020 at 8:52 AM Romain Manni-Bucau 
wrote:

> For what is worth: this is tested in TCK already
> (RestrictedManagedBeanTest I
> think) in an user facing way - i e CDI exception, not our internal OWB one
> which does not have to be stable.
> Don't know if we need to duplicate it - guess this one is fine cause fast
> but thought I should mention it.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -- Forwarded message -
> De : 
> Date: jeu. 4 juin 2020 à 22:57
> Subject: [openwebbeans] branch master updated: adding a test for testing
> the Typed annotation with wrong value
> To: comm...@openwebbeans.apache.org 
>
>
> This is an automated email from the ASF dual-hosted git repository.
>
> gerdogdu pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 6de6f20  adding a test for testing the Typed annotation with wrong
> value
> 6de6f20 is described below
>
> commit 6de6f200f0817fc8028017800e5fdcf490496a9a
> Author: Gurkan Erdogdu 
> AuthorDate: Thu Jun 4 23:57:26 2020 +0300
>
> adding a test for testing the Typed annotation with wrong value
> ---
>  .../webbeans/test/injection/typed/NotInTyped.java  | 26 +
>  .../test/injection/typed/NotInTypedTest.java   | 34
> ++
>  2 files changed, 60 insertions(+)
>
> diff --git
>
> a/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
>
> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
> new file mode 100644
> index 000..d5d265e
> --- /dev/null
> +++
>
> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTyped.java
> @@ -0,0 +1,26 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership.  The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied.  See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.webbeans.test.injection.typed;
> +
> +import javax.enterprise.inject.Typed;
> +
> +@Typed(Raven.class)
> +public class NotInTyped implements Bird{
> +
> +}
> diff --git
>
> a/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
>
> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
> new file mode 100644
> index 000..97cbdb3
> --- /dev/null
> +++
>
> b/webbeans-impl/src/test/java/org/apache/webbeans/test/injection/typed/NotInTypedTest.java
> @@ -0,0 +1,34 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership.  The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied.  See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
>

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125911#comment-17125911
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

Yup, he did not remove the method in API :) I added the @deprecated to 
BeanAttributesImpl#isNull method.

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125894#comment-17125894
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

[~romain.manni-bucau] But he says he will remove and I understood that he 
deleted

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125880#comment-17125880
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

[~romain.manni-bucau] OK lets explain this way :) How are you sure that nobody 
is using isNull? there is no only TomEE but other applications/servers may use 
it. Actually, this is not a specific to OWB codebase, look Tomcat coebase(lots 
of @deprecated code any maybe they are never used but still in there). Nobody 
can remove the API methods instantly, first need to deprecate then remove. What 
is the problem with using @Deprecate? I am not against the removal, but APIs 
must not be removed immediately.

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125866#comment-17125866
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

[~romain.manni-bucau]This is an internal API but application server 
integrations may use internal APIs too. It is not logical to remove it before 
deprecation. First let the public to know it will remove shortly via 
deprecation, then remove it.

Please don't assume that interal APIs must not be used anywhere.

 

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [openwebbeans] branch master updated: adding comments and cosmetic changes

[Gurkan Erdogdu]

Hi Romain
I am going over each file slowly and commit slowly :) there is no reason
otherwise
Regards.
Gurkan

On Thu, Jun 4, 2020 at 3:04 PM Romain Manni-Bucau 
wrote:

> I would even say *it compiles in another project* (since if OWB compiles it
> does not prove it is backward compat cause i'm not sure we impl it in
> another module than the one we define it into ;))
>
> BTW any reason for this kind of commit? If you wantto do a global
> comment+generic round trip to do let's do a big fat commit, no?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 4 juin 2020 à 13:19, Gurkan Erdogdu  a
> écrit :
>
> > I don't see any problem,it compiles perfectly :)
> >
> > On Thu, Jun 4, 2020 at 1:32 PM Mark Struberg 
> > wrote:
> >
> > > did you double check compile and runtime bytecode compatibility?
> > >
> > > -protected abstract Class getMarkerInterface();
> > > +protected abstract Class getMarkerInterface();
> > >
> > > Always have to think hard about those types of changes. Seen some
> > > unpleasant surprises in the past ;)
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> > > > Am 04.06.2020 um 00:38 schrieb gerdo...@apache.org:
> > > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > gerdogdu pushed a commit to branch master
> > > > in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/master by this push:
> > > > new 91dcbf2  adding comments and cosmetic changes
> > > > new b6c1310  Merge branch 'master' of
> > > https://github.com/apache/openwebbeans
> > > > 91dcbf2 is described below
> > > >
> > > > commit 91dcbf2484c7da9aeba9a90712a4a16f8438c84f
> > > > Author: Gurkan Erdogdu 
> > > > AuthorDate: Thu Jun 4 01:25:55 2020 +0300
> > > >
> > > >adding comments and cosmetic changes
> > > > ---
> > > > .../src/main/java/org/apache/webbeans/component/OwbBean.java
>  |
> > 5
> > > +
> > > > .../main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> |
> > 2
> > > +-
> > > > .../java/org/apache/webbeans/spi/ApplicationBoundaryService.java
>  |
> > 2
> > > +-
> > > > 3 files changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git
> > >
> a/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > >
> b/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > > > index 83173c7..2e859ca 100644
> > > > ---
> > >
> a/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > > > +++
> > >
> b/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > > > @@ -96,5 +96,10 @@ public interface OwbBean extends Bean
> > > >  */
> > > > boolean isDependent();
> > > >
> > > > +
> > > > +/**
> > > > + * Gets the context instance in which this bean belongs to.
> > > > + * @return the {@link WebBeansContext} instance
> > > > + */
> > > > WebBeansContext getWebBeansContext();
> > > > }
> > > > diff --git
> > >
> >
> a/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > >
> >
> b/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > > > index 2ec4daa..8934c59 100644
> > > > ---
> > >
> >
> a/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > > > +++
> > >
> >
> b/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > > > @@ -146,7 +146,7 @@ public abstract class AbstractProxyFactory
> > > > /**
> > > >  * @return the marker interface which should be used for this
> > proxy.
> > > >  */
> > > > -protected abstract Class get

Re: [openwebbeans] branch master updated: adding comments and cosmetic changes

[Gurkan Erdogdu]

I don't see any problem,it compiles perfectly :)

On Thu, Jun 4, 2020 at 1:32 PM Mark Struberg 
wrote:

> did you double check compile and runtime bytecode compatibility?
>
> -protected abstract Class getMarkerInterface();
> +protected abstract Class getMarkerInterface();
>
> Always have to think hard about those types of changes. Seen some
> unpleasant surprises in the past ;)
>
> txs and LieGrue,
> strub
>
>
> > Am 04.06.2020 um 00:38 schrieb gerdo...@apache.org:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > gerdogdu pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 91dcbf2  adding comments and cosmetic changes
> > new b6c1310  Merge branch 'master' of
> https://github.com/apache/openwebbeans
> > 91dcbf2 is described below
> >
> > commit 91dcbf2484c7da9aeba9a90712a4a16f8438c84f
> > Author: Gurkan Erdogdu 
> > AuthorDate: Thu Jun 4 01:25:55 2020 +0300
> >
> >adding comments and cosmetic changes
> > ---
> > .../src/main/java/org/apache/webbeans/component/OwbBean.java | 5
> +
> > .../main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java| 2
> +-
> > .../java/org/apache/webbeans/spi/ApplicationBoundaryService.java | 2
> +-
> > 3 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git
> a/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> b/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > index 83173c7..2e859ca 100644
> > ---
> a/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > +++
> b/webbeans-impl/src/main/java/org/apache/webbeans/component/OwbBean.java
> > @@ -96,5 +96,10 @@ public interface OwbBean extends Bean
> >  */
> > boolean isDependent();
> >
> > +
> > +/**
> > + * Gets the context instance in which this bean belongs to.
> > + * @return the {@link WebBeansContext} instance
> > + */
> > WebBeansContext getWebBeansContext();
> > }
> > diff --git
> a/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> b/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > index 2ec4daa..8934c59 100644
> > ---
> a/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > +++
> b/webbeans-impl/src/main/java/org/apache/webbeans/proxy/AbstractProxyFactory.java
> > @@ -146,7 +146,7 @@ public abstract class AbstractProxyFactory
> > /**
> >  * @return the marker interface which should be used for this proxy.
> >  */
> > -protected abstract Class getMarkerInterface();
> > +protected abstract Class getMarkerInterface();
> >
> > /**
> >  * generate the bytecode for creating the instance variables of the
> class
> > diff --git
> a/webbeans-spi/src/main/java/org/apache/webbeans/spi/ApplicationBoundaryService.java
> b/webbeans-spi/src/main/java/org/apache/webbeans/spi/ApplicationBoundaryService.java
> > index 592d9f2..ac81045 100644
> > ---
> a/webbeans-spi/src/main/java/org/apache/webbeans/spi/ApplicationBoundaryService.java
> > +++
> b/webbeans-spi/src/main/java/org/apache/webbeans/spi/ApplicationBoundaryService.java
> > @@ -38,6 +38,6 @@ public interface ApplicationBoundaryService
> > /**
> >  * @return the ClassLoader which shall get used to e.g. proxy that
> very class.
> >  */
> > -ClassLoader getBoundaryClassLoader(Class classToProxy);
> > +ClassLoader getBoundaryClassLoader(Class classToProxy);
> >
> > }
> >
>
>

-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125836#comment-17125836
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

We need to support previous users of API (2.x) but I think that we can remove 
it with 3.0 release. We can comment to the method that this is deprecated and 
will be removed from 3.x

 

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OWB-1326) Bean#isNullable is ignored since CDI-1.1.

[Gurkan Erdogdu (Jira)]

[ 
https://issues.apache.org/jira/browse/OWB-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125791#comment-17125791
 ] 

Gurkan Erdogdu commented on OWB-1326:
-

Please don't remove the code, Deprecate it

> Bean#isNullable is ignored since CDI-1.1.
> -
>
> Key: OWB-1326
> URL: https://issues.apache.org/jira/browse/OWB-1326
> Project: OpenWebBeans
>  Issue Type: Task
>Affects Versions: 2.0.16
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.17
>
>
> Bean#isNullable is ignored since CDI-1.1. We can remove all the internal code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Release 2.0.17?

[Gurkan Erdogdu]

+1
Gurkan

On Wed, Jun 3, 2020 at 9:04 AM Romain Manni-Bucau 
wrote:

> Hi everyone,
>
> Should we release master? main changes are asm8 upgrade and last shade
> plugin support.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Regarding Provide a spy flavor of ClassDefiningService

[Gurkan Erdogdu]

Hi folks
I have put more time and energy to contribute back to OWB.

@Romain, I did see your JIRA issue as the mail subject but I don't see any
discussion regarding this in mailing list. I think first is to discuss
these experimental features in the list before creating jira and committing
the code.

Also, for future contributors to easily understand the code, we need to
have some comments on source. When I look to ClassLoaderProxyService.java,
I don't see any comments. Only it says* // runtim companion of Spy -
@Experimental. *Can you please write some comments for the class and
related methods?

My suggestion is to create a new maven project for experimental features
and not pollute the master codebase.

Regards.
Gurkan

Re: [VOTE] Apache OpenWebBeans-2.0.5

[Gurkan Erdogdu]

Thanks Mark

+1
 Gurkan

On Sunday, April 29, 2018, 1:39:57 PM GMT+3, Daniel Cunha 
 wrote:  
 
 +1

2018-04-29 5:18 GMT-03:00 Mark Struberg :

> My own +1
>
> LieGrue,
> strub
>
> > Am 29.04.2018 um 09:47 schrieb Romain Manni-Bucau  >:
> >
> > +1
> >
> > Le 29 avr. 2018 03:27, "Joseph Bergmark"  a écrit :
> >
> >> +1
> >>
> >> On Sat, Apr 28, 2018 at 4:52 PM, Mark Struberg
> 
> >> wrote:
> >>
> >>> good evening!
> >>>
> >>> I'd like to call a VOTE to release Apache OpenWebBeans-2.0.5.
> >>>
> >>> The following tickets got resolved
> >>>
> >>> Bug
> >>>        • [OWB-1233] - WrappedValueExpression.equals(Object arg0)
> always
> >>> false if arg0 is an instance of WrappedValueExpression
> >>>        • [OWB-1235] - ConversationScope destroyed upon session
> >>> serialization/deserialization
> >>>        • [OWB-1241] - Bean cache ignores qualifier model defined
> through
> >>> an AnnotatedType
> >>>
> >>> New Feature
> >>>        • [OWB-1242] - Add a configuration option to not proxy Principal
> >>>
> >>> Improvement
> >>>        • [OWB-1232] - replace warning about interceptors
> >>>        • [OWB-1238] - Our VersionVisitor shouldn't visit code
> >>>        • [OWB-1243] - improve event performance
> >>>
> >>> Task
> >>>        • [OWB-1240] - Non-static inner classes should not get picked up
> >>> as CDI Beans
> >>>
> >>> Dependency upgrade
> >>>        • [OWB-1236] - Update to XBean Asm 6 Shaded 4.7
> >>>        • [OWB-1237] - upgrade to xbean-4.8
> >>>
> >>>
> >>> The staging repo is
> >>> https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1041/
> >>>
> >>> The source distribution can be found here:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapacheopenwebbeans-1041/org/apache/openwebbeans/openwebbeans/2.0.5/
> >>>
> >>> The sha1 is 7fed2fe13879270ce17ee711232bdca55b08d83b
> >>>
> >>> The tag is https://svn.apache.org/repos/asf/openwebbeans/tags/
> >>> openwebbeans-2.0.5/
> >>> -r 1830447
> >>>
> >>> Please VOTE
> >>>
> >>> [+1] yeah, let's ship it!
> >>> [+0] meh, don't care
> >>> [-1] stop there's a ${showstopper}
> >>>
> >>> The VOTE is open for 72h
> >>>
> >>> txs and LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>
>
>


-- 
Daniel "soro" Cunha
https://twitter.com/dvlc_  

Adding Original Project Proposal to Community Page

[Gurkan Erdogdu]

Hi folksI have added the original project proposal (OpenWebBeansProposal - 
Incubator Wiki) to Community Page in 
openwebbeans-cms-site/content/community.mdtext

| 
| 
|  | 
OpenWebBeansProposal - Incubator Wiki


 |

 |

 |




How this is synched?Regards.Gurkan

Re: [VOTE] Release Apache OpenWebBeans-2.0.0

[Gurkan Erdogdu]

Hi Mark
Thanks for the release. Does this current release pass CDI Web Profile TCK? 

Regards.
Gurkan
On Monday, July 10, 2017, 2:28:39 PM GMT+3, Mark Struberg 
 wrote:

Good afternoon!

We are proud to call a VOTE on releasing Apache OpenWebBeans-2.0.0

This is an implementation of the CDI-2.0 specification (JSR-365) which just got 
released.

We already tested it with DeltaSpike, BVal and quite a few other projects, and 
it really looks fine so far!

Besides implenting CDI-2.0 the following bugs and enhancements got fixed

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844=12333257

Sub-task

    • [OWB-1185] - implement Annotated#getAnnotations
    • [OWB-1186] - update logic for bootstrapping-events
    • [OWB-1187] - implement configurators
    • [OWB-1188] - implement async events
    • [OWB-1189] - add new parts to the event-api
    • [OWB-1190] - implement java-se support
    • [OWB-1192] - update logic for Instance
    • [OWB-1193] - implement InterceptionFactory
Bug

    • [OWB-1179] - OWB-Arquillian scanner doesn't ignore classes with 
ClassNotFound and NoClassDefFound
    • [OWB-1183] - OWB-Arquillian does not supports implicit bean discovery mode
    • [OWB-1184] - arquillian connector doesn't support BDAs
    • [OWB-1196] - Signed classes can't be proxied: 
java.lang.SecurityException: class "com.Foo$$OwbNormalScopeProxy0"'s signer 
information does not match signer information of other classes in the same 
package
    • [OWB-1197] - OwbSWClassLoader creates wrong URL
Improvement

    • [OWB-1135] - Remove duplication for openwebbeans/Messages
    • [OWB-1195] - do a codestyle analysis check and apply fidings before 
releasing OWB-2.0.0
Task

    • [OWB-1087] - fix failing integration tests with java 8
    • [OWB-1182] - Implement the CDI-2.0 API



The staging repo is here
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/

The Source release can be found here
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1030/org/apache/openwebbeans/openwebbeans/2.0.0/



Please VOTE:
[+1] yeah, let's ship it
[+0] meh, don't care
[-1] no, because I found a ${showstopper}

The VOTE is open for 72h


A special thanks to all who put their hard time into making this release 
possible!

txs and LieGrue,
the Apache OpenWebBeans team

Re: Regarding Meecrowave Subproject

[Gurkan Erdogdu]

Thanks Romain.

>From my experience all the way in projects running in ASF, OW2 and some other 
>open source orgranizations, subprojects like this confuses  user and  
>developers/committers. If we need a custom microprofile based server  (or an 
>implementation of the specification which results from Microprofile group or 
>from Oracle Java EE ), we need definitely to have a new incubator project or 
>to include it into the Apache TomEE. Clearly, OpenWebBeans IMHO may not be a 
>good place for such project.
If you look at the current Meecrowave project, it contains some mix of EE 
components with integration code like Apache TomEE. In addition to duplicate 
ourselves, we may create another profile in Apache TomEE in addition to Web 
Profile, Plus, Plume and Micro Profile. We call it TomEE Microprofile. I think 
it is much more logical.
We may discuss it more of course
Thanks and Regards.
Gurkan- 

On Monday, January 9, 2017 10:26 AM, Romain Manni-Bucau 
<rmannibu...@gmail.com> wrote:
 

 Hi Gurkan,

very good question ;)

We actually debated more places - think half of the discussion was on IRC
but there was a thread there as well.

Let me try to summurize it.

First of all a quick reminder: meecrowave is first OWB+Tomcat+CXF (before
being microprofile which is just a buzz word today and doesn't mean more
than this). Said otherwise it is the core of any potential server today in
a smooth fashion (embeddable, presetup etc).

Then in term of where to do it:

- incubator: community will be OWB and/or Tomcat and/or CXF -> no point to
create a new project with the same community (we kind of get this as an
issue for several EE sub projects so we tried to avoid it)
- Tomcat: not their philosophy and goal to do more than tomcat scope
(JAX-RS and CDI are clearly out of their bounds)
- CXF: would be a good place but CDI stays core of meecrowave and not their
central knowledge yet
- TomEE: no real force there and TomEE has a few big pitfalls like being
associated with a full blown server which make most of its subprojects
eliminated before being evaluated even if not accurate
- OWB: Tomcat/OWB integration is a real plus for OWB, CXF is likely a "?"
but the CXF part is not that much in meecrowave, most of the code is
Tomcat/OWB integration and config

We had the first discusiion on http://markmail.org/thread/vh6x3u7yt6ex2fp2
IIRC




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-01-09 9:11 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.invalid>:

> Hi all
> First of all happy new year!
> As I am a founder and keen observer of the project (hope to commit much
> more time this year), I would like to ask a question regarding the new
> subproject Meecrowave. Why would we create such a sub-project under
> OpenWebBeans? From my perspective, OpenWebBeans only aim is to implement
> CDI specifications. If we would like to create a such a microprofile
> server, we may have to first write an incubator project proposal,
> http://incubator.apache.org/
> Moreover, I think that this subproject must be under developed in Apache
> TomEE, not in OpenWebBeans.
>
> Do we have any discussion about this topic in the dev or private list that
> I did not catch?
> Regards.
> Gurkan-
>
>
>
>


   

Regarding Meecrowave Subproject

[Gurkan Erdogdu]

Hi all
First of all happy new year!
As I am a founder and keen observer of the project (hope to commit much more 
time this year), I would like to ask a question regarding the new subproject 
Meecrowave. Why would we create such a sub-project under OpenWebBeans? From my 
perspective, OpenWebBeans only aim is to implement CDI specifications. If we 
would like to create a such a microprofile server, we may have to first write 
an incubator project proposal, http://incubator.apache.org/
Moreover, I think that this subproject must be under developed in Apache TomEE, 
not in OpenWebBeans. 

Do we have any discussion about this topic in the dev or private list that I 
did not catch?
Regards.
Gurkan-

Re: [VOTE] release Apache OpenWebBeans-1.7.1

[Gurkan Erdogdu]

+1
Great work thanks Mark!
I still remember the first M1 release, 2009-02-16.  

On Monday, January 2, 2017 3:03 PM, Mark Struberg 
 wrote:
 

 Hi folks!

Please VOTE for the release of Apache OpenWebBeans-1.7.1.

Staging repo:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1019/

And the source release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1019/org/apache/openwebbeans/openwebbeans/1.7.1/

My Key is in the OWB KEYS file.

Release-Notes:
Bug

    • [OWB-1150] - OSGI bundle version ranges too restrictive
    • [OWB-1154] - Synchronization on a string literal
    • [OWB-1157] - when user does a getReference of a programmatically 
registered bean without looking it up it can lead to multiple bean handling
    • [OWB-1158] - Web lifecycle not registering Servlet Context as bean
    • [OWB-1159] - HttpServletRequest not available
    • [OWB-1160] - DefaultArchiveService migh mix up BDA urls if the containing 
folder is also a cp entry
    • [OWB-1162] - CDI.current().select(X.class).select(SomeQualifier.LITERAL) 
doesn't work
    • [OWB-1163] - NPE in BeforeBeanDiscovery#addAnnotatedType if id is null
    • [OWB-1164] - Third Party Beans do not include Any qualifier if not 
included in bean impl
Improvement

    • [OWB-1151] - extend our default scan-excludes
    • [OWB-1152] - Improve compatibility and handling with Java9
    • [OWB-1153] - improve tomcat-plugin performance
    • [OWB-1156] - implement support for  feature of CDI-2.0
Task

    • [OWB-1090] - remove jsf12 module for owb-2.0


Please VOTE:
[+1] great, let's ship it
[+0] meh, don't care
[-1] stop there is a ${blocker}

The VOTE is open for 72h.


txs and LieGrue,
strub



   

Re: [VOTE] take 1: Release Apache OpenWebBeans-1.2.1

[Gurkan Erdogdu]

+1

Gurkan





On Saturday, November 9, 2013 7:38 AM, David Blevins david.blev...@gmail.com 
wrote:
 
+1

-David


On Nov 8, 2013, at 6:12 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:

 Hey guys,
 
 As discuss in another thread, I'd like to call a VOTE on releasing Apache
 OpenWebBeans-1.2.1 .
 
 This is a maintenance release of the OpenWebBeans-1.2.x branch.
 
 The ReleaseNotes are available online:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12324388
 
 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/https://www.google.com/url?q=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapacheopenwebbeans-091%2Fsa=Dsntz=1usg=AFQjCNGM7LHYZWxEZ8jBmLZO08f9vODX2Q
 
 SVN source tag:
 *http://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.1/
 http://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.1/*
 
 Source Release:
 *https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans/1.2.1/openwebbeans-1.2.1-source-release.zip
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans/1.2.1/openwebbeans-1.2.1-source-release.zip*
 
 Binary release:
 *https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans-distribution/1.2.1/openwebbeans-distribution-1.2.1-binary.zip
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-091/org/apache/openwebbeans/openwebbeans-distribution/1.2.1/openwebbeans-distribution-1.2.1-binary.zip*
 
 
 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)
 
 -- 
 Jean-Louis

Re: [E-Book Version] Apache TomEE Cookbook

[Gurkan Erdogdu]

Hello Yann

You can buy PDF version of the book from http://payhip.com/b/bsva

Best.

Gurkan




 From: Yann Blazart yann.blaz...@bycode.fr
To: us...@tomee.apache.org; Gurkan Erdogdu gurkanerdo...@yahoo.com 
Cc: u...@openwebbeans.apache.org u...@openwebbeans.apache.org; 
dev@openwebbeans.apache.org dev@openwebbeans.apache.org; 
d...@tomee.apache.org d...@tomee.apache.org 
Sent: Wednesday, August 21, 2013 4:19 PM
Subject: Re: Apache TomEE Cookbook
 

Sorry, but it's the printed version ? Where can I buy the pdf version ?


2013/8/21 Gurkan Erdogdu gurkanerdo...@yahoo.com

 Hi folks

 I have written a small cook book about Apache TomEE. My book Apache TomEE
 Cookbook published by Amazon Create Space. You can get e-book format of
 the book from http://tinyurl.com/k9rr56a

 Hard copy of the book will also be published in Amazon Strore in 5-7 days.

 Please give your feedbacks to me directly for Version-2 of the book!

 Enjoy!

June 2013 Board Report

[Gurkan Erdogdu]

Hi


Time to report.  I have written June2013 at 
https://cwiki.apache.org/confluence/display/OWB/June2013

Please have a look and add/update/delete?

Thanks,

Gurkan

Re: [VOTE] take 3: Release Apache OpenWebBeans-1.2.0

[Gurkan Erdogdu]

+1 


Gurkan




 From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev dev@openwebbeans.apache.org 
Sent: Sunday, May 19, 2013 8:49 AM
Subject: [VOTE] take 3: Release Apache OpenWebBeans-1.2.0
 

I'd like to call a 3rd take to VOTE on releasing Apache OpenWebBeans-1.2.0 .

This is the first release of the OpenWebBeans-1.2.x branch.
This release changed many internal mechanics but still targets
the CDI-1.0 specification.

Please note that the source binary contains a few non-enabled modules like
webbeans-cdi11. They do pass RAT though.


The ReleaseNotes are available online:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12315461

Maven staging repo:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/

SVN source tag:
https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.2.0/

Source Release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/org/apache/openwebbeans/openwebbeans/1.2.0/openwebbeans-1.2.0-source-release.zip

Binary release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-013/org/apache/openwebbeans/openwebbeans-distribution/1.2.0/openwebbeans-distribution-1.2.0-binary.zip

PGP release key 2FDB81B1 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

The VOTE will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 veto (and reason why)

LieGrue,
strub

Re: [VOTE] Release Apache OpenWebBeans build-tools 1.3

[Gurkan Erdogdu]

+1



 From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev dev@openwebbeans.apache.org 
Sent: Tuesday, May 14, 2013 9:45 AM
Subject: [VOTE] Release Apache OpenWebBeans build-tools 1.3
 

Hi!

This is now a split VOTE for owb-build-tools-1.3

The stating repo is up here:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-016/


The sources can be found at 

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-016/org/apache/openwebbeans/build-tools/checkstyle-rules/1.3/checkstyle-rules-1.3-source-release.zip

The tag in SVN is here

https://svn.apache.org/repos/asf/openwebbeans/build-tools/tags/checkstyle-rules-1.3/
The VOTE will be open for 72 hours. 
[ ] +1 approve 
[ ] +0 no opinion 
[ ] -1 veto (and reason why)

LieGrue,
strub

Re: [ANNOUNCE] Welcome Romain Manni-Buccau as new OWB PMC member

[Gurkan Erdogdu]

welcome a board!

Gurkan



 From: Mark Struberg strub...@yahoo.de
To: openwebbeans-user u...@openwebbeans.apache.org; openwebbeans-dev 
dev@openwebbeans.apache.org 
Sent: Monday, May 6, 2013 10:31 PM
Subject: [ANNOUNCE] Welcome Romain Manni-Buccau as new OWB PMC member
 

Hi!

The Apache OpenWebBeans PMC is happy to announce that Romain Manni-Buccau has 
joined the OWB PMC team!
Romain has earned this merrit due his long and substantial contributions in the 
EE integration part of OWB.

Welcome on board!

LieGrue,
the Apache OpenWebBeans PMC team

Yan: CDI 1.0 TCK Problem + validatePassivationDependencies

[Gurkan Erdogdu]

Hi Mark

1.1.8 branch


Broken means that it is not necessary to pass this in TCK for CDI 1.0, why this 
test exist in TCK?

Thks.


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 9 Nis 2013 21:47 Salı
Konu: Re: CDI 1.0 TCK  Problem + validatePassivationDependencies
 
because it's broken!
It's broken in the CDI-1.0 spec and we clarified the correct behaviour in 
CDI-1.1.

Btw, which branch do you speak of?

LieGrue,
strub




- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: openwebbeans-dev dev@openwebbeans.apache.org
 Cc: 
 Sent: Tuesday, April 9, 2013 11:17 AM
 Subject: CDI 1.0 TCK  Problem + validatePassivationDependencies
 
 Hi 
 
 In AbstractProducerBean below method is commented out but TCK 1.0 still 
 checks 
 ProducerMethod's Serializable return type and fields. 
 
     public void validatePassivationDependencies()
     {
     // don't call super.validatePassivationDependencies()!
     // the injection points of producers are the parameters of the 
 producermethod.
     // since CDI-1.1 we must not check those for is serializable anymore.
     }
 
 
 In CDI 1.1 this is corrected but TCK 1.0 still check this. Why is this 
 commented 
 out?
 
 
 Gurkan

CDI 1.0 TCK Problem + validatePassivationDependencies

[Gurkan Erdogdu]

Hi 

In AbstractProducerBean below method is commented out but TCK 1.0 still checks 
ProducerMethod's Serializable return type and fields. 

    public void validatePassivationDependencies()
    {
    // don't call super.validatePassivationDependencies()!
    // the injection points of producers are the parameters of the 
producermethod.
    // since CDI-1.1 we must not check those for is serializable anymore.
    }


In CDI 1.1 this is corrected but TCK 1.0 still check this. Why is this 
commented out?


Gurkan

Re: [VOTE] (take2) Release Apache OpenWebBeans 1.1.8

[Gurkan Erdogdu]

+1


 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 17 Mart 2013 19:01 Pazar
Konu: [VOTE] (take2) Release Apache OpenWebBeans 1.1.8
 

Hi!


2nd try ;)

I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.8 .

This is a bugfix release of OpenWebBeans-1.1.x, thus it's maintained in a 
maintenance branch.
 
This
release mainly contains small bugfixes. The most prominent new feature 
is the addition of the owb-arquillian-standalone adaptor for the JBoss™ 
Arquillian testing framework (which is ALv2 licensed).

The ReleaseNotes are available online: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12323873

Maven staging repo:

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/

SVN source tag:
https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.8/

Source Release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/org/apache/openwebbeans/openwebbeans/1.1.8/openwebbeans-1.1.8-source-release.zip

Binary release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-008/org/apache/openwebbeans/openwebbeans-distribution/1.1.8/openwebbeans-distribution-1.1.8-binary.tar.gz

PGP release key 2FDB81B1 
http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

The VOTE will be open for 72 hours.
[ ] +1 approve 
[ ] +0 no opinion 
[ ] -1 veto (and reason why)


LieGrue, 
strub


March 2013 Board Report

[Gurkan Erdogdu]

Hi


Time to report.  I have written March2013 at 
https://cwiki.apache.org/confluence/display/OWB/March2013

Please have a look and add/update/delete?

Thanks,

Gurkan

December 2012 Board Report

[Gurkan Erdogdu]

Hi

Time to report.  I have written December 2012 at 
https://cwiki.apache.org/confluence/display/OWB/December2012

Please have a look and add/update/delete?

Thanks,

Gurkan

Re: [VOTE] release OpenWebBeans-1.1.6

[Gurkan Erdogdu]

+1




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 5 Aralık 2012 23:24 Çarşamba
Konu: [VOTE] release OpenWebBeans-1.1.6
 
Hi!
I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.7.
This is a bugfix release of OpenWebBeans-1.1.x in the owb_1.1.x branch. It 
mainly contains compatibility/portability/performance improvements and small 
bugfixes.

The ReleaseNotes are available online: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12323362


Maven staging repo:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/


SVN source tag :
https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.7/


Source release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/org/apache/openwebbeans/openwebbeans/1.1.7/openwebbeans-1.1.7-source-release.zip


Binary release:
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-117/org/apache/openwebbeans/openwebbeans-distribution/1.1.7/openwebbeans-distribution-1.1.7-binary.tar.gz


PGP release key 2FDB81B1
http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


The VOTE will be open for 72 hours.
[ ] +1 approve 
[ ] +0 no opinion 
[ ] -1 veto (and reason why)

LieGrue, 
strub

Re: Thoughts on OWB 1.1.7 ?

[Gurkan Erdogdu]

AFAIK some fix in trunk were not ported to 1.1.7 branch. Before releasing, we 
must fix these bugs.




 Kimden: David Blevins david.blev...@gmail.com
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 27 Kasım 2012 0:52 Salı
Konu: Thoughts on OWB 1.1.7 ?
 
What's the approximate timeline on 1.1.7 ?


-David

Re: Thoughts on OWB 1.1.7 ?

[Gurkan Erdogdu]

I mean that there are some commits to TRUNK before Mark created 1.1.x branch. 
Following were committed before creating the 1.1.x branch to TRUNK but not 
ported to 1.1.x branch. We have to merge those commits to 1.1.x branch. 


Author: rmannibucau
Date: Thu Nov  8 20:51:48 2012
New Revision: 1407263

URL: http://svn.apache.org/viewvc?rev=1407263view=rev
Log:
OWB-718 oops sorry, forgot to reset an updated field for debugging purpose to a 
private field

Modified:
    
openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DelegateHandler.java

Modified: 
openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DelegateHandler.java
URL: 
http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/decorator/DelegateHandler.java?rev=1407263r1=1407262r2=1407263view=diff

Author: rmannibucau
Date: Tue Nov 13 16:25:55 2012
New Revision: 1408825

URL: http://svn.apache.org/viewvc?rev=1408825view=rev
Log:
OWB-720 trying to get generic type from superclass to get a better matching on 
injection points

Modified:
    
openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/ClassUtil.java

Modified: 
openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/ClassUtil.java
URL: 
http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/util/ClassUtil.java?rev=1408825r1=1408824r2=1408825view=diff

Author: arne
Date: Tue Nov 13 17:04:55 2012
New Revision: 1408834

URL: http://svn.apache.org/viewvc?rev=1408834view=rev
Log:
OWB-719: Changing the @Named qualifier of a bean based on the bean name

Author: gerdogdu
Date: Thu Nov 15 10:32:02 2012
New Revision: 1409721

URL: http://svn.apache.org/viewvc?rev=1409721view=rev
Log:
Enable protected fields for being extended with subclasses.

Modified:
    
openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/proxy/EjbBeanProxyHandler.java

Modified: 
openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/proxy/EjbBeanProxyHandler.java
URL: 
http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/proxy/EjbBeanProxyHandler.java?rev=1409721r1=1409720r2=1409721view=diff






 Kimden: Romain Manni-Bucau rmannibu...@gmail.com
Kime: dev@openwebbeans.apache.org; Gurkan Erdogdu gurkanerdo...@yahoo.com 
Gönderildiği Tarih: 27 Kasım 2012 12:27 Salı
Konu: Re: Thoughts on OWB 1.1.7 ?
 
Hi Gurkan,

which fixes are you thinking about?

thought it was mainly cleanup which were not ported (and these cleanup can
generate issue if badly used but no issue intrinsically)

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Gurkan Erdogdu gurkanerdo...@yahoo.com

 AFAIK some fix in trunk were not ported to 1.1.7 branch. Before releasing,
 we must fix these bugs.



 
  Kimden: David Blevins david.blev...@gmail.com
 Kime: openwebbeans-dev dev@openwebbeans.apache.org
 Gönderildiği Tarih: 27 Kasım 2012 0:52 Salı
 Konu: Thoughts on OWB 1.1.7 ?

 What's the approximate timeline on 1.1.7 ?


 -David

Re: Thoughts on OWB 1.1.7 ?

[Gurkan Erdogdu]

Hi Mark

Yeah I get your point! I do not mean that we have to port module changes to 
1.1.x branch. I just want to have other fixes that I mentioned in previous 
email in 1.1.x branch. If we will not commit these fix to branch,  these fixes 
had already been committed to the 1.2.0 TRUNK, we can release 1.2.0.M1 before 
changing lots of the things in TRUNK.  For Siwpas, these fixes are very 
important.


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 27 Kasım 2012 13:51 Salı
Konu: Re: Thoughts on OWB 1.1.7 ?
 
Hi Gurkan!

I think we should _not_ port back all changes we did on trunk. That would make 
the maintenance branch worthless.
I would e.g. not port back the SPI and module changes because that means it's 
not a drop-in replacement anymore. I have not looked at the webbeans-cluster 
stuff right now. If this is not needed for most users which do not use 
fail-over then I can imagine that it might be ok for 1.1.7 as well. It should 
at least be drop in for most of our users.


Before heading to release 1.2.0 I would like to fix our Security stuff with 
commons-privilizer. 


There are for sure a few things we need to fix in both branches. E.g. making 
the Producers stateless and remove the CreationalContext from them. 


How do we handle this in JIRA?
I propose to create a bug report for 1.2.0 and then create a clone for 1.1.7 
just for tracking commits and to be able to get a clean release report. wdyt?

Please tell us your preferences for doing a 1.2.0 release. 
So far we are still on CDI-1.0, releasing 1.2.0 with CDI-1.0 and later moving 
to 1.1 sounds a bit weird imo.

LieGrue,
strub



- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Cc: 
 Sent: Tuesday, November 27, 2012 11:19 AM
 Subject: Re: Thoughts on OWB 1.1.7 ?
 
 AFAIK some fix in trunk were not ported to 1.1.7 branch. Before releasing, we 
 must fix these bugs.
 
 
 
 
 Kimden: David Blevins david.blev...@gmail.com
 Kime: openwebbeans-dev dev@openwebbeans.apache.org 
 Gönderildiği Tarih: 27 Kasım 2012 0:52 Salı
 Konu: Thoughts on OWB 1.1.7 ?
 
 What's the approximate timeline on 1.1.7 ?
 
 
 -David

Re: Thoughts on OWB 1.1.7 ?

[Gurkan Erdogdu]

r1409751, r1409721 not ported to 1.1.x branch.  Mark, are you able to port this?




 Kimden: Romain Manni-Bucau rmannibu...@gmail.com
Kime: dev@openwebbeans.apache.org; Gurkan Erdogdu gurkanerdo...@yahoo.com 
Kopya: Mark Struberg strub...@yahoo.de 
Gönderildiği Tarih: 27 Kasım 2012 14:18 Salı
Konu: Re: Thoughts on OWB 1.1.7 ?
 
think only 1409721 was not ported, no?

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Gurkan Erdogdu gurkanerdo...@yahoo.com

 Hi Mark

 Yeah I get your point! I do not mean that we have to port module changes
 to 1.1.x branch. I just want to have other fixes that I mentioned in
 previous email in 1.1.x branch. If we will not commit these fix to branch,
 these fixes had already been committed to the 1.2.0 TRUNK, we can release
 1.2.0.M1 before changing lots of the things in TRUNK.  For Siwpas, these
 fixes are very important.


 Gurkan



 
  Kimden: Mark Struberg strub...@yahoo.de
 Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Gönderildiği Tarih: 27 Kasım 2012 13:51 Salı
 Konu: Re: Thoughts on OWB 1.1.7 ?

 Hi Gurkan!

 I think we should _not_ port back all changes we did on trunk. That would
 make the maintenance branch worthless.
 I would e.g. not port back the SPI and module changes because that means
 it's not a drop-in replacement anymore. I have not looked at the
 webbeans-cluster stuff right now. If this is not needed for most users
 which do not use fail-over then I can imagine that it might be ok for 1.1.7
 as well. It should at least be drop in for most of our users.


 Before heading to release 1.2.0 I would like to fix our Security stuff
 with commons-privilizer.


 There are for sure a few things we need to fix in both branches. E.g.
 making the Producers stateless and remove the CreationalContext from them.


 How do we handle this in JIRA?
 I propose to create a bug report for 1.2.0 and then create a clone for
 1.1.7 just for tracking commits and to be able to get a clean release
 report. wdyt?

 Please tell us your preferences for doing a 1.2.0 release.
 So far we are still on CDI-1.0, releasing 1.2.0 with CDI-1.0 and later
 moving to 1.1 sounds a bit weird imo.

 LieGrue,
 strub



 - Original Message -
  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
  To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
  Cc:
  Sent: Tuesday, November 27, 2012 11:19 AM
  Subject: Re: Thoughts on OWB 1.1.7 ?
 
  AFAIK some fix in trunk were not ported to 1.1.7 branch. Before
 releasing, we
  must fix these bugs.
 
 
 
  
  Kimden: David Blevins david.blev...@gmail.com
  Kime: openwebbeans-dev dev@openwebbeans.apache.org
  Gönderildiği Tarih: 27 Kasım 2012 0:52 Salı
  Konu: Thoughts on OWB 1.1.7 ?
 
  What's the approximate timeline on 1.1.7 ?
 
 
  -David
 

Re: Thoughts on OWB 1.1.7 ?

[Gurkan Erdogdu]

OK, I will merge these commits to 1.1.x branch from trunk. Then, no need to 
release 1.2.0

Thanks

Gurkan




 Kimden: Gurkan Erdogdu gurkanerdo...@yahoo.com
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Kopya: Mark Struberg strub...@yahoo.de 
Gönderildiği Tarih: 27 Kasım 2012 14:25 Salı
Konu: Re: Thoughts on OWB 1.1.7 ?
 
r1409751, r1409721 not ported to 1.1.x branch.  Mark, are you able to port this?




Kimden: Romain Manni-Bucau rmannibu...@gmail.com
Kime: dev@openwebbeans.apache.org; Gurkan Erdogdu gurkanerdo...@yahoo.com 
Kopya: Mark Struberg strub...@yahoo.de 
Gönderildiği Tarih: 27 Kasım 2012 14:18 Salı
Konu: Re: Thoughts on OWB 1.1.7 ?

think only 1409721 was not ported, no?

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/27 Gurkan Erdogdu gurkanerdo...@yahoo.com

 Hi Mark

 Yeah I get your point! I do not mean that we have to port module changes
 to 1.1.x branch. I just want to have other fixes that I mentioned in
 previous email in 1.1.x branch. If we will not commit these fix to branch,
 these fixes had already been committed to the 1.2.0 TRUNK, we can release
 1.2.0.M1 before changing lots of the things in TRUNK.  For Siwpas, these
 fixes are very important.


 Gurkan



 
  Kimden: Mark Struberg strub...@yahoo.de
 Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Gönderildiği Tarih: 27 Kasım 2012 13:51 Salı
 Konu: Re: Thoughts on OWB 1.1.7 ?

 Hi Gurkan!

 I think we should _not_ port back all changes we did on trunk. That would
 make the maintenance branch worthless.
 I would e.g. not port back the SPI and module changes because that means
 it's not a drop-in replacement anymore. I have not looked at the
 webbeans-cluster stuff right now. If this is not needed for most users
 which do not use fail-over then I can imagine that it might be ok for 1.1.7
 as well. It should at least be drop in for most of our users.


 Before heading to release 1.2.0 I would like to fix our Security stuff
 with commons-privilizer.


 There are for sure a few things we need to fix in both branches. E.g.
 making the Producers stateless and remove the CreationalContext from them.


 How do we handle this in JIRA?
 I propose to create a bug report for 1.2.0 and then create a clone for
 1.1.7 just for tracking commits and to be able to get a clean release
 report. wdyt?

 Please tell us your preferences for doing a 1.2.0 release.
 So far we are still on CDI-1.0, releasing 1.2.0 with CDI-1.0 and later
 moving to 1.1 sounds a bit weird imo.

 LieGrue,
 strub



 - Original Message -
  From: Gurkan Erdogdu gurkanerdo...@yahoo.com
  To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
  Cc:
  Sent: Tuesday, November 27, 2012 11:19 AM
  Subject: Re: Thoughts on OWB 1.1.7 ?
 
  AFAIK some fix in trunk were not ported to 1.1.7 branch. Before
 releasing, we
  must fix these bugs.
 
 
 
  
  Kimden: David Blevins david.blev...@gmail.com
  Kime: openwebbeans-dev dev@openwebbeans.apache.org
  Gönderildiği Tarih: 27 Kasım 2012 0:52 Salı
  Konu: Thoughts on OWB 1.1.7 ?
 
  What's the approximate timeline on 1.1.7 ?
 
 
  -David
 

Re: svn commit: r1409751 - in /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: ProxyFactory.java javassist/JavassistFactory.java

[Gurkan Erdogdu]

In siwpas application server.




 Kimden: Romain Manni-Bucau rmannibu...@gmail.com
Kime: dev@openwebbeans.apache.org 
Gönderildiği Tarih: 15 Kasım 2012 16:02 Perşembe
Konu: Re: Yan: svn commit: r1409751 - in 
/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: 
ProxyFactory.java javassist/JavassistFactory.java
 
oops, ok this map is always empty in tomeedefinitively a part of OWB to
rework ;)

For my info where do you use it? in WAS?

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*




2012/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com

 Where is the location of this code in TomEE? (ProxyFactory #
 getEjbBeanProxyClass)


 
  Kimden: Romain Manni-Bucau rmannibu...@gmail.com
 Kime: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
 Gönderildiği Tarih: 15 Kasım 2012 15:53 Perşembe
 Konu: Re: svn commit: r1409751 - in
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
 ProxyFactory.java javassist/JavassistFactory.java

 +1 we use it pretty much in TomEE

 and not sure about the argument the code is not used here so i can change
 it

 btw the separation could be reworked for sure

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*




 2012/11/15 Mark Struberg strub...@yahoo.de

  Actually that code is used in TomEE afaik. We might think about better
  separation between CDI and EJB in the end.
 
  Also this part would need unit test - another argument for creating a
 JIRA.
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Gurkan Erdogdu gurkanerdo...@yahoo.com
   To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
   Cc:
   Sent: Thursday, November 15, 2012 2:16 PM
   Subject: Re: svn commit: r1409751 - in
 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
  ProxyFactory.java javassist/JavassistFactory.java
  
   Hey Mark
  
  
   I don't think to create JIRA issues for every commit.  I think that
 this
  is
   not a big change, this method is not used in anywhere in the codebase
  and only
   used for EJB purposes. Someone removed this code while removing
 Javassist
   functionality and introduces regression. Sure to always open for a big
  changes!
  
  
   Gurkan
  
  
  
   
   Kimden: Mark Struberg strub...@yahoo.de
   Kime: dev@openwebbeans.apache.org
   dev@openwebbeans.apache.org
   Gönderildiği Tarih: 15 Kasım 2012 15:10 Perşembe
   Konu: Re: svn commit: r1409751 - in
  
 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
   ProxyFactory.java javassist/JavassistFactory.java
  
   Gurkan, please create a JIRA for all other than cosmetical changes!
   This is a pretty big change internally and really requires a JIRA
 entry.
  
   txs and LieGrue,
   strub
  
  
  
   - Original Message -
    From: gerdo...@apache.org gerdo...@apache.org
    To: comm...@openwebbeans.apache.org
    Cc:
    Sent: Thursday, November 15, 2012 1:25 PM
    Subject: svn commit: r1409751 - in
  
 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
   ProxyFactory.java javassist/JavassistFactory.java
  
    Author: gerdogdu
    Date: Thu Nov 15 12:25:17 2012
    New Revision: 1409751
  
    URL: http://svn.apache.org/viewvc?rev=1409751view=rev
    Log:
    Regression in Javassist remove updates
  
    Modified:
  
  
  
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/ProxyFactory.java
  
  
  
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/javassist/JavassistFactory.java
  
    Modified:
  
  
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/ProxyFactory.java
    URL:
  
  
 
 http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/ProxyFactory.java?rev=1409751r1=1409750r2=1409751view=diff
  
  
 
 ==
    ---
  
  
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/ProxyFactory.java
  
    (original)
    +++
  
  
 
 openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy/ProxyFactory.java
  
    Thu Nov 15 12:25:17 2012
    @@ -22,6 +22,7 @@ import java.io.Serializable;
    import java.lang.reflect.Constructor;
    import java.lang.reflect.InvocationTargetException;
    import java.lang.reflect.Type;
    +import java.util.ArrayList;
    import java.util.HashSet;
    import java.util.Iterator;
    import java.util.List

Re: svn commit: r1409751 - in /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: ProxyFactory.java javassist/JavassistFactory.java

[Gurkan Erdogdu]

Currently no plan to switch. Probably remain in using javassist.



 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 15 Kasım 2012 16:13 Perşembe
Konu: Re: svn commit: r1409751 - in 
/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: 
ProxyFactory.java javassist/JavassistFactory.java
 
Oki folks, good to know. Which means we need to take care about it in the 
future. 

Gurkan, do you plan to also switch to ASM in the middle future? Or will siwpas 
remain using javassist?

In that case we should adopt our plans and add unit/integration tests for both. 
probably via a maven profile?


LieGrue,
strub



- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Cc: 
 Sent: Thursday, November 15, 2012 3:06 PM
 Subject: Re: svn commit: r1409751 - in 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: 
 ProxyFactory.java javassist/JavassistFactory.java
 
 In siwpas application server.
 
 
 
 
 Kimden: Romain Manni-Bucau rmannibu...@gmail.com
 Kime: dev@openwebbeans.apache.org 
 Gönderildiği Tarih: 15 Kasım 2012 16:02 Perşembe
 Konu: Re: Yan: svn commit: r1409751 - in 
 /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy: 
 ProxyFactory.java javassist/JavassistFactory.java
 
 oops, ok this map is always empty in tomeedefinitively a part of OWB to
 rework ;)
 
 For my info where do you use it? in WAS?
 
 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: 
 **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*
 
 
 
 
 2012/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com
 
  Where is the location of this code in TomEE? (ProxyFactory #
  getEjbBeanProxyClass)
 
 
  
   Kimden: Romain Manni-Bucau rmannibu...@gmail.com
  Kime: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
  Gönderildiği Tarih: 15 Kasım 2012 15:53 Perşembe
  Konu: Re: svn commit: r1409751 - in
  /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
  ProxyFactory.java javassist/JavassistFactory.java
 
  +1 we use it pretty much in TomEE
 
  and not sure about the argument the code is not used here so i can 
 change
  it
 
  btw the separation could be reworked for sure
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
 
  2012/11/15 Mark Struberg strub...@yahoo.de
 
   Actually that code is used in TomEE afaik. We might think about better
   separation between CDI and EJB in the end.
  
   Also this part would need unit test - another argument for creating a
  JIRA.
  
   LieGrue,
   strub
  
  
  
  
   - Original Message -
    From: Gurkan Erdogdu gurkanerdo...@yahoo.com
    To: dev@openwebbeans.apache.org 
 dev@openwebbeans.apache.org
    Cc:
    Sent: Thursday, November 15, 2012 2:16 PM
    Subject: Re: svn commit: r1409751 - in
  
  /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
   ProxyFactory.java javassist/JavassistFactory.java
   
    Hey Mark
   
   
    I don't think to create JIRA issues for every commit.  I 
 think that
  this
   is
    not a big change, this method is not used in anywhere in the 
 codebase
   and only
    used for EJB purposes. Someone removed this code while removing
  Javassist
    functionality and introduces regression. Sure to always open for 
 a big
   changes!
   
   
    Gurkan
   
   
   
    
    Kimden: Mark Struberg strub...@yahoo.de
    Kime: dev@openwebbeans.apache.org
    dev@openwebbeans.apache.org
    Gönderildiği Tarih: 15 Kasım 2012 15:10 Perşembe
    Konu: Re: svn commit: r1409751 - in
   
  
  /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
    ProxyFactory.java javassist/JavassistFactory.java
   
    Gurkan, please create a JIRA for all other than cosmetical 
 changes!
    This is a pretty big change internally and really requires a JIRA
  entry.
   
    txs and LieGrue,
    strub
   
   
   
    - Original Message -
     From: gerdo...@apache.org 
 gerdo...@apache.org
     To: comm...@openwebbeans.apache.org
     Cc:
     Sent: Thursday, November 15, 2012 1:25 PM
     Subject: svn commit: r1409751 - in
   
  
  /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/proxy:
    ProxyFactory.java javassist/JavassistFactory.java
   
     Author: gerdogdu
     Date: Thu Nov 15 12:25:17 2012
     New Revision: 1409751
   
     URL: http://svn.apache.org/viewvc?rev=1409751view=rev

Re: 1.1.8 or 1.2.0 ?

[Gurkan Erdogdu]

+1 for 1.2.0

Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 10 Kasım 2012 17:21 Cumartesi
Konu: 1.1.8 or 1.2.0 ?
 
Hi folks!

Removing functionality from webbeans-impl into an own module + changes in the 
API might be too big a change for a bugfix release. 

So I'd rather bump the minor version as well and work towards a 1.2.0. 
This would also allow us to finish the 85% finished move to ASM as well as 
finally committing the HierarchicScannerService and HierarchicBeanManager we 
need for properly supporting EARs.

wdyt?

LieGrue,
strub

[jira] [Commented] (OWB-717) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494864#comment-13494864
 ] 

Gurkan Erdogdu commented on OWB-717:


Yes we can activate it.

 Remove Failover  implementation from Web to Own Project
 ---

 Key: OWB-717
 URL: https://issues.apache.org/jira/browse/OWB-717
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently failover logic is located in openwebbeans-web. Move failover logic 
 to its own project, openwebbeans-clustering

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-717) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494910#comment-13494910
 ] 

Gurkan Erdogdu commented on OWB-717:


I will do, no problem

 Remove Failover  implementation from Web to Own Project
 ---

 Key: OWB-717
 URL: https://issues.apache.org/jira/browse/OWB-717
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently failover logic is located in openwebbeans-web. Move failover logic 
 to its own project, openwebbeans-clustering

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OWB-717) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494913#comment-13494913
 ] 

Gurkan Erdogdu commented on OWB-717:


Done.

 Remove Failover  implementation from Web to Own Project
 ---

 Key: OWB-717
 URL: https://issues.apache.org/jira/browse/OWB-717
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently failover logic is located in openwebbeans-web. Move failover logic 
 to its own project, openwebbeans-clustering

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Method in OpenWebBeansEjbPlugin

[Gurkan Erdogdu]

+1

Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 9 Kasım 2012 23:42 Cuma
Konu: Re: Method in OpenWebBeansEjbPlugin
 
Sounds perfectly fine, but we still need some docs if we add such stuff. 
Especially if we do not use it internally.

LieGrue,
strub





- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: dev@openwebbeans.apache.org
 Cc: 
 Sent: Thursday, November 8, 2012 11:21 PM
 Subject: Re: Method in OpenWebBeansEjbPlugin
 
 Hi guys,
 
 right, you can have a quick look in openejb
 on org.apache.openejb.cdi.CdiPlugin#resolveViewMethod but you got the idea
 
 OWB doesn't know anything about EJB so it needs to ask it to somebody
 else (at least i understand this method this way ;))
 
 
 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: 
 **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*
 
 
 
 
 2012/11/8 Joseph Bergmark bergm...@gmail.com
 
  I believe this method is used to take the actual method annotated and
  find which method that corresponds to in an EJB interface.  The one
  place I see it used in the code is DefinitionUtil when its trying to
  determine the producer/disposer methods.  I believe the concern is the
  proxy that is built by the EJB container can only validly be called
  from methods on the interface but not the method from the concrete
  class (unless it is a NIV EJB).
 
  svn blame seems to hint that David changed these lines most recently,
  so I would defer to him on this.
 
  Sincerely,
 
  Joe
 
  On Thu, Nov 8, 2012 at 3:50 AM, Gurkan Erdogdu 
 gurkanerdo...@yahoo.com
  wrote:
   Hello
  
   There is a method Method resolveViewMethod(Bean? 
 component, Method
  declaredMethod); in OpenWebBeansEjbPlugin? What is the meaning of 
 this
  method? No comment there.
  
  
   Gurkan
 

[jira] [Created] (OWB-715) Remove EL22 implementation from Core to Own Project

[Gurkan Erdogdu (JIRA)]

Gurkan Erdogdu created OWB-715:
--

 Summary: Remove EL22 implementation from Core to Own Project
 Key: OWB-715
 URL: https://issues.apache.org/jira/browse/OWB-715
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core, Java EE Integration
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7


Currently EL 2.2 integration code is located in the openwebbeans-impl project. 
It is more reasonable to include EL 2.2 integration into its own project and 
use only SPI logic in core.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OWB-715) Remove EL22 implementation from Core to Own Project

[Gurkan Erdogdu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu resolved OWB-715.


Resolution: Fixed

Fixed.

 Remove EL22 implementation from Core to Own Project
 ---

 Key: OWB-715
 URL: https://issues.apache.org/jira/browse/OWB-715
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core, Java EE Integration
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently EL 2.2 integration code is located in the openwebbeans-impl 
 project. It is more reasonable to include EL 2.2 integration into its own 
 project and use only SPI logic in core.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Deleted] (OWB-716) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu deleted OWB-716:
---


 Remove Failover  implementation from Web to Own Project
 ---

 Key: OWB-716
 URL: https://issues.apache.org/jira/browse/OWB-716
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently EL 2.2 integration code is located in the openwebbeans-impl 
 project. It is more reasonable to include EL 2.2 integration into its own 
 project and use only SPI logic in core.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OWB-716) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

Gurkan Erdogdu created OWB-716:
--

 Summary: Remove Failover  implementation from Web to Own Project
 Key: OWB-716
 URL: https://issues.apache.org/jira/browse/OWB-716
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core, Java EE Integration
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7


Currently EL 2.2 integration code is located in the openwebbeans-impl project. 
It is more reasonable to include EL 2.2 integration into its own project and 
use only SPI logic in core.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OWB-717) Remove Failover implementation from Web to Own Project

[Gurkan Erdogdu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu reassigned OWB-717:
--

Assignee: Gurkan Erdogdu

 Remove Failover  implementation from Web to Own Project
 ---

 Key: OWB-717
 URL: https://issues.apache.org/jira/browse/OWB-717
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.7
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.1.7


 Currently failover logic is located in openwebbeans-web. Move failover logic 
 to its own project, openwebbeans-clustering

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] release Apache OpenWebBeans build tools 1.2

[Gurkan Erdogdu]

+1




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 16 Eylül 2012 23:58 Pazar
Konu: [VOTE] release Apache OpenWebBeans build tools 1.2
 


Hi!  


I'd like to call a VOTE on releasing Apache OpenWebBeans build-tools-1.2. 
This release is needed for shipping OWB.


We just relaxed the method length rules a bit.Maven staging repo: 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/


SVN source tag:
https://svn.apache.org/repos/asf/openwebbeans/build-tools/tags/checkstyle-rules-1.2/

Source release: 

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/build-tools/checkstyle-rules/1.2/checkstyle-rules-1.2-source-release.zip

PGP release key 2FDB81B1 
http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


The VOTE will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 veto (and reason why) 



LieGrue,
strub

September 2012 Board Report

[Gurkan Erdogdu]

Hi



Time to report.  I have written September 2012 at 
https://cwiki.apache.org/confluence/display/OWB/September2012

Please have a look and add/update/delete?

Thanks,

Gurkan

Yan: September 2012 Board Report

[Gurkan Erdogdu]

Hello Joe

Maybe a permission problem but I do not know!. Please send email to infra@ 
to get correct answer


Gurkan




 Kimden: Joseph Bergmark bergm...@apache.org
Kime: dev@openwebbeans.apache.org 
Gönderildiği Tarih: 10 Eylül 2012 17:24 Pazartesi
Konu: Re: September 2012 Board Report
 
For some reason I can't log in to that page using my apache
name/password.  Do we need to request something separate, or am I
missing some needed permissions?

Sincerely,

Joe

On Mon, Sep 10, 2012 at 10:22 AM, Mark Struberg strub...@yahoo.de wrote:
 perfectly fine.

 txs and LieGrue,
 strub




 - Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Cc:
 Sent: Monday, September 10, 2012 3:35 PM
 Subject: September  2012 Board Report

 Hi



 Time to report.  I have written September 2012 at
 https://cwiki.apache.org/confluence/display/OWB/September2012

 Please have a look and add/update/delete?

 Thanks,

 Gurkan

Yan: javassist removal

[Gurkan Erdogdu]

Hello David

I favor that we can implement a common SPI like other integrations and refactor 
code to use SPI (Pluggable way of using javassist or ASM). 


Thanks.


Gurkan




 Kimden: David Blevins david.blev...@gmail.com
Kime: dev@openwebbeans.apache.org 
Gönderildiği Tarih: 9 Ağustos 2012 7:27 Perşembe
Konu: javassist removal
 
Hey All,

Heads up that I'd like to investigate removing javassist and replacing it with 
some simple ASM code to create subclass based proxies.  The proxy code is the 
small part, the bigger part is refactoring out the MethodHandler classes and 
replacing them with java.lang.reflect.InvocationHandler implementations.

As usual I'll probably look for an intermediary step in refactoring it out, 
maybe some way to keep the MethodHandlers and get all the code working with a 
different proxy impl, then refactor the handlers.

Any thoughts or comments welcome.


-David

Yan: ApacheCon Germany

[Gurkan Erdogdu]

Great all  team there! 


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 6 Ağustos 2012 16:15 Pazartesi
Konu: Re: ApacheCon Germany
 
Hi Gurkan!

Gerhard, David, Romain, Jean-Louis and me will be there. Most probably also a 
few others.Would be great to meet you there as well!

LieGrue,
strub

- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: openwebbeans-dev dev@openwebbeans.apache.org
 Cc: 
 Sent: Monday, August 6, 2012 2:40 PM
 Subject: ApacheCon Germany
 
 Hello folks
 
 
 Is anyone here attending conference in Germany? 
 
 
 Gurkan
 

June 2012 Board Report

[Gurkan Erdogdu]

Hi


Time to report.  I have written March 2012 at 
https://cwiki.apache.org/confluence/display/OWB/June2012

Please have a look and add/update/delete?

Thanks,

Gurkan

Re : [VOTE] take2 Release Apache OpenWebBeans-1.1.4

[Gurkan Erdogdu]

+1

Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 5 Nis 2012 13:23 Perşembe
Konu: [VOTE] take2 Release Apache OpenWebBeans-1.1.4
 
Hi! 

I'd like to call a second VOTE on releasing Apache OpenWebBeans-1.1.4 .


I've now fixed the picking up of the atinject-tck and docs.


This
is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been 
created. It mainly contains compatibility/portability/performance 
improvements and small bugfixes.

The ReleaseNotes are available online: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12319171

Maven staging repo:

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/

SVN source tag (1309727):

https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.4/

Source release:

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/org/apache/openwebbeans/openwebbeans/1.1.4/openwebbeans-1.1.4-source-release.zip

Binary release:

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-007/org/apache/openwebbeans/openwebbeans-distribution/1.1.4/openwebbeans-distribution-1.1.4-binary.tar.gz

PGP release key 2FDB81B1

http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS

The VOTE will be open for 72 hours. 
[ ] +1 approve 
[ ] +0 no opinion 
[ ] -1 veto (and reason why)

LieGrue,
strub 

Re: [ANNOUNCE] Welcome Romain Manni-Bucau as new Committer!

[Gurkan Erdogdu]

Welcome on board Romain!

Gurkan



 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org; 
u...@openwebbeans.apache.org u...@openwebbeans.apache.org 
Gönderildiği Tarih: 12 Mart 2012 9:23 Pazartesi
Konu: [ANNOUNCE] Welcome Romain Manni-Bucau as new Committer!
 
All, 

The OpenWebBeans PMC is pleased to announce that Romain Manni-Bucau has 
accepted our invitation to join the OpenWebBeans project as a 
committer. 

Congratulations and welcome Romain!

the OpenWebBeans PMC

Re: OpenWebBeans meets Eclipse RCP

[Gurkan Erdogdu]

Cool project :)

Thanks.


Gurkan.




 Kimden: Jakob Korherr jakob.korh...@gmail.com
Kime: dev@openwebbeans.apache.org 
Gönderildiği Tarih: 9 Mart 2012 15:25 Cuma
Konu: OpenWebBeans meets Eclipse RCP
 
Hi guys,

Last year I had to do a project at university using Eclipse RCP.
Frankly, the Eclipse framework kinda sucked. Thus I tried to pimp
Eclipse RCP a little bit, which means I wanted to use OWB and CODI.

After some time I figured out how to combine OWB and Eclipse RCP
thanks to the excellent plugin system of OWB. Now I finally found some
time to put the relevant classes online. You can find the project at
apache-extras: 
http://code.google.com/a/apache-extras.org/p/openwebbeans-eclipse-rcp/

Please note: Although this is a maven project, I was not able to
really build it with maven, b/c I couldn't find a way to get all the
relevant eclipse jars into a maven repo. If you want to use it, the
best way is to copy the source files directly into your Eclipse RCP
project.

Regards,
Jakob

-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Yan: Which JAX-WS/RS implementation with OWB?

[Gurkan Erdogdu]

Hi Thomas

OWB does not implement/provide any WS functionality. You can look at Apache 
Wink for JAX-RS from http://incubator.apache.org/wink/


Thanks

Gurkan




 Kimden: Thomas Andraschko zoi...@googlemail.com
Kime: dev@openwebbeans.apache.org 
Gönderildiği Tarih: 31 Ocak 2012 17:24 Salı
Konu: Which JAX-WS/RS implementation with OWB?
 
Hi,

which JAX-WS  RS implementation works with OWB/CDI? Which is the preferred
one?
Is there a sample available?

Thanks,
Thomas

Yan: [VOTE] drop outdated (and unused) openwebbeans-openejb plugin

[Gurkan Erdogdu]

+1.

I implemented it for experimental OpenEJB + CDI usage. It has done its job 
well. We can drop it!

Thks.


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org 
Gönderildiği Tarih: 27 Aralık 2011 21:08 Salı
Konu: [VOTE] drop outdated (and unused) openwebbeans-openejb plugin
 
Hi!

I was made aware by David that our openwebbeans-openejb plugin is 


a.) not needed anymore because the OpenEJB project maintains a much deeper 
integration already
b.) It doesn't even compile against the latest trunk anymore, because 
DeploymentInfo got removed.

Thus I hereby ask to drop the openwebbeans-openejb plugin form our SVN repo.

Anyone using it?



[+1] get rid of it, it is just broken and not used anymore

[+0] I don't care

[-1] nope I'm using it and it must remain maintained


The VOTE is open for 72h with lazy consensus.


here is my 


+1 for dropping it


LieGrue,
strub

Yan: [VOTE] Release Apache OpenWebBeans-1.1.3

[Gurkan Erdogdu]

+1

PS: It is unnecessary to send vote to user@... group

Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: openwebbeans-dev dev@openwebbeans.apache.org; 
u...@openwebbeans.apache.org u...@openwebbeans.apache.org 
Gönderildiği Tarih: 3 Aralık 2011 15:07 Cumartesi
Konu: [VOTE] Release Apache OpenWebBeans-1.1.3
 

Hi! 

I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.3 . 


This is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been created.
It mainly contains compatibility/portability improvements and small bugfixes. 

The ReleaseNotes are available online:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12318845


Maven staging repo: 

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/


SVN source tag (1209899): 

https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.3/


Source release: 

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/org/apache/openwebbeans/openwebbeans/1.1.3/openwebbeans-1.1.3-source-release.zip


Binary release: 

https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/org/apache/openwebbeans/openwebbeans-distribution/1.1.3/openwebbeans-distribution-1.1.3-binary.tar.gz


PGP release key 2FDB81B1 

http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS


The VOTE will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 veto (and reason why) 


LieGrue,
strub

Yan: Yan: [VOTE] Release Apache OpenWebBeans-1.1.3

[Gurkan Erdogdu]

Just concerning on rules for mailing lists, do not cross-post.

for example, below is excerpted from http://struts.apache.org/mail.html

Respect the mailing list type  
* The User list is where you can send questions and comments about 
configuration, setup, usage and other user types of questions. 
* The Developer (or Dev) list is where you can send questions and 
comments about the actual software source code and general development types 
of questions. Questions about the future of Struts are best addressed to the 
dev list. 
Some questions may seem appropriate for posting on both the user and the 
developer lists. In this case, pick one and only one. Do not cross post, 
unless a Committer asks that the thread be moved to the other list. 

Actually I got the feedback that even people from distantly associated 
projects like MyFaces, OpenEJB and Geronimo are interested in a VOTE 
being in progress
Then they can register to dev@ list.


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 4 Aralık 2011 14:50 Pazar
Konu: Re: Yan: [VOTE] Release Apache OpenWebBeans-1.1.3
 
I don't think so. 


The more the merrier ^^


Actually I got the feedback that even people from distantly associated projects 
like MyFaces, OpenEJB and Geronimo are interested in a VOTE being in progress.

LieGrue,
strub


- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Cc: 
 Sent: Sunday, December 4, 2011 1:08 PM
 Subject: Yan: [VOTE] Release Apache OpenWebBeans-1.1.3
 
 +1
 
 PS: It is unnecessary to send vote to user@... group
 
 Gurkan
 
 
 
 
 Kimden: Mark Struberg strub...@yahoo.de
 Kime: openwebbeans-dev dev@openwebbeans.apache.org; 
 u...@openwebbeans.apache.org u...@openwebbeans.apache.org 
 Gönderildiği Tarih: 3 Aralık 2011 15:07 Cumartesi
 Konu: [VOTE] Release Apache OpenWebBeans-1.1.3
 
 
 Hi! 
 
 I'd like to call a VOTE on releasing Apache OpenWebBeans-1.1.3 . 
 
 
 This is a bugfix release of OpenWebBeans-1.1.x, thus no branch has been 
 created.
 It mainly contains compatibility/portability improvements and small bugfixes. 
 
 The ReleaseNotes are available online:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310844version=12318845
 
 
 Maven staging repo: 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/
 
 
 SVN source tag (1209899): 
 
 https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.3/
 
 
 Source release: 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/org/apache/openwebbeans/openwebbeans/1.1.3/openwebbeans-1.1.3-source-release.zip
 
 
 Binary release: 
 
 https://repository.apache.org/content/repositories/orgapacheopenwebbeans-291/org/apache/openwebbeans/openwebbeans-distribution/1.1.3/openwebbeans-distribution-1.1.3-binary.tar.gz
 
 
 PGP release key 2FDB81B1 
 
 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
 
 
 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why) 
 
 
 LieGrue,
 strub

Yan: 1.2 Branch

[Gurkan Erdogdu]

Hi Mark

CDI 1.1 adds new functions and introduces new APIs. We can not add these to OWB 
1.1.x, therefore we have to branch if we want to implement these features. 


OK for just updating OWB-1.1.x codebase for some simple clarifications but not 
for new functionalites.We can add mature CDI 1.1 spec items (hardly to change) 
to OWB 1.2. 


Gurkan




 Kimden: Mark Struberg strub...@yahoo.de
Kime: dev@openwebbeans.apache.org dev@openwebbeans.apache.org 
Gönderildiği Tarih: 4 Aralık 2011 16:15 Pazar
Konu: Re: 1.2 Branch
 
Hi Gurkan!

I'm on the EG and we are still heavily changing the draft!
We even already reverted/changed a lot stuff which made it into the EDR after 
reviewing the pieces.

Imo it's still too early to adopt it. 

As I already wrote 3 months ago, I'm already in the process of incorporating 
1.0 API compatible clarifications and changes into owb-1.1.x

Actually owb already contains a hell lot of that stuff!

Also there is atm not really much I desperately miss in 1.0 from the 1.1 spec. 
Most of the work currently done have been clarifications!


LieGrue,
strub



- Original Message -
 From: Gurkan Erdogdu gurkanerdo...@yahoo.com
 To: dev@openwebbeans.apache.org dev@openwebbeans.apache.org
 Cc: 
 Sent: Sunday, December 4, 2011 3:05 PM
 Subject: 1.2 Branch
 
 Hi folks,
 
 I think that time has arrived to create 1.2 branch. 1.2 branch will implement 
 CDI 1.1 specification that EDR has already been published.
 
 
 Gurkan