Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Time to play the game?

I completely agree.  And having documentation spread across multiple implementation-specific websites, all with their own look-and-feel and levels of detail doesn't help either. 

In general, unless you are doing application server specific work, you don't need to know the name of the implementation project or which organization created it.  That's the entire point of having a standard API


On Wednesday, November 22, 2017, 7:08:51 AM CST, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:


I agree here. For newcomers it’s much easier to understand Spring, because it’s the only thing to understand. I found that people have difficulties understanding a difference between Java EE API and Java EE implementations. The key to success is having nice tutorials like this:


with a nice collection of real use cases.

Dmitry

On 6 Nov 2017, at 16:33, Werner Keil <werner.keil@xxxxxxxxx> wrote:

A lot of those "hip new" players in the Microservice space share the problem of being short of good examples or tutorials.

I try my best to help some of those catch up with the pace of specs and features at MicroProfile. Right now on average samples and tutorials are at least one version behind what's released. Which for a slower moving stack like Java EE 6-8 was OK, books, examples or tutorials should still be fine a few months from now, but for a faster moving "Agile" kind of approach this won't work.

The joke "I was on vacation for 2 weeks, are my Angular skill still relevant?" has a lot of truth in it.

Werner


On Mon, Nov 6, 2017 at 12:10 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@ 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: Use of javax.* in new EE4J projects (Greg Luck)
   2. Re: Use of javax.* in new EE4J projects (arjan tijms)
   3. Re: Time to play the game? (Rodolfo Fortes)


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

Message: 1
Date: Sun, 5 Nov 2017 13:28:18 -0800
From: Greg Luck <gluck@xxxxxxxxxxxx>
To: Bill Shannon <bill.shannon@xxxxxxxxxx>
Cc: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID: <7D087516-3C80-4123-99DC- EF85076BACB2@xxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Bill

I would also very luck like JCache 1.1 to be included in EE4J. In 1.1 we fixed the license issue which was blocking wider adoption (use of JSPA license for the APIs not an open source one).

JCache 1.1 is evolving inside the JCP. It is in review now and will go to vote in a week or so.

We have 13 implementations of the 1.0 spec.

What is missing now is integration into Enterprise Java for ease of use by end users.

Regards
Greg Luck


> On 3 Nov 2017, at 1:06 pm, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
> It would be great to include JCache in EE4J!
>
> Any API that continues to evolve through the JCP can continue to use javax.* package names as it always has.
>
> We're still working out the rules for existing JCP specs that want to evolve outside of the JCP.  Clearly JCache is an existing JCP spec.
>
> Completely new specs outside of the JCP should not expect to use javax.* package names.
>
> Greg Luck wrote on 11/ 3/17 11:07 AM:
>> Hi
>>
>> Had a call with Mike today about moving JCache across to EE4J.
>>
>> We have JCache 1.1 in the JCP review process now and it should be out in a few weeks? time. So we could consider moving after that point.
>>
>> The biggest issue to me is that, at least currently, any new APIs will not be allowed to use javax. Today we use javax.cache. This would mean that JCache 2 would need to change its package name. We have 13 implementations out there and a huge amount of user code that uses javax.cache. This would be an extremely disruptive change.
>>
>> In our case Oracle is a copyright owner along with myself for the spec. As an owner, Oracle if they wished, should be able to allow JCache 2 to continue to use the javax.cache package even though the process has changed from JCP to the yet unnamed and to be formed Eclipse Community Process.
>>
>> Interested in anyone?s thoughts on this.
>>
>> Regards
>>
>> Greg Luck
>>
>>
>>
>>
>> ______________________________ _________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@ eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/ mailman/listinfo/ee4j- community <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/ 20171105/8789075c/attachment. html>

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

Message: 2
Date: Sun, 5 Nov 2017 23:03:09 +0100
From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID:
        <CAE=-AhDj0eZ9PbczMtmy9kk2uoN5 jjUBc9fcOZxB8dRWQsCBOA@mail. gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

On Sun, Nov 5, 2017 at 10:28 PM, Greg Luck <gluck@xxxxxxxxxxxx> wrote:

> What is missing now is integration into Enterprise Java for ease of use by
> end users.
>

Integration would also be good for other specs / spec implementations. For
Java EE Security I'd love to use an authorization cache without the need
for any custom SPI or anything like that.

Kind regards,
Arjan Tijms




