Dne 6.3.2016 v 18:41 John D. Ament napsal(a):
On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau
<rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote:
2016-03-06 18:02 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com
<mailto:john.d.ament@gmail.com>>:
What I think would be even better is to see this implemented in
the impls (Weld & OWB) and see how users use it, in a release
that's not plastered with Alpha or Experimental all over it.
While I think we were all wary about it, we need real end user
input from the impl standpoint to figure out what makes sense to
standardize on.
Or just do the opposite and *standardize* it. We can use Rx*
feedbacks but it doesnt' match event case at all which is a real
small subset of the reactive programming so I guess easiness should
be what drives us there and integration at least with the JVM so
CFuture version sounds more natural than CStage one. Difference is
very small at method level but at utility level it is.
Side note: a Weld or OWB release without experimental/alpha sounds
worse if the spec changes later. A compromise can be an extension
doing it already you can drop in any of these containers.
There seems to be a general misunderstanding about how the specs are
intended to work. You standardize on things that as a group everyone
has agreed would work in a specific way. Right now, the CDI EG is
innovating and standardizing on those innovations instead of
standardizing on the features already available in the various impls.
Lets take a few examples of where impls deviate from the specs.
- Bean Validation: Hibernate Validator has a suite of built in
validations
https://github.com/hibernate/hibernate-validator/tree/master/engine/src/m...
-
these constraints can in theory work in any pluggable environment, but
come with their core engine built in, for people to leverage. These are
good targets to leverage in the core spec when its seen as being very
useful.
I think you cannot compare custom BV constraints and things which
require core API changes.
- JAX-RS : All of the implementations had client impls paired up with
their 1.1 compliant releases, even though it wasn't required. Why?
Because it made a ton of sense. Then see what happened afterwards, the
EG came together and standardized on a Client API that took a lot of the
great features in each impl and made them consistent.
- EJB: Lets not forget that the removal of home/remote/local interfaces
came from a combination of xdoclet and spring. The EG came together,
saw that what was in use and figured out how to standardize on it once
the language features were available.
- Singleton EJBs: An extension of EJB 3, most vendors supported a form
of singleton in their EJBs, and the EJB EG agreed upon it in addition to
some concurrency issues that had to be addressed.
- CDI: Lets not forget about the hard work people like strub have put
into making CDI work well. Scoped Beans only? Awesome idea.
https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194...
He didn't wait for the EG to standardize on anything before implementing.
You call it "awesome idea", I agree that this feature makes sense, but I
call it "manipulative approach". It was implemented before the EG was
able to decide. The same for CDI-527 - OWB has a config property
"javax.enterprise.inject.allowProxying.classes" but the proposed PR was
not merged. Sure, EG is slow but it doesn't mean it should be ignored.
- JPA: Lets not forget that HIbernate supports in dual hierarchies the
EntityManager and Session interfaces concurrently. Want to use HQL in
your @NamedQuery? Sure, it works fine.
Bottom line, we need to get these features out into the wild, let people
play and come back with input on the various impls. There's nothing
stopping the weld team from introducing
org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and
CompletionStage, allowing app developers to consume this via an
injection point just like Event works today, @Inject AsyncEvent<Foo>.
But this would require the users to depend on Weld API! And that's only
acceptable in SE and servlet containers where the users need
impl-specific stuff anyway.
Even if thats not the spec compliant way to do it long term, it makes
it
clear that you're using a provider specific API.
In addition, there would be nothing stopping either team from
introducing support for @Priority on observer methods. There's no API
change, no spec change required. The spec doesn't mandate that it
works, but there's nothing stopping your impl from allowing it. The
spec doesn't say you absolutely cannot leverage it.
I agree that the impls should innovate where the spec allows it. On the
hand, it's not always an easy task, esp. if you need backward compatibility.
John
John
On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman
<reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com>> wrote:
How much end user feedback has there been on this? I have to
be honest that it surprises me to find this out now.
This to me stands out as an obvious usability problem.
CompletableFuture is the obvious top level end user API, not
CompletionStage. Not going with CompletableFuture is very
likely to confuse most people. The last thing we need is
more potential usability problems in Java EE APIs.
On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau
<rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote:
> Hi guys,
>
> as a user having a ComlpetionStage makes me loose some JDK
> utilities, can we move back to CompletionFuture?
>
> It would allow for instance:
>
> // doesn't work with CompletionStage
> CompletionFuture.allOf(event1.fireAsync(...),
> event2.fireAsync(...))
> .then(...)
>
> Romain Manni-Bucau
> @rmannibucau <
https://twitter.com/rmannibucau> | Blog
> <
http://rmannibucau.wordpress.com> | Github
> <
https://github.com/rmannibucau> | LinkedIn
> <
https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <
http://www.tomitribe.com>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>
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
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
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
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
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
cdi-dev(a)lists.jboss.org
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.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic