Merging JSR-330 into CDI

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Merging JSR-330 into CDI

Manfred Riem
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Reza Rahman
I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process.

BTW, it is really great to see you active in the community!

> On Mar 19, 2016, at 10:49 AM, Manfred Riem <[hidden email]> wrote:
>
> Hi all,
>
> I wrote a little blog entry about a CDI wish I have and in essence it comes
> down to merging JSR-330 into the CDI specification as a sub spec. I realize
> there is history there, but to me it looks like the best course of action.
>
> I had some twitter exchanges about this and some folks are for, some are
> against.
>
> Note I think this is worth exploring as an idea, not something that
> necessarily needs to be in the current JSR, but definitely something that I
> think is worth to do at some point (sooner rather than later in my book).
>
> What do you think?
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
>
>
> --
> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

aalmiray
In reply to this post by Manfred Riem
How would this move affect existing implementations, such as Guice, Springframework, Dagger, Afterburner, Griffon, etc? These implementations rely on a tiny core (the small JSR-330 JAR file) and nothing more.

What are the foreseeable consequences of such move (as a subspec)?

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Reza Rahman
They could certainly support the smallest CDI module/profile. The way the proposal looks, it should be pretty tiny and almost just the same as JSR 330.

> On Mar 19, 2016, at 11:57 AM, aalmiray <[hidden email]> wrote:
>
> How would this move affect existing implementations, such as Guice,
> Springframework, Dagger, Afterburner, Griffon, etc? These implementations
> rely on a tiny core (the small JSR-330 JAR file) and nothing more.
>
> What are the foreseeable consequences of such move (as a subspec)?
>
> Cheers,
> Andres
>
>
>
> --
> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712812.html
> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Manfred Riem
In reply to this post by Reza Rahman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Stephan Knitelius
If I understand you correctly, you are suggesting to move the JSR-330 annotations into a separate CDI module/profile, thereby semi-deprecating these.

This would essentially open up the possibility of replacing @Named, etc... with CDI specific annotations.

Certainly an interesting path to explore.

Stephan


On Sa., 19. März 2016 at 19:27, Manfred Riem <[hidden email]> wrote:
I couldn't agree more ;)

Thanks!

Kind regards,
Manfred Riem

> On Mar 19, 2016, at 10:47 AM, Reza Rahman <[hidden email]> wrote:
>
> I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process.
>
> BTW, it is really great to see you active in the community!
>
>> On Mar 19, 2016, at 10:49 AM, Manfred Riem <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I wrote a little blog entry about a CDI wish I have and in essence it comes
>> down to merging JSR-330 into the CDI specification as a sub spec. I realize
>> there is history there, but to me it looks like the best course of action.
>>
>> I had some twitter exchanges about this and some folks are for, some are
>> against.
>>
>> Note I think this is worth exploring as an idea, not something that
>> necessarily needs to be in the current JSR, but definitely something that I
>> think is worth to do at some point (sooner rather than later in my book).
>>
>> What do you think?
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>>
>> --
>> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Manfred Riem
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

aalmiray
Precisely my thoughts. Any changes in behavior / binary compatibility in JSR-330 must be discussed with the JSR-330 EG and stakeholders.

This being said, what would be the real benefit (to both specs) of rolling JSR-330 as a subspec of CDI?

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Stephan Knitelius
In reply to this post by Manfred Riem
Hi Manfred,

sorry my replay was a bit out of context since, I was referring to Rezas last mail.

As already discussed yesterday, this could proof difficult. Since there are other implementations based on JSR-330, most noticeably spring.

What exactly are we looking to gain from integrating JSR-330?

I agree it would be "cleaner", but maybe too much effort for too little gain.

If we wanted greater control over those parts, maybe it would be better to move these parts into a separate module for backwards compatibility.
Including new CDI owned annotations alongside the separated JSR-330, as and where sensible.

Stephan


On Sa., 19. März 2016 at 20:40, Manfred Riem <[hidden email]> wrote:
Hi Stephan,

I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as it currently
stands. Anything beyond that is beyond the scope of the discussion/wish I have as that
would then be decided by the combined EG.

