Date   

Application Client and Security 1.0?

Kevin Sutter
 

Hi,
Looking at Figure EE.2-1 and I see that Security 1.0 is listed as part of the Application Client.  I knew about the discussion to include Security 1.0 in the Web Profile.  I was not aware of it being included in the App Client.  I don't know if I have strong opinions one way or the other on this one...  But, if it is meant to be included in the App Client, then don't we also have to include JASPIC in the app client (due to the dependency of Security on JASPIC)?

Was the inclusion of Security in the App Client discussed and I missed it?  In any case, an update to the Figure will be required to get the App Client definition properly updated.  Is this Figure the only location where the specific content of the App Client is defined?

Thanks,
Kevin


Re: Application Client and Security 1.0?

Arjan Tijms
 

Hi Kevin,

I know nothing about support for the Application Client Container and Java EE Security. To be honest, I don't know much about the ACC at all, but doesn't it work via a kind of automatic remote EJB?

At the very least, JASPIC nor Java EE Security have any kind of support for remote EJB. This was discussed, but because of resources constraints in the JSR 375 EG as well as the deemphasis of (remote) EJB and the ACC we decided not to pursue standardisation for the 1.0 release of the Java EE Security API.

Kind regards,
Arjan Tijms


Re: Application Client and Security 1.0?

Linda DeMichiel
 

Hi Kevin,

This looks like a cut-and-paste bug. 

Table EE.6-1 indicates that Security 1.0 is not a requirement for Application Clients.

Thanks again for your diligence in reviewing the spec.

-Linda


On 6/6/17, 1:19 PM, Kevin Sutter wrote:
Hi,
Looking at Figure EE.2-1 and I see that Security 1.0 is listed as part of the Application Client.  I knew about the discussion to include Security 1.0 in the Web Profile.  I was not aware of it being included in the App Client.  I don't know if I have strong opinions one way or the other on this one...  But, if it is meant to be included in the App Client, then don't we also have to include JASPIC in the app client (due to the dependency of Security on JASPIC)?

Was the inclusion of Security in the App Client discussed and I missed it?  In any case, an update to the Figure will be required to get the App Client definition properly updated.  Is this Figure the only location where the specific content of the App Client is defined?

Thanks,
Kevin


URL redirects from java.net pages to new pages on github?

Ondrej Mihályi
 

Dear Java EE and java.net maintainers,

Since java.net was shutdown, most of the content has been migrated to github. However, although much of the content is available, it's not easy to find it because there are still many links refereing to java.net on the internet and even search engines like google yield these old links among the to results.

Is it possible to set up a redirect from java.net to the new pages for the content that is already migrated and easy to map from the old URL to the new URL?
This should be easy for all JIRA issues migrated to github issues, because the issue ID was preserved in github. Many JIRA issues are also referenced from SCM commits and it's not easy to find the issue information now. Also, project pages should be rather easy to redirect - e.g. grizzly.java.net to grizzly.github.io and the same for glassfish once the page is migrated to glassfish.github.io. It's a pity that the content is (or will be) there, but old links won't work for it.

I hope this can be sorted out in the future, otherwise Java EE will become very confusing for developers with all those broken links all over the internet. The is damaging even now and the current state will become catastrophic and unreversible for Java EE in a longer term if not mitigated.

--Ondro


Inconsistent or incomplete usage of @Repeatable

Kevin Sutter
 

Hi,
I know we discussed this back in May of 2016, but actual practice is causing us to scratch our heads...  Without the @Repeatable annotation usage being spelled out at the Platform level, we're discovering some inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on several of their annotations.  And, Common Annotations has identified the use with @Resource and @DataSourceDefinition.  But, what about @EJB?  It seems that this would be another valid usage of @Repeatable.  So, with each spec deciding for themselves whether to support @Repeatable, we don't have a consistent story for our users.  It won't be intuitive.  Sometimes you can skip the plural form of the annotation, and sometimes you can't.  You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure if the @EJB is the only miss.  If we're down to just a handful of misses, should we step up to support these additional @Repeatables in Java EE 8?

Thanks, Kevin


Re: Inconsistent or incomplete usage of @Repeatable

Linda DeMichiel
 

Hi Kevin,

I agree that consistency here would be desirable.
However, in planning for Java EE 8 we had to prioritize
resources around updating those specs we felt it most
important to focus on, with the expectation that we
would handle any missing @Repeatable updates when the
others were next updated.

@EJB is not the only miss. You can see the remainders
by scrolling through the JIRA issue here:
https://github.com/javaee/javaee-spec/issues/36.

In particular, since JMS and Connector are not being
updated in this release, those annotations will still
not be repeatable either.

-Linda

On 6/21/17, 12:08 PM, Kevin Sutter wrote:
Hi,
I know we discussed this back in May of 2016, but actual practice is
causing us to scratch our heads... Without the @Repeatable annotation
usage being spelled out at the Platform level, we're discovering some
inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on
several of their annotations. And, Common Annotations has identified
the use with @Resource and @DataSourceDefinition. But, what about
@EJB? It seems that this would be another valid usage of @Repeatable.
So, with each spec deciding for themselves whether to support
@Repeatable, we don't have a consistent story for our users. It won't
be intuitive. Sometimes you can skip the plural form of the annotation,
and sometimes you can't. You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure
if the @EJB is the only miss. If we're down to just a handful of
misses, should we step up to support these additional @Repeatables in
Java EE 8?

Thanks, Kevin


Re: Inconsistent or incomplete usage of @Repeatable

reza_rahman <reza_rahman@...>
 

I had helped develop the initial JIRA on this and I do not think EJB is the only miss, though it may be the major miss. I also agree this is an important issue to get right.

-------- Original message --------
From: Kevin Sutter <kwsutter@...>
Date: 6/21/17 3:08 PM (GMT-05:00)
To: javaee-spec@javaee.groups.io
Subject: [javaee-spec] Inconsistent or incomplete usage of @Repeatable

Hi,
I know we discussed this back in May of 2016, but actual practice is causing us to scratch our heads...  Without the @Repeatable annotation usage being spelled out at the Platform level, we're discovering some inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on several of their annotations.  And, Common Annotations has identified the use with @Resource and @DataSourceDefinition.  But, what about @EJB?  It seems that this would be another valid usage of @Repeatable.  So, with each spec deciding for themselves whether to support @Repeatable, we don't have a consistent story for our users.  It won't be intuitive.  Sometimes you can skip the plural form of the annotation, and sometimes you can't.  You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure if the @EJB is the only miss.  If we're down to just a handful of misses, should we step up to support these additional @Repeatables in Java EE 8?

Thanks, Kevin


Re: Inconsistent or incomplete usage of @Repeatable

Kevin Sutter
 

Wow.  I guess @EJB was not the only miss...  I didn't think too hard before asking that...  :-)  In any case, thanks for the pointer to the JIRA.  I missed that reference when I went back in the archives.  We'll have to add that JIRA to our required list of TODOs for Java EE 9.  I agree that this looks to be too much to consider at this point.

Thanks, Kevin

On Wed, Jun 21, 2017 at 2:34 PM, Linda DeMichiel <linda.demichiel@...> wrote:
Hi Kevin,

I agree that consistency here would be desirable.
However, in planning for Java EE 8 we had to prioritize
resources around updating those specs we felt it most
important to focus on, with the expectation that we
would handle any missing @Repeatable updates when the
others were next updated.

@EJB is not the only miss.  You can see the remainders
by scrolling through the JIRA issue here:
https://github.com/javaee/javaee-spec/issues/36.

In particular, since JMS and Connector are not being
updated in this release, those annotations will still
not be repeatable either.

-Linda



On 6/21/17, 12:08 PM, Kevin Sutter wrote:
Hi,
I know we discussed this back in May of 2016, but actual practice is
causing us to scratch our heads...  Without the @Repeatable annotation
usage being spelled out at the Platform level, we're discovering some
inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on
several of their annotations.  And, Common Annotations has identified
the use with @Resource and @DataSourceDefinition.  But, what about
@EJB?  It seems that this would be another valid usage of @Repeatable.
So, with each spec deciding for themselves whether to support
@Repeatable, we don't have a consistent story for our users.  It won't
be intuitive.  Sometimes you can skip the plural form of the annotation,
and sometimes you can't.  You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure
if the @EJB is the only miss.  If we're down to just a handful of
misses, should we step up to support these additional @Repeatables in
Java EE 8?

