[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-community] Initial thoughts on where the Payara team can contribute best.
|
> On 16. Oct 2017, at 00:09, Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Adam/all,
>
> Some of these threads look a bit misleading, when the actual content is about "yet another twist" to the name.
>
> "EJ" is shorter, but the whole requirement of not calling it "Enterprise Java" would be undermined. As well as a future version beyond the Java EE 8 compatibility when EJB could be optional or pruned, too. "EJ" sounds more along the lines of EJB.
Then "JE". "EJ" sounds just nicer and is shortened EE4J.
Nickname is a nickname.
cheers,
adam
>
> "RT" is an Eclipse TLP with just 2 characters, but there are not many and it stands for "Runtime, "EJ" would clearly be considered "Enterprise Java" and this name is not supposed to be used now. Log4J or SLF4J did pretty well with their "4J" so why should it be a problem for EE4J, it is still the umbrella TLP anyway, individual projects can have other names or keep them like "Glassfish", "Yasson", "Jersey", "Jetty", etc.
>
> Werner
>
>
> On Sun, Oct 15, 2017 at 9:18 PM, <ee4j-community-request@xxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxx
>
> You can reach the person managing the list at
> ee4j-community-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ee4j-community digest..."
>
>
> Today's Topics:
>
> 1. Re: Eclipse Jetty and EE4J (Mike Milinkovich)
> 2. Re: Initial thoughts on where the Payara team can contribute
> best. (Adam Bien)
> 3. Re: Tomitribe commitment to EE4J (Adam Bien)
> 4. Re: Tomitribe commitment to EE4J (reza_rahman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 15 Oct 2017 08:18:57 -0400
> From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
> To: ee4j-community@xxxxxxxxxxx
> Subject: Re: [ee4j-community] Eclipse Jetty and EE4J
> Message-ID:
> <9ca1521e-a861-cdcf-6a4b-7ca1c991d8bb@xxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 2017-10-14 8:49 AM, David Heffelfinger wrote:
> > I have to admit, not having an RI never even crossed my mind, I
> > suppose I'm too used to "that's just the way things are", interesting
> > how this list opens the mind to new possibilities.
> >
> > Having said that, I think that at least in the beginning, we should
> > still have an RI, we are going through enough changes with the move to
> > Eclipse, too many variables and things changing. Most members of the
> > Java EE community are used to having an RI, continuing this for the
> > time being would provide some sense of continuity during the transition.
>
> Yes. I would like to remind everyone that one of the stated goals from
> Oracle is to first build a compatible EE4J implementation that passes
> existing Java EE 8 TCKs. Once that baseline is established, we can move
> on to other models.
>
> > I'm open to the possibility of removing RI's in the future, if it
> > makes sense.
>
> Me too :)
>
> --
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
> (m) +1.613.220.3223
>
> EclipseCon Europe 2017 <http://www.eclipsecon.org/europe2017>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171015/f510d03a/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 15 Oct 2017 18:53:31 +0200
> From: Adam Bien <abien@xxxxxxxxxxxxx>
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Initial thoughts on where the Payara
> team can contribute best.
> Message-ID: <04346DE9-BBCD-495F-8B38-FDBF72FDCAFC@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
>
>
> > On 13. Oct 2017, at 20:08, Will Lyons <will.lyons@xxxxxxxxxx> wrote:
> >
> > A new version of the Charter Doc has been published:
> > https://projects.eclipse.org/projects/ee4j/charter
>
> Regarding nickname. Could we change it to just "EJ"?
> The shorter, the better,
>
> cheers,
>
> adam
> >
> > ...which addresses a number of issues raised by the community including:
> > - referencing runtimes vs. application servers
> > - the ability to run technologies in standalone Java SE environments
> > - referencing cloud-native applications
> >
> > Further charter feedback should be based on this version of the Charter Doc.
> >
> > Thanks
> >
> > Will
> >
> >
> >
> > On 10/13/17 12:48 PM, Vikas Deolaliker wrote:
> >> Instead of application servers which was intended only for on premise bare metal. Can we expand the charter to run-time environment for any execution env including clouds.
> >>
> >> On Thu, Oct 12, 2017 at 1:24 AM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:
> >> Hi Giorgio,
> >>
> >> I think step one is to get the code into the Foundation as "Code speaks the loudest!". Bruno and I plan to hold a fortnight / weekly meeting so we can discuss with the community what the steps are and together plan what to do next. More on this later on today :-)
> >>
> >> Cheers,
> >> Martijn
> >>
> >> On 12 October 2017 at 09:08, Giorgio Desideri <giorgio.desideri@xxxxxxxxx> wrote:
> >> Hi All,
> >>
> >> I follow this mailing from few days ago , and the main issues are discussing, JCP and License to use, packages name and new functionalities.
> >>
> >> Now, waiting the completion of this discussion, to organize the development and the community. What is the time-line that the community wants follow before to start the development phase ?
> >>
> >>
> >> Thanks
> >>
> >> Doct. Giorgio Desideri
> >>
> >> Skype: kallsu82
> >> Linkedin: http://www.linkedin.com/pub/giorgio-desideri/7/a5a/176
> >>
> >> PGP-Public Key: 4096R/E8B659C4
> >> PGP Fingerprint: 52C8 09E5 346B A2EE E210 2399 073A 778E E8B6 59C4
> >>
> >> -----
> >> "If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is" (J. von Neumann)
> >>
> >> "Il saggio coltiva Linux, perch? s? che Window$ si pianta da solo !"
> >>
> >>
> >>
> >> 2017-10-12 13:27 GMT+07:00 Guillermo Gonz?lez de Ag?ero <z06.guillermo@xxxxxxxxx>:
> >> Makes sense. Thanks for the sincere answer and for preserving everyone interests.
> >>
> >>
> >> Regards,
> >>
> >> Guillermo Gonz?lez de Ag?ero
> >>
> >>
> >> El jue., 12 de octubre de 2017 6:09, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> escribi?:
> >> I still see value in having an RI and as that is currently GlassFish I think it has great relevance. Building a new RI would be a major distraction for EE4J.
> >>
> >>
> >> I don?t think Payara Server should be the RI as Payara Server is evolving in ways that are demanded by our customers as ultimately customers pay for our developers. In time these demands may or may not align with features that are needed by an RI. Saying that we now have good knowledge of the GlassFish code base and are happy to contribute fixes and future integrations to make GlassFish reliable and stable and provide a good developer experience.
> >>
> >>
> >> Ultimately the goal of an RI should be the gold standard on how EE4J apis behave and having an open collaboratively developed RI ensures that where this diverges we can all chip in to clarify and fix the behaviour. Also with having an open source TCK we can all fix the test that allowed anomalous or ill-defined behaviour to slip through. That?s why having a vendor neutral, community developed, GlassFish as RI is I feel the best solution.
> >>
> >>
> >> Steve
> >>
> >>
> >> From: ee4j-community-bounces@xxxxxxxxxxx [mailto:ee4j-community-bounces@xxxxxxxxxxx] On Behalf Of Guillermo Gonz?lez de Ag?ero
> >> Sent: 11 October 2017 12:53
> >>
> >>
> >> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> >>
> >> Subject: Re: [ee4j-community] Initial thoughts on where the Payara team can contribute best.
> >>
> >>
> >> Great to see this commitment from Payara!
> >>
> >>
> >> One thing I've been wondering for some time is wether GlassFish (the application server, not its components) should really be maintained. I sadly doubt the reliability of the latast GlassFish (>4.0) versions and I'm not sure much people actually use it in production Java EE 7 systems.
> >>
> >>
> >> With GlassFish relicensed as EPL, I guess Payara could also get rid of its Oracle license bits and perhaps be promoted as the RI.
> >>
> >>
> >> Would you possibly be interested in discussing such a thing? I'd like to hear some preliminary thoughts on that matter.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >> Guillermo Gonz?lez de Ag?ero
> >>
> >>
> >> El mi?., 11 de octubre de 2017 20:13, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> escribi?:
> >>
> >> Hi All,
> >>
> >>
> >> As EE4J starts to happen and project and code starts to move to the Eclipse Foundation it is now time for the community to put their hand up and indicate which areas people can commit expertise and real development hours to drive forward.
> >>
> >>
> >> We?ve had some initial discussions on where the Payara team can provide the biggest impact. First and foremost we can take on driving forward GlassFish as the reference implementation, providing key development effort to ensure EE4J GlassFish is free of bugs and integrates new and updated specifications for future EE4J releases as well as assisting in setting up the dev and CI environments for passing the TCK. This will also include helping keep a bunch of the dependent sub-projects that are not JSRs up to date including HK2, Grizzly, CORBA, etc. This is a big piece of work where our knowledge of the code base means we can provide a great contribution.
> >>
> >>
> >> In a couple of other areas we can draw and build on the experience and expertise of Arjan Tijms and provide leadership and sustained developer hours to drive forward JSF with Mojarra as well as JSR 375 along with Soteria the RI. Longer term as project teams are drawn up I imagine we will also take on contributing development to many other EE4J projects and maintenance of RIs.
> >>
> >>
> >> All in all this is an exciting and challenging time that needs community developers, vendors, end users and open-source projects to commit real coding time to the future development of EE4J. I hope we can do our bit without being overwhelmed with the volume of work involved. These are our first thoughts and will evolve as everything becomes clearer.
> >>
> >>
> >>
> >> Steve Millidge
> >>
> >> Payara
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >> _______________________________________________
> >> 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
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 15 Oct 2017 18:06:28 +0200
> From: Adam Bien <abien@xxxxxxxxxxxxx>
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
> Message-ID: <F91CE93E-15BC-4664-8C9F-6A9F6E2121DA@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On 14. Oct 2017, at 21:07, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> >
> > Personally I think @Pooled/@PoolScoped is best in CDI. The remainder of the EJB functionality can be pretty cleanly farmed out between Java EE Concurrency and JMS/JCA.
> >
> > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> >
> > -------- Original message --------
> > From: arjan tijms <arjan.tijms@xxxxxxxxx>
> > Date: 10/14/17 2:24 PM (GMT-05:00)
> > To: ee4j-community@xxxxxxxxxxx
> > Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
> >
> > Hi,
> >
> > 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.
> >
> > As expressed previously on the Java EE spec list, I strongly support that too. In order to have a more consistent programming model to offer the user, these, and a few others should be re-implemented based on CDI and Interceptors.
> >
> > I think this can best be done in a similar way as @Transactional was done; basically have the EJB name and semantics, but add a few extra features and/or take away some existing pain points.
> >
> > At OmniFaces we started prototyping this a while ago. The intend was for those implementations to be a base proposal for inclusion in Java EE 8, but that never happened.
> >
> > See: https://github.com/omnifaces/omniservices/tree/develop/src/main/java/org/omnifaces/services
> >
> > Also note that we took a couple of steps to align JSF more with CDI in JSF 2.3, and that alignment story is far from done.
> >
> > Java EE Security as a new spec has been based fully on CDI from the start.
> >
> >
> > The former EJB should just be services that could be applied to any CDI bean.
> >
> > By that do you mean that you'd like to see @Asynchronous to remain in the EJB spec, but in a CDI version?
> >
> > Since @Transactional moved to JTA, I think it might be a better idea to move @Asynchronous to the Concurrency spec. Not sure about @Pooled though, but @Schedule and @Lock probably should be best at home in the Concurrency spec as well.
> +1 to move @Transactional to concurrency spec. However: @Asynchronous should also define in which (Managed)ExecutorService the bean is going to be executed.
> >
> >
> > In JSR 375 we (EG) unfortunately did not go into any aspects of modern rest security, which is a real shame.
> >
> > Yes and no. There are no specific authentication mechanisms provided such as OAuth2 or JWT, but the spec was really careful to make sure it does work well with REST endpoints. The RI specifically tests for this. See https://github.com/javaee/security-soteria/tree/master/test/app-jaxrs
> >
> > With the primitives that were put in place it's easy to do something like this:
> >
> > http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
> >
> >
> > 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.
> >
> > I'm not so sure if it really fell onto a trap of any kind.
> >
> > There were simply many issues to be addressed and only so much time and resources available. The artefacts that were specified were basically the low hanging fruit and addressed basic gaps in the existing specs.
> >
> > 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.
> >
> > Absolutely, and in my mind that was always the idea basically. It's certainly what we had in mind for Payara.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> > 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
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 15 Oct 2017 14:15:33 -0400
> From: reza_rahman <reza_rahman@xxxxxxxxx>
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
> Message-ID: <mailman.83.1508095106.32427.ee4j-community@xxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> When I/others suggested this to the CDI EG in the past, they resisted for what seemed to me like non-technical reasons. Maybe they will change their mind this time and see reason. We can hope. Other than CDI, I don't even see where else @PoolScoped would fit.
> I don't actually mind just throwing it in with the rest into Java EE Concurrency. What matters is making the functionality available to end users in the end.
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> -------- Original message --------From: arjan tijms <arjan.tijms@xxxxxxxxx> Date: 10/14/17 3:59 PM (GMT-05:00) To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
> Hi,
>
> On Sat, Oct 14, 2017 at 8:07 PM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> Personally I think @Pooled/@PoolScoped is best in CDI. The remainder of the EJB functionality can be pretty cleanly farmed out between Java EE Concurrency and JMS/JCA.
> Despite the fact that we seem to want to make CDI somewhat smaller, I think this is indeed a very good suggestion. Thx! @Pooled feels basic enough to warrant being in CDI core indeed.
> Things like the build-in beans for Principal and HttpServletRequest should really be moved to the specifications that own these artefacts in the first place. I already proposed for Java EE Security taking ownership of the Principal build-in bean.
> Kind regards,Arjan Tijms
> ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171015/22d15e32/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 123
> **********************************************
>
> _______________________________________________
> 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
workshops.adam-bien.com
webstandards.training
javaeemicro.services
adambien.blog
Author of:
"Real World Java EE Night Hacks”,
"Real World Java EE Patterns— Rethinking Best Practices"