Thanks!

King regards,
Manfred Riem


On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <[hidden email]> wrote:

If I understand you correctly, you are suggesting to move the JSR-330 annotations into a separate CDI module/profile, thereby semi-deprecating these.

This would essentially open up the possibility of replacing @Named, etc... with CDI specific annotations.

Certainly an interesting path to explore.

Stephan


On Sa., 19. März 2016 at 19:27, Manfred Riem <[hidden email]> wrote:
I couldn't agree more ;)

Thanks!

Kind regards,
Manfred Riem

> On Mar 19, 2016, at 10:47 AM, Reza Rahman <[hidden email]> wrote:
>
> I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process.
>
> BTW, it is really great to see you active in the community!
>
>> On Mar 19, 2016, at 10:49 AM, Manfred Riem <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I wrote a little blog entry about a CDI wish I have and in essence it comes
>> down to merging JSR-330 into the CDI specification as a sub spec. I realize
>> there is history there, but to me it looks like the best course of action.
>>
>> I had some twitter exchanges about this and some folks are for, some are
>> against.
>>
>> Note I think this is worth exploring as an idea, not something that
>> necessarily needs to be in the current JSR, but definitely something that I
>> think is worth to do at some point (sooner rather than later in my book).
>>
>> What do you think?
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>>
>> --
>> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

arjan tijms
Hi,

On Saturday, March 19, 2016, Stephan Knitelius <[hidden email]> wrote:
Hi Manfred,

sorry my replay was a bit out of context since, I was referring to Rezas last mail.

As already discussed yesterday, this could proof difficult. Since there are other implementations based on JSR-330, most noticeably spring. 

Wound anything really change for other implementations technically?

AtInject 1.0 will stay as it is, but newer versions of it will be done as sub-spec of CDI, right?

If those other implementations do not want changes in AtInject then things can stay as they are, and if they do want changes they can ask the CDI EG, which is active. 

If it's a sub-spec, I guess just the sub-spec can be officially implemented (like Hibernate implemented just sub-spec JPA which was initially part of EJB).

But have those other implementations ever asked for changes?

Kind regards,
Arjan Tijms

 

What exactly are we looking to gain from integrating JSR-330?

I agree it would be "cleaner", but maybe too much effort for too little gain.

If we wanted greater control over those parts, maybe it would be better to move these parts into a separate module for backwards compatibility.
Including new CDI owned annotations alongside the separated JSR-330, as and where sensible.

Stephan


On Sa., 19. März 2016 at 20:40, Manfred Riem <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;mnriem@gmail.com&#39;);" target="_blank">mnriem@...> wrote:
Hi Stephan,

I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as it currently
stands. Anything beyond that is beyond the scope of the discussion/wish I have as that
would then be decided by the combined EG.

Thanks!

King regards,
Manfred Riem


On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;stephan@knitelius.com&#39;);" target="_blank">stephan@...> wrote:

If I understand you correctly, you are suggesting to move the JSR-330 annotations into a separate CDI module/profile, thereby semi-deprecating these.

This would essentially open up the possibility of replacing @Named, etc... with CDI specific annotations.

Certainly an interesting path to explore.

Stephan


On Sa., 19. März 2016 at 19:27, Manfred Riem <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;mnriem@gmail.com&#39;);" target="_blank">mnriem@...> wrote:
I couldn't agree more ;)

Thanks!

Kind regards,
Manfred Riem

> On Mar 19, 2016, at 10:47 AM, Reza Rahman <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;reza_rahman@lycos.com&#39;);" target="_blank">reza_rahman@...> wrote:
>
> I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process.
>
> BTW, it is really great to see you active in the community!
>
>> On Mar 19, 2016, at 10:49 AM, Manfred Riem <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;mnriem@gmail.com&#39;);" target="_blank">mnriem@...> wrote:
>>
>> Hi all,
>>
>> I wrote a little blog entry about a CDI wish I have and in essence it comes
>> down to merging JSR-330 into the CDI specification as a sub spec. I realize
>> there is history there, but to me it looks like the best course of action.
>>
>> I had some twitter exchanges about this and some folks are for, some are
>> against.
>>
>> Note I think this is worth exploring as an idea, not something that
>> necessarily needs to be in the current JSR, but definitely something that I
>> think is worth to do at some point (sooner rather than later in my book).
>>
>> What do you think?
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>>
>> --
>> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> Sent from the CDI Development mailing list mailing list archive at Nabble.com.
>> _______________________________________________
>> cdi-dev mailing list
>> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Werner Keil-2
In reply to this post by Manfred Riem
Keeping the few annotations like @Inject as they are should be also in CDI's interest, but as JSR 330 is final there is no EG. Unlike this EG and mailing list with great participation, there has never been too much of an EG even when 330 was active, it was more or less Bob and maybe a few participants in the mailing lists. That activity stopped in 2011, see https://groups.google.com/forum/?hl=de#!forum/atinject-observer, so the EG pretty much died 5 years ago. 

It seems reasonable and natural to do changes or tweaks as part of CDI.

Werner



On Sat, Mar 19, 2016 at 9:35 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Merging JSR-330 into CDI (aalmiray)
   2. Re: Merging JSR-330 into CDI (Stephan Knitelius)
   3. Re: @ThreadScoped? (Stephan Knitelius)


----------------------------------------------------------------------

Message: 1
Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST)
From: aalmiray <[hidden email]>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

Precisely my thoughts. Any changes in behavior / binary compatibility in
JSR-330 must be discussed with the JSR-330 EG and stakeholders.

This being said, what would be the real benefit (to both specs) of rolling
JSR-330 as a subspec of CDI?

Cheers,
Andres



--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712817.html
Sent from the CDI Development mailing list mailing list archive at Nabble.com.


------------------------------

Message: 2
Date: Sat, 19 Mar 2016 19:53:13 +0000
From: Stephan Knitelius <[hidden email]>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: Manfred Riem <[hidden email]>
Cc: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi Manfred,

sorry my replay was a bit out of context since, I was referring to Rezas
last mail.

As already discussed yesterday, this could proof difficult. Since there are
other implementations based on JSR-330, most noticeably spring.

What exactly are we looking to gain from integrating JSR-330?

I agree it would be "cleaner", but maybe too much effort for too little
gain.

If we wanted greater control over those parts, maybe it would be better to
move these parts into a separate module for backwards compatibility.
Including new CDI owned annotations alongside the separated JSR-330, as and
where sensible.

Stephan


On Sa., 19. M?rz 2016 at 20:40, Manfred Riem <[hidden email]> wrote:

> Hi Stephan,
>
> I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as
> it currently
> stands. Anything beyond that is beyond the scope of the discussion/wish I
> have as that
> would then be decided by the combined EG.
>
> Thanks!
>
> King regards,
> Manfred Riem
>
>
> On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <[hidden email]>
> wrote:
>
> If I understand you correctly, you are suggesting to move the JSR-330
> annotations into a separate CDI module/profile, thereby semi-deprecating
> these.
>
> This would essentially open up the possibility of replacing @Named, etc...
> with CDI specific annotations.
>
> Certainly an interesting path to explore.
>
> Stephan
>
>
> On Sa., 19. M?rz 2016 at 19:27, Manfred Riem <[hidden email]> wrote:
>
>> I couldn't agree more ;)
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> > On Mar 19, 2016, at 10:47 AM, Reza Rahman <[hidden email]>
>> wrote:
>> >
>> > I definitely think it's an idea worth exploring. It will strengthen
>> CDI's hand further. It will be great if some of the confusingly redundant
>> APIs like @Singleton could be deprecated in the process.
>> >
>> > BTW, it is really great to see you active in the community!
>> >
>> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem <[hidden email]> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I wrote a little blog entry about a CDI wish I have and in essence it
>> comes
>> >> down to merging JSR-330 into the CDI specification as a sub spec. I
>> realize
>> >> there is history there, but to me it looks like the best course of
>> action.
>> >>
>> >> I had some twitter exchanges about this and some folks are for, some
>> are
>> >> against.
>> >>
>> >> Note I think this is worth exploring as an idea, not something that
>> >> necessarily needs to be in the current JSR, but definitely something
>> that I
>> >> think is worth to do at some point (sooner rather than later in my
>> book).
>> >>
>> >> What do you think?
>> >>
>> >> Thanks!
>> >>
>> >> Kind regards,
>> >> Manfred Riem
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> >> Sent from the CDI Development mailing list mailing list archive at
>> Nabble.com <http://nabble.com>.
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >> [hidden email]
>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>
>> >> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment-0001.html