Thanks, Kevin






Re: Inconsistent or incomplete usage of @Repeatable

Arjan Tijms
 

I think one of the issues, and for me this is huge issue, is how the JCP process is set up. In order to make changes in specs, even if they are platform initiated, specs have to be active. But specs can really only be active if they are planned to be active.

Here it's some relatively simple annotations that have to be changed throughout many specs, but I've seen this in other cases too.

For example, JSF (and JSP) extracted their expression language functionality into a separate spec (EL 3). Separation is good, since this allows specs to evolve at their own pace.

Except, for Java EE 8 it wasn't planned to make the EL spec active, and thus it couldn't be active. Now at some point the JSF EG needed to make a change in an EL class, but we could not do it, since the EL spec was not active and could not be made active because of the aforementioned planning.

Had JSF not extracted EL but kept it to itself the change would have been trivial to make. In other words, the current process in some way encourages specs not to extract functionality into separate specs.

I fully realise it's much easier said then done, but I would like to propose a kind of tree mechanism in how specs are organised, such that a "parent" spec can take responsibility of "child" specs. With EE Umbrella being the parent of them all, that EG could make changes in any spec if that spec would be unfortunate enough to be missed in the planning to be active.

In this case, the EE 8 umbrella EG could make the necessary changes for annotations in all specs that are currently not active or get a MR.

I know this can't be changed for EE 8 now, but just a thought going forward.

Kind regards,
Arjan Tijms






On Wed, Jun 21, 2017 at 9:47 PM, Kevin Sutter <kwsutter@...> wrote:
Wow.  I guess @EJB was not the only miss...  I didn't think too hard before asking that...  :-)  In any case, thanks for the pointer to the JIRA.  I missed that reference when I went back in the archives.  We'll have to add that JIRA to our required list of TODOs for Java EE 9.  I agree that this looks to be too much to consider at this point.

Thanks, Kevin

On Wed, Jun 21, 2017 at 2:34 PM, Linda DeMichiel <linda.demichiel@...> wrote:
Hi Kevin,

I agree that consistency here would be desirable.
However, in planning for Java EE 8 we had to prioritize
resources around updating those specs we felt it most
important to focus on, with the expectation that we
would handle any missing @Repeatable updates when the
others were next updated.

@EJB is not the only miss.  You can see the remainders
by scrolling through the JIRA issue here:
https://github.com/javaee/javaee-spec/issues/36.

In particular, since JMS and Connector are not being
updated in this release, those annotations will still
not be repeatable either.

-Linda



On 6/21/17, 12:08 PM, Kevin Sutter wrote:
Hi,
I know we discussed this back in May of 2016, but actual practice is
causing us to scratch our heads...  Without the @Repeatable annotation
usage being spelled out at the Platform level, we're discovering some
inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on
several of their annotations.  And, Common Annotations has identified
the use with @Resource and @DataSourceDefinition.  But, what about
@EJB?  It seems that this would be another valid usage of @Repeatable.
So, with each spec deciding for themselves whether to support
@Repeatable, we don't have a consistent story for our users.  It won't
be intuitive.  Sometimes you can skip the plural form of the annotation,
and sometimes you can't.  You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure
if the @EJB is the only miss.  If we're down to just a handful of
misses, should we step up to support these additional @Repeatables in
Java EE 8?

Thanks, Kevin







Java EE 8 Proposed Final Draft

Linda DeMichiel
 

I've just uploaded to our project documents area
(https://github.com/javaee/javaee-spec/tree/master/download) the
drafts of the Java EE 8 Platform and Web Profile specification
documents that we plan to submit to the JCP for Proposed Final Draft.

The drafts have changebars indicating all changes made to the
documents since the Public Review draft. Changes are also
summarized in the appendices.

Changes in this draft are quite minimal, mostly to sync with
updates in the Java Security API.

At this point we are not anticipating much further in the way of
updates to the Platform spec, other than what might be needed to
reflect any further updates to Java EE Security.

Please let me know if you find any issues.

thanks,

-Linda


Java EE 8 Platform and Web Profile Final Draft specs

Linda DeMichiel
 

Greetings,

I've just uploaded Final Draft versions of the Java EE and Web Profile
specifications to our Java EE downloads area:
https://github.com/javaee/javaee-spec/tree/master/download.

These are the versions that we to submit to the JCP later this week
for the Final Approval Ballot.

The few changes from the Proposed Final Draft of the Java EE
Platform specification are referenced in Appendix EE.B.
Briefly, these include minor clarifications regarding
metadata-complete for application clients and updates to
the Security chapter to align with the requirements of
the Java EE Security API.

The contents of the Web Profile specification are unchanged
from the Proposed Final Draft.

regards,

-Linda


RMI-IIOP proposed optional

Jens Engel
 

Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens


Re: RMI-IIOP proposed optional

Bill Shannon
 

Hi Jens.

First of all, there is nothing named "JEE".  The correct name is "Java EE".

"Proposed optional" means that it might be declared optional in the next release.  In Java EE 8, it is still required.

In the next release, we will consider whether the time is right to make this technology optional.  If it is made optional, vendors will not be required to include it in their products.  Still, we expect many products with a large customer base to continue to provide it so as to support their existing customers.  If you depend on it and your vendor drops support for it, you might need to take advantage of the portability of Java EE applications and move to a new vendor.

While RMI-IIOP might be made optional, support for remote EJB invocations using EJB 3 style EJBs, including transaction support, will still be required.  The protocol used might be RMI-IIOP or it might be a vendor-specific protocol; the spec would no longer require a specific protocol.

The feedback we've gotten from the vast majority of customers is that use of remote EJB invocations between independently deployed applications is no longer a best practice.  Web technologies such as JAX-WS or especially JAX-RS are greatly preferred.  Such loosely coupled components will not depend on distributed transactions.  We would encourage new applications to use a more web-centric architecture, although remote EJBs will remain for applications that need them.

    Bill

Jens Engel wrote on 08/ 2/17 07:34 AM:

Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens


Re: RMI-IIOP proposed optional

Jeff Genender
 


On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

Jeff


Re: RMI-IIOP proposed optional

Bill Shannon
 

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)


Re: RMI-IIOP proposed optional

reza_rahman <reza_rahman@...>
 

The community does actually try to correct this when they can. Your efforts are not falling on deaf ears.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Bill Shannon <bill.shannon@...>
Date: 8/2/17 3:30 PM (GMT-05:00)
To: javaee-spec@javaee.groups.io
Subject: Re: [javaee-spec] RMI-IIOP proposed optional

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)


Re: RMI-IIOP proposed optional

Jason Greene
 


On Aug 2, 2017, at 2:30 PM, Bill Shannon <bill.shannon@...> wrote:

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)

I’m with you!

-Jason


Re: RMI-IIOP proposed optional

Guillermo González de Agüero
 

Reading it a bit more thoroughly, "Proposed Optional" just means that a future Java EE version could make it optional. It will still be required to work on Java EE 8, but the EG can make it definitely optional on Java EE 9.

Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 19:05, Guillermo González de Agüero (<z06.guillermo@...>) escribió:
Hi Jens,

As I read it, it just means that application servers won't need to provide remote EJBs based on RMI-IIOP starting from Java EE 8. Remote EJBs will still have the same features, although vendors will be able to base them on another technology.

As for Java EE 7, remote EJBs *must * work over RMI-IIOP and implementations are *allowed* to use additional protocols.

Hopefully some EG member will be able to confirm my interpretation.


Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 18:43, Jens Engel (<jens.engel@...>) escribió:
Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens


Re: RMI-IIOP proposed optional

Guillermo González de Agüero
 

Hi Jens,

As I read it, it just means that application servers won't need to provide remote EJBs based on RMI-IIOP starting from Java EE 8. Remote EJBs will still have the same features, although vendors will be able to base them on another technology.

As for Java EE 7, remote EJBs *must * work over RMI-IIOP and implementations are *allowed* to use additional protocols.

Hopefully some EG member will be able to confirm my interpretation.


Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 18:43, Jens Engel (<jens.engel@...>) escribió:
Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens


Re: RMI-IIOP proposed optional

Werner Keil
 

I tend to take those less serious than others, but as Java and IT consultant you still stumble over requests to help a project with "J2EE" after all those years ;-)