| Re: [ee4j-community] Tomitribe commitment to EE4J |
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Re: Tomitribe commitment to EE4J (Greg Wilkins)
2. Re: Eclipse Jetty and EE4J (Werner Keil)
3. Re: Tomitribe commitment to EE4J (Guillermo Gonz?lez de Ag?ero)
------------------------------------------------------------ ----------
Message: 1
Date: Sat, 14 Oct 2017 08:56:53 +1100
From: Greg Wilkins <gregw@xxxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
Message-ID:
<CAAPGdfEWSQ44BhuRv5hz5gQ7kLAU9crkvwNCAX9O4Pf4eWmHTg@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
Hey David,
I too think that CDI is a core technology that is vital to get right for
EE4J and a good test of the process and collaboration.
Historically it has been a difficult one because it clashes with other
specifications on definitions of specific annotations and the
implementation of scanning for annotations.
Previously, it has been very difficult to avoid multiple annotation scans
being done, by container, by CDI, by other JSP, etc. etc. Now with java9
MR jars and modules as well as classpaths, it is even less clear what jars
should be scanned and what classes within those jars should be visited.
It is a real disappointment that java9 didn't provide some good common
annotation scanning support, specially as so much more of the jars /
classpath / modules are now hidden.
So for various specification to play nice with each other, we really need
to cooperate on object creation and decoration in a way that facilitates
legacy annotations, full CDI support and perhaps what ever might replace
CDI (as picking winners is seldom good).
>From the servlet spec point of view, I would resist any "you must support
CDI" initiative, but would embrace a "please open up and standardise your
object creation and decoration"
Note also that I would love to see some standard for features to be able to
persist and replay the results of annotation scanning. In a micro service
virtualised deployment it can be dire to ask a user to wait 30 plus seconds
when spinning up a new instance to allow annotation scanning to take place
over jars you know have not changed, but that you don't know what the
features are looking for in them.
cheers
On 14 October 2017 at 05:49, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> It goes without saying, Tomitribe is 100% committed to the success of Java
> EE's future as EE4J and very excited about what we can all achieve together.
>
> We've had discussions within the Tribe about where we might like to
> contribute or potentially lead. We tend to be passionate about topics we
> perceive as abandoned. Before we sign ourselves up for any crusades, we
> would like community feedback to see if there are other's who might share
> our passions.
>
> EJB: We believe CDI is the future and all things should align to it. We
> (Java EE EG, EJB EG) started work on aligning EJB to CDI in the form of
> breaking apart the EJB spec into smaller specifications like Interceptors
> specification and @Transaction specification, but we did not finish. There
> is some work left pulling things like @Schedule, @Asynchronous, or
> @Lock(READ) out. The former EJB should just be services that could be
> applied to any CDI bean. We've also presented ideas for passing Java 8
> functions to things like the TimerService. Long-term, timers could be
> clustered. We expect we might be entirely alone in that passion. If not
> speak up.
>
> JMS: We (JMS 2.1 EG) got very nearly finished with annotation-based JMS
> API. It would be a shame to not deliver that work and there is more than
> one Triber passionate about this topic. There is also potential synergy
> with Reactive style models here that are worth exploring. On this topic in
> particular we would like community feedback on interest. Are we the only
> thinks this work is worth finishing or that this API could support some of
> our more modern asynchronous/reactive approaches?
>
> Security: We have a number of people interested in security. This year
> we showed at JavaOne an API Gateway that supports JWT, HTTP Signatures and
> also did a security talk and the MicroProfile JWT specification we believe
> is perhaps the best specification in the MicroProfile. In JSR 375 we (EG)
> unfortunately did not go into any aspects of modern rest security, which is
> a real shame. The specification is a step forward, but does fall into the
> same trap that Java EE security has always "solved" the via Java layer
> abstractions and doesn't address wire level interoperability. What was
> done in the MicroProfile JWT specification should get merged in some way
> with EE4J security. Microservices should be able to portably communicate
> the caller via JWTs.
>
> There is some internal tribe interest in participating in JCA, JPA and
> JAX-RS. For JPA, there are thoughts about what a Java 8 stream based API
> for JPA might look like.
>
> On the topic of RIs, we would want the ability to chose the RI for
> anything we might lead. Before any "that's the way it is" might be used as
> an argument, we'd point out that we are changing almost everything about EE
> and its process. We'd want to see this up for discussion.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 310-633-3852
>
>
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 310-633-3852
>
>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
>
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20171014/9b10a4bd/attachment. html
------------------------------
Message: 2
Date: Sat, 14 Oct 2017 00:57:28 +0200
From: Werner Keil <werner.keil@xxxxxxxxx>
To: Greg Wilkins <gregw@xxxxxxxxxxx>
Cc: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Eclipse Jetty and EE4J
Message-ID:
<CAAGawe1dm6dd90SqdBYQcKZGz6aXrh19H07BM4btwvBo3iOYLA@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
I know what you mean.
Being an EG member of Java ME 8 CLDC and MEEP I had no access to the TCK.
Only because I'm also in the EC I could review it.
That's why JSR 363 is the only one with multiple profiles across ME and
SE/EE that has a truly open TCK. CDI 2 comes next with SE and EE support,
but so far Java EE itself knows just 2 profiles.
Am 13.10.2017 23:10 schrieb "Greg Wilkins" <gregw@xxxxxxxxxxx>:
Jetty has been run against the TCK whenever we have had access to it either
as part of our membership of the expert group or contribution to other
project with access.
We just never paid the license fee that would have allowed us to say
anything about the results of those tests one way or another.
Once the TCK is open we will certainly be running against it and making the
results public.
Cheers
On 14 Oct 2017 07:07, "Bill Shannon" <bill.shannon@xxxxxxxxxx> wrote:
> Werner Keil wrote on 10/13/17 08:14 AM:
> >
> > Jetty is a compatible Servlet Implementation
> >
> Actually, it is not.
>
> Jetty has never licensed, and thus never passed, the Servlet TCK.
>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20171014/a195ad96/attachment. html
------------------------------
Message: 3
Date: Sat, 14 Oct 2017 08:55:55 +0000
From: Guillermo Gonz?lez de Ag?ero <z06.guillermo@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
Message-ID:
<CAG1ZpUYhZBK+era=yx_nJ3pCwZVHadsEkRPf6x43+ >QjHwe6ckA@xxxxxxxxxxxxxx
Content-Type: text/plain; charset="utf-8"
Hi,
I totally support the idea of EJB services moving to CDI, and I want to
participate on that when work begins. Is your idea to totally deprecate
EJBs or do you advocate for maintaining things like TimerService from them?
I believe the EJB brand should be abandoned as lots of people still
associate them with a dark past.
On JMS, at least the CDI alignment work should be released IMO, as it's
needed for EJB decoupling. Onwards, do you (you and your team) expect JMS
to be adaptable to the new cloud messaging? Payara has done some JCA
resource adapters for them [1]. I wonder if JMS could handle the new
systems. Perhaps with the new more open process, some representatives of
those libraries would like to participate there.
Wrt Security, I'm pretty happy we now have a solid foundation that is user
approachable, which didn't exist before. I personally missed some more
vendor participation there, which again I expect to change with a more open
process and maybe even co-leading as you suggested.
One thing I recall was discussed as problematic when talking about JSR 375
and JWT was that the GlassFish cannot depend on any non-RI or non Java
library (I don't know the exact terms). Making JWT easy to use would
require an external library and that was going to be a problem for
Soteria. I imagine we will be able to change even those rules, which will
accelerate some things a bit.
Btw, there's already a good example of JSR375+JWT available at [2].
Regards,
Guillermo Gonz?lez de Ag?ero
[1] https://github.com/payara/Cloud-Connectors
[2]
https://github.com/javaee-samples/javaee8-samples/tree/ master/security/jwt
El vie., 13 oct. 2017 a las 20:49, David Blevins (<dblevins@xxxxxxxxxxxxx>)
escribi?:
> It goes without saying, Tomitribe is 100% committed to the success of Java
> EE's future as EE4J and very excited about what we can all achieve together.
>
> We've had discussions within the Tribe about where we might like to
> contribute or potentially lead. We tend to be passionate about topics we
> perceive as abandoned. Before we sign ourselves up for any crusades, we
> would like community feedback to see if there are other's who might share
> our passions.
>
> EJB: We believe CDI is the future and all things should align to it. We
> (Java EE EG, EJB EG) started work on aligning EJB to CDI in the form of
> breaking apart the EJB spec into smaller specifications like Interceptors
> specification and @Transaction specification, but we did not finish. There
> is some work left pulling things like @Schedule, @Asynchronous, or
> @Lock(READ) out. The former EJB should just be services that could be
> applied to any CDI bean. We've also presented ideas for passing Java 8
> functions to things like the TimerService. Long-term, timers could be
> clustered. We expect we might be entirely alone in that passion. If not
> speak up.
>
> JMS: We (JMS 2.1 EG) got very nearly finished with annotation-based JMS
> API. It would be a shame to not deliver that work and there is more than
> one Triber passionate about this topic. There is also potential synergy
> with Reactive style models here that are worth exploring. On this topic in
> particular we would like community feedback on interest. Are we the only
> thinks this work is worth finishing or that this API could support some of
> our more modern asynchronous/reactive approaches?
>
> Security: We have a number of people interested in security. This year
> we showed at JavaOne an API Gateway that supports JWT, HTTP Signatures and
> also did a security talk and the MicroProfile JWT specification we believe
> is perhaps the best specification in the MicroProfile. In JSR 375 we (EG)
> unfortunately did not go into any aspects of modern rest security, which is
> a real shame. The specification is a step forward, but does fall into the
> same trap that Java EE security has always "solved" the via Java layer
> abstractions and doesn't address wire level interoperability. What was
> done in the MicroProfile JWT specification should get merged in some way
> with EE4J security. Microservices should be able to portably communicate
> the caller via JWTs.
>
> There is some internal tribe interest in participating in JCA, JPA and
> JAX-RS. For JPA, there are thoughts about what a Java 8 stream based API
> for JPA might look like.
>
> On the topic of RIs, we would want the ability to chose the RI for
> anything we might lead. Before any "that's the way it is" might be used as
> an argument, we'd point out that we are changing almost everything about EE
> and its process. We'd want to see this up for discussion.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 310-633-3852
>
>
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 310-633-3852
>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20171014/75e607f6/attachment. html
------------------------------
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
End of ee4j-community Digest, Vol 2, Issue 108
**********************************************