------------------------------

Message: 3
Date: Sat, 19 Mar 2016 20:35:29 +0000
From: Stephan Knitelius <[hidden email]>
Subject: Re: [cdi-dev] @ThreadScoped?
To: Mark Struberg <[hidden email]>, Reza Rahman
        <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

I would certainly agree with the assertion that in general it's not
advisable to execute a request with multiple threads and that usually
single threaded execution is sufficient.

However I don't think ignoring it is an option. Concurrent operations can
be launched even from CDI beans. Yet we don't properly support context
propagation nor a context spanning all threads launched from a request.

I know that changing @requestScoped is probably out of the question, but at
least we should consider adding a new context spanning all threads and
defining a logical solution for context propagation that can be explained
to the end user.



On Fr., 11. M?rz 2016 at 17:17, Mark Struberg <[hidden email]> wrote:

> Yes, but certain things in EE are assumed to be handled on a single
> thread. And if you run on a servr then this is really not a blocker most
> times. If I get many paralllel requests hitting my box then I do not need
> async handling _that_ often. The whole overhead for setting up the new
> thread, etc often heavily exceeds the benefits.
> So I would not put too much energy into it?
>
> LieGrue,
> strub
>
> > Am 11.03.2016 um 15:44 schrieb Reza Rahman <[hidden email]>:
> >
> > This is essentially in keeping with the minimalist nature of the EE
> concurrency JSR. I believe most of it is left to vendors to do the right
> thing for users. May be a good idea is this language can be tightened up.
> >
> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <[hidden email]> wrote:
> >> E
> >> From the servlet spec:
> >>
> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web
> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of
> Security Identity in EJBTM Calls? on page 15-176 are available only to
> threads executing the initial request or when the request is dispatched to
> the container via the AsyncContext.dispatch method. Java Enterprise Edition
> features may be available to other threads operating directly on the
> response object via the AsyncContext.start(Runnable) method.?
> >>
> >> check ?available only to threads executing the initial request?
> >>
> >> Also if you look at the servlet AsyncContext then all the wording is
> written as MAY and not as MUST.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <
> [hidden email]>:
> >>>
> >>> Hi Mark,
> >>>
> >>> think 2.3.3.4 states the opposite.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <[hidden email]>:
> >>> Back from JavaLand conference, so sorry for not kicking in earlier.
> >>>
> >>> I not quite get the argumentation chain. It?s that all triggered by
> async servlet requests? And isn?t the servlet spec also saying that all the
> request param etc may max be assigned to a single thread AT A TIME!
> >>>
> >>> Means that it might not be on multiple threads in parallel, but the
> data is allowed to get moved from one thread to another (disapearing from
> the first one), right?
> >>> Would really need to dig into the wording of the async servlets spec
> again, maybe has this in the back of his head?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>>> Am <a href="tel:08.03.2016" value="+498032016">08.03.2016 um 14:43 schrieb Romain Manni-Bucau <
> [hidden email]>:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> following request scope thread and to center the discussion on the
> thread safety part: do we work on this?
> >>>>
> >>>> Background: @RequestScoped is often used as a ThreadLocal instance
> solution. A lot of SE or Batch implementations rely on it from what I saw
> as well as async implementations reusing existing business logic with this
> thread safety constraint.
> >>>>
> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI
> and implemenation and would avoid the headache we can have with
> @RequestScoped. Will also remove the quite dark side of the spec regarding
> servlet request and request scope since now we would have a more natural
> solution for all of these situation so @RequestScoped goals wouldn't
> collide as much.
> >>>>
> >>>> Questions:
> >>>> - is it automatically started as request scoped is (JMS, @Async,
> ...)? Alternative could be some configuration in beans.xml (merged accross
> the app):
> >>>>
> >>>> <beans>
> >>>> <scopes>
> >>>>   <thread>
> >>>>     <active>JMS</active>
> >>>>     <active>ASYNCHONOUS</active>
> >>>>   </thread>
> >>>> </scopes>
> >>>> </beans>
> >>>>
> >>>> - start/stop API (this is typically an API the user should be able to
> control for its own threads)
> >>>> - CDI 2.*0*?
> >>>>
> >>>> wdyt?
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > _______________________________________________
> > cdi-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 64, Issue 100
****************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Stephan Knitelius
If it's possible, I am all for it.
On Sa., 19. März 2016 at 22:07, Werner Keil <[hidden email]> wrote:
Keeping the few annotations like @Inject as they are should be also in CDI's interest, but as JSR 330 is final there is no EG. Unlike this EG and mailing list with great participation, there has never been too much of an EG even when 330 was active, it was more or less Bob and maybe a few participants in the mailing lists. That activity stopped in 2011, see https://groups.google.com/forum/?hl=de#!forum/atinject-observer, so the EG pretty much died 5 years ago. 

It seems reasonable and natural to do changes or tweaks as part of CDI.

Werner



On Sat, Mar 19, 2016 at 9:35 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Merging JSR-330 into CDI (aalmiray)
   2. Re: Merging JSR-330 into CDI (Stephan Knitelius)
   3. Re: @ThreadScoped? (Stephan Knitelius)


----------------------------------------------------------------------

Message: 1
Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST)
From: aalmiray <[hidden email]>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii


Precisely my thoughts. Any changes in behavior / binary compatibility in
JSR-330 must be discussed with the JSR-330 EG and stakeholders.

This being said, what would be the real benefit (to both specs) of rolling
JSR-330 as a subspec of CDI?

Cheers,
Andres




Sent from the CDI Development mailing list mailing list archive at Nabble.com.


------------------------------

Message: 2
Date: Sat, 19 Mar 2016 19:53:13 +0000
From: Stephan Knitelius <[hidden email]>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: Manfred Riem <[hidden email]>
Cc: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"


Hi Manfred,

sorry my replay was a bit out of context since, I was referring to Rezas
last mail.

As already discussed yesterday, this could proof difficult. Since there are
other implementations based on JSR-330, most noticeably spring.

What exactly are we looking to gain from integrating JSR-330?

I agree it would be "cleaner", but maybe too much effort for too little
gain.

If we wanted greater control over those parts, maybe it would be better to
move these parts into a separate module for backwards compatibility.
Including new CDI owned annotations alongside the separated JSR-330, as and
where sensible.

Stephan


On Sa., 19. M?rz 2016 at 20:40, Manfred Riem <[hidden email]> wrote:

> Hi Stephan,
>
> I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as
> it currently
> stands. Anything beyond that is beyond the scope of the discussion/wish I
> have as that
> would then be decided by the combined EG.
>
> Thanks!
>
> King regards,
> Manfred Riem
>
>
> On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <[hidden email]>
> wrote:
>
> If I understand you correctly, you are suggesting to move the JSR-330
> annotations into a separate CDI module/profile, thereby semi-deprecating
> these.
>
> This would essentially open up the possibility of replacing @Named, etc...
> with CDI specific annotations.
>
> Certainly an interesting path to explore.
>
> Stephan
>
>
> On Sa., 19. M?rz 2016 at 19:27, Manfred Riem <[hidden email]> wrote:
>
>> I couldn't agree more ;)
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> > On Mar 19, 2016, at 10:47 AM, Reza Rahman <[hidden email]>
>> wrote:
>> >
>> > I definitely think it's an idea worth exploring. It will strengthen
>> CDI's hand further. It will be great if some of the confusingly redundant
>> APIs like @Singleton could be deprecated in the process.
>> >
>> > BTW, it is really great to see you active in the community!
>> >
>> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem <[hidden email]> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I wrote a little blog entry about a CDI wish I have and in essence it
>> comes
>> >> down to merging JSR-330 into the CDI specification as a sub spec. I
>> realize
>> >> there is history there, but to me it looks like the best course of
>> action.
>> >>
>> >> I had some twitter exchanges about this and some folks are for, some
>> are
>> >> against.
>> >>
>> >> Note I think this is worth exploring as an idea, not something that
>> >> necessarily needs to be in the current JSR, but definitely something
>> that I
>> >> think is worth to do at some point (sooner rather than later in my
>> book).
>> >>
>> >> What do you think?
>> >>
>> >> Thanks!
>> >>
>> >> Kind regards,
>> >> Manfred Riem
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> >> Sent from the CDI Development mailing list mailing list archive at
>> Nabble.com <http://nabble.com>.