>
> Regards
> Greg Luck
>
>
> On 3 Nov 2017, at 1:06 pm, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
> It would be great to include JCache in EE4J!
>
> Any API that continues to evolve through the JCP can continue to use
> javax.* package names as it always has.
>
> We're still working out the rules for existing JCP specs that want to
> evolve outside of the JCP.  Clearly JCache is an existing JCP spec.
>
> Completely new specs outside of the JCP should not expect to use javax.*
> package names.
>
> Greg Luck wrote on 11/ 3/17 11:07 AM:
>
> Hi
>
> Had a call with Mike today about moving JCache across to EE4J.
>
> We have JCache 1.1 in the JCP review process now and it should be out in a
> few weeks? time. So we could consider moving after that point.
>
> The biggest issue to me is that, at least currently, any new APIs will not
> be allowed to use javax. Today we use javax.cache. This would mean that
> JCache 2 would need to change its package name. We have 13 implementations
> out there and a huge amount of user code that uses javax.cache. This would
> be an extremely disruptive change.
>
> In our case Oracle is a copyright owner along with myself for the spec. As
> an owner, Oracle if they wished, should be able to allow JCache 2 to
> continue to use the javax.cache package even though the process has changed
> from JCP to the yet unnamed and to be formed Eclipse Community Process.
>
> Interested in anyone?s thoughts on this.
>
> Regards
>
> Greg Luck
>
>
>
>
> ______________________________ _________________
> ee4j-community mailing listee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/ mailman/private/ee4j- community/attachments/ 20171105/adf57f71/attachment. html>

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

Message: 3
Date: Mon, 6 Nov 2017 09:10:18 -0200
From: Rodolfo Fortes <rfortes@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Time to play the game?
Message-ID:
        <CAPyuUiMnMjZScPXN+ X5YrRyEpPxXsSUY+HeQ- jrTTKKopbSoDg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

*So I think, in order to avoid the takeover of other, more verbose,
technologies and practices, Eclipse Fdn has to put a *big* emphasys on
tutorials and clear explanations of concepts. Even though those concepts
are supposed to be understood by the majority*. +1

Couldn't agree more, the best programmers that I know are self-taught,
tutorials and docs plays a major role in the process of learning and
adoption of a technologie, it doesn't matter with we have the best solution
out there if nobody can use it properly.

On Fri, Nov 3, 2017 at 7:24 PM, John Clingan <jclingan@xxxxxxxxxx> wrote:

> MicroProfile added a Config Specification
> <https://projects.eclipse.org/ projects/technology. microprofile/releases/config- 1.1>,
> which was also submitted as the Configuration 1.0 JSR. Java EE application
> servers are beginning to support MicroProfile Config 1.1, so take a look
> there.   The configuration specification provides some OOTB support for
> specifying a configuration (property file, env variables), but vendors are
> expected to extend that (yaml, externalized services, etc).
>
> Hope this helps.
>
>
> On Nov 3, 2017, at 1:30 PM, Guillermo Gonz?lez de Ag?ero <
> z06.guillermo@xxxxxxxxx> wrote:
>
> Welcome Georgios!
>
> Java EE servers are required to provide a default datasource. Creating a
> persistence.xml without a specific datasource must work on all servers.
>
> You can also define datasources with the @DataSourceDefinition annotation
> or via web.xml at application level. The same applies to JMS resources and
> JCA resource adapter administer objects.
>
> It's true that integration between application defined datasources and JPA
> is a bit unclear at spec level but I think it works on most servers now.
>
> A real problem that has made it useless in practice is the need to specify
> database pssswords in plain text on a constant. Recently the Security spec
> (JSR 375) solved it by using _expression_ Language expressions, but I expect
> this all to be handled by the new Config JSR that's already in the making.
>
> Note also that Java EE 8 originally contained a new Management API JSR
> that aimed to provide a standard API to configure servers, but it was
> untimately withdrawn.
>
> I'm not sure this is exactly what you meant. Does it solve part of your
> concern?
>
> Regards,
>
> Guillermo Gonz?lez de Ag?ero
>
> El vie., 3 nov. 2017 21:10, gbourant <gbourant@xxxxxxxxx> escribi?:
>
>> Hello everyone ,
>>
>> Based in my personal experience as a young developer in Java EE ecosystem
>> i think Java EE AS lacks of a central configuration system.
>>
>> As a result it makes difficult for young developers to get started.
>>
>> If you want to configure something you have to edit xml files or use AS's
>> specific cli tools.
>>
>> For example to connect in a database in Payara , you just provide the
>> persistence.xml.
>>
>> To achieve the same in Wildfly you must provide persistence.xml and
>> configure the datasource in AS.
>>
>> To simplify this we can have a file(config.json) and provide project's
>> spesific configuration.
>>
>> example
>>
>> {
>>      "profile" : "full|web|micro"
>>      "datasources" : [],
>>      "app-server-config" : {
>>
>>       }
>> }
>>
>> Based on the above idea we can get rid of persistance.xml or even any
>> other *.xml files.
>>
>> P.S. take it easy on me , it's the first time that i'm writing to a
>> mailing list :-)
>>
>> Thank you,
>> Georgios Bourantas
>>
>> On Nov 3, 2017 2:34 PM, "Rodolfo Fortes" <rfortes@xxxxxxxxx> wrote:
>>
>>>     Well, I guess that there isn't such thing like "fight back", I fight
>>> back enemys and I don't see this frameworks as it. Every framework has it
>>> uses, for a start-up I think this technologies could fit (Spring Boot), we
>>> can learn from their advacements and even incoporate it if it proves to be
>>> something that worth it (no shame on that).
>>>     Docker it's something complementary I can still use it with my Java
>>> EE apps, doesn't see why not, It save some time to a new developer set-up a
>>> environment and it's more easy to control this environmen across all devs.
>>>     And Jigsaw is here to stay, It's part of Java now, and in my point
>>> of view, a necessary one, I will use only the parts that suits my needs, I
>>> don't see how it could be a bad thing.
>>>
>>>     But you have a point when you said " A lot of people seem to not
>>> understand JavaEE", here is where we can do something, we can teach and
>>> show the learn path for this awsome tool that is Java EE. I really didn't
>>> have someone to teach me so my path to learn it was a little bit rough,
>>> what has helped me along the way was the Java EE Tutorial and it's
>>> examples, I would like to say a big thank you for everyone involved in the
>>> Java EE Tutorial, I guess I wouldn't love Java EE like I do now and I don't
>>> know if I would have a job if weren't for you.
>>>     That's it, we have a awsome and powerful tool, let's spread the good
>>> news.
>>>
>>> On Fri, Nov 3, 2017 at 9:59 AM, Mihai A. <amihaiemil@xxxxxxxxx> wrote:
>>>
>>>> Hello All,
>>>>
>>>> I wanted to ask you how is JavaEE going to fight back to Spring and
>>>> project Jigsaw?
>>>>
>>>> Let me explain:
>>>>
>>>> These days, I noticed an increasing trend of developing Java (web)apps
>>>> with Spring + Spring Boot, and running them with Docker. A lot of people
>>>> seem to not understand JavaEE, they cannot use it properly so, naturally,
>>>> they prefer to have a fat deployable and *use Docker just as a simple
>>>> OS wrap*.
>>>>
>>>> Then here comes project *Jigsaw *which, it seems to me, *is an effort
>>>> made in the complete opposite direction of JavaEE*. I read this
>>>> article that kept showing on my Twitter feed:
>>>>
>>>> https://steveperkins.com/ using-java-9-modularization-
>>>> to-ship-zero-dependency- native-apps/
>>>>
>>>> Basically, with Jigsaw, we can create standalone Java apps which do not
>>>> need a preset runtime anymore. It encourages developers to follow the
>>>> monoliths path, building even fatter apps. Because hey, nobody wants to
>>>> take care of setting the JRE. But they will still play Docker just to spin
>>>> the app. Do you see the irony?
>>>>
>>>> I cannot understand why more and more developers build fat applications
>>>> and use Docker only as an OS bubble. Why don't they use Docker for what it
>>>> was meant, for setting an environment, a platform (JavaEE) and keeping
>>>> their applications lightweight?
>>>>
>>>> These days, the developer, instead of focusing on lightweight,
>>>> efficient projects, is burdened with having to know everything: the app
>>>> couples together (tightly!) concepts such as Spring Boot, Jigsaw, Docker.
>>>> Everyone is still happy, they enjoy it, not thinking that we are throwing
>>>> away many years of progress.
>>>>
>>>> Any thoughts on this topic? It's a rather grim view, I know, but I am
>>>> really curious of what the experts believe.
>>>>
>>>> Best regards,
>>>> Mihai Andronache
>>>>
>>>> --
>>>> amihaiemil.com
>>>> https://www.github.com/ amihaiemil
>>>> https://www.twitter.com/ amihaiemil
>>>>
>>>> ______________________________ _________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/ mailman/private/ee4j- community/attachments/ 20171106/339e071e/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 3, Issue 19
****************************** ***************

_______________________________________________
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

Back to the top