>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >> [hidden email]
>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>
>> >> Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment-0001.html

------------------------------

Message: 3
Date: Sat, 19 Mar 2016 20:35:29 +0000
From: Stephan Knitelius <[hidden email]>
Subject: Re: [cdi-dev] @ThreadScoped?
To: Mark Struberg <[hidden email]>, Reza Rahman
        <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

I would certainly agree with the assertion that in general it's not
advisable to execute a request with multiple threads and that usually
single threaded execution is sufficient.

However I don't think ignoring it is an option. Concurrent operations can
be launched even from CDI beans. Yet we don't properly support context
propagation nor a context spanning all threads launched from a request.

I know that changing @requestScoped is probably out of the question, but at
least we should consider adding a new context spanning all threads and
defining a logical solution for context propagation that can be explained
to the end user.



On Fr., 11. M?rz 2016 at 17:17, Mark Struberg <[hidden email]> wrote:

> Yes, but certain things in EE are assumed to be handled on a single
> thread. And if you run on a servr then this is really not a blocker most
> times. If I get many paralllel requests hitting my box then I do not need
> async handling _that_ often. The whole overhead for setting up the new
> thread, etc often heavily exceeds the benefits.
> So I would not put too much energy into it?
>
> LieGrue,
> strub
>
> > Am 11.03.2016 um 15:44 schrieb Reza Rahman <[hidden email]>:
> >
> > This is essentially in keeping with the minimalist nature of the EE
> concurrency JSR. I believe most of it is left to vendors to do the right
> thing for users. May be a good idea is this language can be tightened up.
> >
> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <[hidden email]> wrote:
> >> E
> >> From the servlet spec:
> >>
> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web
> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of
> Security Identity in EJBTM Calls? on page 15-176 are available only to
> threads executing the initial request or when the request is dispatched to
> the container via the AsyncContext.dispatch method. Java Enterprise Edition
> features may be available to other threads operating directly on the
> response object via the AsyncContext.start(Runnable) method.?
> >>
> >> check ?available only to threads executing the initial request?
> >>
> >> Also if you look at the servlet AsyncContext then all the wording is
> written as MAY and not as MUST.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <
> [hidden email]>:
> >>>
> >>> Hi Mark,
> >>>
> >>> think 2.3.3.4 states the opposite.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <[hidden email]>:
> >>> Back from JavaLand conference, so sorry for not kicking in earlier.
> >>>
> >>> I not quite get the argumentation chain. It?s that all triggered by
> async servlet requests? And isn?t the servlet spec also saying that all the
> request param etc may max be assigned to a single thread AT A TIME!
> >>>
> >>> Means that it might not be on multiple threads in parallel, but the
> data is allowed to get moved from one thread to another (disapearing from
> the first one), right?
> >>> Would really need to dig into the wording of the async servlets spec
> again, maybe has this in the back of his head?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>>> Am <a href="tel:08.03.2016" value="+498032016" target="_blank">08.03.2016 um 14:43 schrieb Romain Manni-Bucau <
> [hidden email]>:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> following request scope thread and to center the discussion on the
> thread safety part: do we work on this?
> >>>>
> >>>> Background: @RequestScoped is often used as a ThreadLocal instance
> solution. A lot of SE or Batch implementations rely on it from what I saw
> as well as async implementations reusing existing business logic with this
> thread safety constraint.
> >>>>
> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI
> and implemenation and would avoid the headache we can have with
> @RequestScoped. Will also remove the quite dark side of the spec regarding
> servlet request and request scope since now we would have a more natural
> solution for all of these situation so @RequestScoped goals wouldn't
> collide as much.
> >>>>
> >>>> Questions:
> >>>> - is it automatically started as request scoped is (JMS, @Async,
> ...)? Alternative could be some configuration in beans.xml (merged accross
> the app):
> >>>>
> >>>> <beans>
> >>>> <scopes>
> >>>>   <thread>
> >>>>     <active>JMS</active>
> >>>>     <active>ASYNCHONOUS</active>
> >>>>   </thread>
> >>>> </scopes>
> >>>> </beans>
> >>>>
> >>>> - start/stop API (this is typically an API the user should be able to
> control for its own threads)
> >>>> - CDI 2.*0*?
> >>>>
> >>>> wdyt?
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber

> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > _______________________________________________
> > cdi-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment.html

------------------------------


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 64, Issue 100
****************************************

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Mark Struberg
What are the benefits?



I mean serious, what does CDI gain?


I can at least tell you what it hurts:

TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to change. I like to see CODE to show possible benefits. Before that I don't waste any more energy, and you should neither.



long version:


1.) A lot specs are currently worded to only need JSR-330 for users. That way they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is wrong with that?

2.) What changes do you need in atinject? We had a few ideas and sent them to the JSR-330 EG a year ago. We had good discussions but none of our wishes was worked out because WE failed to make final suggestions!
The atinject EG (Bob, Jürgen) has been responsive. At least MUCH more responsive than other EG leaders these days... So I fail to see why the atinject EG is 'inactive since 5 years'. That's just wrong information.

3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs.

4.) We also cannot just amend the annotations and take them 'over'. That would require the EC to officially move the maintenance of atinject to the CDI EG. Or even requires a handover from the atinject EG. I'm not sure about that

5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great. But then again: Show me an example what we would gain from it! Stop trashtalking but show CODE instead!

6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but that's it for now imo.

 

7.) The JSR-330 spec had an important political role back then. I know most people don't know that, but it's still great to have this little peace which managed to make peace. Not peace between Spring and EE as many people believe, back then it was more that it brought mainly peace between CDI and most of the rest of JavaEE EGs! Remember that we haven't been allowed to target Java SE in CDI-1.0? Remember that we were force to have the 'for Java Enterprise' in the spec name? Remember that we had big battles with EJB? No, then just take it as granted and let it rest...



LieGrue,
strub

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Mark Struberg
I'll give you an example:

Currently many specs refer to atinject but also to CDI, because they need to use @Nonbinding (e.g. in Qualifiers).

Thus Antoine and I asked the atinject EG whether they might introduce a @Nonbinding annotation. During that I learned that annotations not available on the classpath will _not_ blow up but simply don't appear at Runtime in Class#getAnnotations() etc.

Means if you don't have the cdi-api.jar on your classpath the @Nonbinding annotation just doesn't show up at Runtime.


Since Spring and Guice seems to not need this feature it's all fine from a CDI pov.

Imagine what it would have meant to us if we would have got a second @Nonbinding in the javax.inject packgae: we would have to duplicate all the code which currently handling @Nonbinding.


And that was actually the most important requirement the CDI EG came up for atinject in the last 7 years.


Thus before we continue any discussions and further rouse people I like to see clear ideas WHAT you like to get changed in atinject.


LieGrue,
strub




> On Sunday, 20 March 2016, 8:35, Mark Struberg <[hidden email]> wrote:
> > What are the benefits?
>
>
>
> I mean serious, what does CDI gain?
>
>
> I can at least tell you what it hurts:
>
> TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to
> change. I like to see CODE to show possible benefits. Before that I don't
> waste any more energy, and you should neither.
>
>
>
> long version:
>
>
> 1.) A lot specs are currently worded to only need JSR-330 for users. That way
> they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is
> wrong with that?
>
> 2.) What changes do you need in atinject? We had a few ideas and sent them to
> the JSR-330 EG a year ago. We had good discussions but none of our wishes was
> worked out because WE failed to make final suggestions!
> The atinject EG (Bob, Jürgen) has been responsive. At least MUCH more responsive
> than other EG leaders these days... So I fail to see why the atinject EG is
> 'inactive since 5 years'. That's just wrong information.
>
> 3.) We cannot simply take the javax.inject package and maintain it in CDI. It is
> forbidden to split a java package into multiple specs.
>
> 4.) We also cannot just amend the annotations and take them 'over'. That
> would require the EC to officially move the maintenance of atinject to the CDI
> EG. Or even requires a handover from the atinject EG. I'm not sure about
> that
>
> 5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great.
> But then again: Show me an example what we would gain from it! Stop trashtalking
> but show CODE instead!
>
> 6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is
> busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but
> that's it for now imo.
>
>
>
> 7.) The JSR-330 spec had an important political role back then. I know most
> people don't know that, but it's still great to have this little peace
> which managed to make peace. Not peace between Spring and EE as many people
> believe, back then it was more that it brought mainly peace between CDI and most
> of the rest of JavaEE EGs! Remember that we haven't been allowed to target
> Java SE in CDI-1.0? Remember that we were force to have the 'for Java
> Enterprise' in the spec name? Remember that we had big battles with EJB? No,
> then just take it as granted and let it rest...
>
>
>
> LieGrue,
> strub
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
> on this list, the provider waives all patent and other intellectual property
> rights inherent in such information.
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

arjan tijms
In reply to this post by Mark Struberg
On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <[hidden email]> wrote:
3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs.

Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Mark Struberg
It's fine to have one spec own multiple packages. But one package shall not get maintained by multiple specs.

Think about how sealed jars or OSGi should handle this -> technically broken and also not allowed by the JCP rules.


Thus before we seriously think about that we need to know what features we like to get from JSR-330.

I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn into real progress.


There are sooo many pull requests waiting to get reviewed first!

* CDI-SE needs a total rework for example
* the Builders need a review

etc


LieGrue,
strub


On Sunday, 20 March 2016, 11:12, arjan tijms <[hidden email]> wrote:

>
>
>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <[hidden email]> wrote:
>
>3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs.
>>
>
>
>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?
>
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

arjan tijms
On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg <[hidden email]> wrote:
It's fine to have one spec own multiple packages. But one package shall not get maintained by multiple specs.

Think about how sealed jars or OSGi should handle this -> technically broken and also not allowed by the JCP rules.

Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375.

Kind regards,
Arjan Tijms

 


Thus before we seriously think about that we need to know what features we like to get from JSR-330.

I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn into real progress.


There are sooo many pull requests waiting to get reviewed first!

* CDI-SE needs a total rework for example
* the Builders need a review

etc


LieGrue,
strub


On Sunday, 20 March 2016, 11:12, arjan tijms <[hidden email]> wrote:
>
>
>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <[hidden email]> wrote:
>
>3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs.
>>
>
>
>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?
>
>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Merging JSR-330 into CDI

Mark Struberg
>Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375.


Yes, at least as far as I understood.

LieGrue,
strub


On Sunday, 20 March 2016, 20:34, arjan tijms <[hidden email]> wrote:


>
>
>On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg <[hidden email]> wrote:
>
>It's fine to have one spec own multiple packages. But one package shall not get maintained by multiple specs.
>>
>>Think about how sealed jars or OSGi should handle this -> technically broken and also not allowed by the JCP rules.
>>
>
>
>Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375.
>
>
>Kind regards,
>Arjan Tijms
>
>
>
>
>>
>>Thus before we seriously think about that we need to know what features we like to get from JSR-330.
>>
>>I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn into real progress.
>>
>>
>>There are sooo many pull requests waiting to get reviewed first!
>>
>>* CDI-SE needs a total rework for example
>>* the Builders need a review
>>
>>etc
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>On Sunday, 20 March 2016, 11:12, arjan tijms <[hidden email]> wrote:
>>>
>>>
>>>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <[hidden email]> wrote:
>>>
>>>3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs.
>>>>
>>>
>>>
>>>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?
>>>
>>>
>>
>
>
>
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.