1. javaee-spec@javaee.groups.io
   Date   
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



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

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

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
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
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
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
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
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: Location of downloadable files?

Kevin Sutter
 

Excellent, Bill!  Thanks for that link.  I agree that we need that link somewhere more obvious.

--  Kevin

On Tue, Jun 6, 2017 at 2:41 PM, Bill Shannon <bill.shannon@...> wrote:
All the downloads from our original java.net project are still available in the GitHub repository here.  I should probably add a link from the web site to make it more obvious.

Kevin Sutter wrote on 06/ 6/17 07:13 AM:
Hi Linda,
Where can we get access to downloadable files?  The current groups.io repo doesn't have any files (https://javaee.groups.io/g/javaee-spec/files).  And, if I try to go to our old repo on java.net (https://java.net/projects/javaee-spec/downloads), we are no longer allowed access.  Not only am I interested in the early drafts of the Java EE 8 specs, javadocs, schemas, etc, but also the older versions. 

Thanks, Kevin
Re: Location of downloadable files?

Bill Shannon
 

Note that the schemas are in GitHub here.

Kevin Sutter wrote on 06/ 6/17 11:29 AM:

Thanks, Linda.  Do we expect any early versions of the schemas before the Java EE 8 spec finalizes?  I wouldn't expect too many changes, just looking ahead...  Thanks.

-- Kevin

On Tue, Jun 6, 2017 at 11:19 am, Linda DeMichiel wrote:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

 
Re: Location of downloadable files?

Bill Shannon
 

All the downloads from our original java.net project are still available in the GitHub repository here.  I should probably add a link from the web site to make it more obvious.

Kevin Sutter wrote on 06/ 6/17 07:13 AM:

Hi Linda,
Where can we get access to downloadable files?  The current groups.io repo doesn't have any files (https://javaee.groups.io/g/javaee-spec/files).  And, if I try to go to our old repo on java.net (https://java.net/projects/javaee-spec/downloads), we are no longer allowed access.  Not only am I interested in the early drafts of the Java EE 8 specs, javadocs, schemas, etc, but also the older versions. 

Thanks, Kevin
Re: Location of downloadable files?

Linda DeMichiel
 

Since some specs are still evolving, I would expect this closer to the end.

-Linda


On 6/6/17, 11:29 AM, Kevin Sutter wrote:
Thanks, Linda.  Do we expect any early versions of the schemas before the Java EE 8 spec finalizes?  I wouldn't expect too many changes, just looking ahead...  Thanks.

-- Kevin

On Tue, Jun 6, 2017 at 11:19 am, Linda DeMichiel wrote:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

 
Re: Location of downloadable files?

Kevin Sutter
 

Thanks, Linda.  Do we expect any early versions of the schemas before the Java EE 8 spec finalizes?  I wouldn't expect too many changes, just looking ahead...  Thanks.

-- Kevin


On Tue, Jun 6, 2017 at 11:19 am, Linda DeMichiel wrote:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

 
Re: Location of downloadable files?

Linda DeMichiel
 

Hi Kevin,

The downloadables from our old projects have not yet been migrated.  I believe that will happen at
some point this summer.

All milestone spec drafts can be found on the JCP JSR pages (e.g., https://jcp.org/en/jsr/detail?id=366).
Schema files are here: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

hth,

-Linda




On 6/6/17, 7:13 AM, Kevin Sutter wrote:
Hi Linda,
Where can we get access to downloadable files?  The current groups.io repo doesn't have any files (https://javaee.groups.io/g/javaee-spec/files).  And, if I try to go to our old repo on java.net (https://java.net/projects/javaee-spec/downloads), we are no longer allowed access.  Not only am I interested in the early drafts of the Java EE 8 specs, javadocs, schemas, etc, but also the older versions. 

Thanks, Kevin
Location of downloadable files?

Kevin Sutter
 

Hi Linda,
Where can we get access to downloadable files?  The current groups.io repo doesn't have any files (https://javaee.groups.io/g/javaee-spec/files).  And, if I try to go to our old repo on java.net (https://java.net/projects/javaee-spec/downloads), we are no longer allowed access.  Not only am I interested in the early drafts of the Java EE 8 specs, javadocs, schemas, etc, but also the older versions. 

Thanks, Kevin
Re: Where are we discussing the Interceptor spec?

Kevin Sutter
 

Thanks, Linda.  I'll cross-post to the interceptor mailing list as well just to complete the picture...

Kevin

On Fri, Jun 2, 2017 at 2:32 PM, Linda DeMichiel <linda.demichiel@...> wrote:
Hi Kevin,

Thanks for calling this to my intention.  It looks like
the spec was ambiguous enough that it could be parsed
with a meaning that I did not intend.  I'll comment further
on the JIRA issue and then clarify the spec.

We set up a groups.io mailing list for the Interceptors
spec (https://javaee.groups.io/g/interceptors-spec), so
it would be best to pursue interceptors-specific topics
there.

regards,

-Linda



On 6/2/17, 11:12 AM, Kevin Sutter wrote:
Hi,
Are we discussing the updated Interceptor spec here?  I know we had some discussions related to this update on the Java EE mailing list, but since it was released as part of the EJB family of specs, should we comment on the EJB mailing list?

I ran this update past our CDI EG member and she discussed it with the wider Weld community (RI).  It sounds like there is an issue with CDI and some of the proposed updates.  Weld opened the following spec issue, but I thought it would be good to post to it to the wider community to ensure that everybody can discuss it.

https://github.com/javaee/interceptors-spec/issues/33

Maybe I'm doing that just be posting this message?  :-)

Thanks,
Kevin
Re: Where are we discussing the Interceptor spec?

Linda DeMichiel
 

Hi Kevin,

Thanks for calling this to my intention.  It looks like
the spec was ambiguous enough that it could be parsed
with a meaning that I did not intend.  I'll comment further
on the JIRA issue and then clarify the spec.

We set up a groups.io mailing list for the Interceptors
spec (https://javaee.groups.io/g/interceptors-spec), so
it would be best to pursue interceptors-specific topics
there.

regards,

-Linda


On 6/2/17, 11:12 AM, Kevin Sutter wrote:
Hi,
Are we discussing the updated Interceptor spec here?  I know we had some discussions related to this update on the Java EE mailing list, but since it was released as part of the EJB family of specs, should we comment on the EJB mailing list?

I ran this update past our CDI EG member and she discussed it with the wider Weld community (RI).  It sounds like there is an issue with CDI and some of the proposed updates.  Weld opened the following spec issue, but I thought it would be good to post to it to the wider community to ensure that everybody can discuss it.

https://github.com/javaee/interceptors-spec/issues/33

Maybe I'm doing that just be posting this message?  :-)

Thanks,
Kevin
Where are we discussing the Interceptor spec?

Kevin Sutter
 

Hi,
Are we discussing the updated Interceptor spec here?  I know we had some discussions related to this update on the Java EE mailing list, but since it was released as part of the EJB family of specs, should we comment on the EJB mailing list?

I ran this update past our CDI EG member and she discussed it with the wider Weld community (RI).  It sounds like there is an issue with CDI and some of the proposed updates.  Weld opened the following spec issue, but I thought it would be good to post to it to the wider community to ensure that everybody can discuss it.

https://github.com/javaee/interceptors-spec/issues/33

Maybe I'm doing that just be posting this message?  :-)

Thanks,
Kevin
Java EE 8 - Release Date

Josh Juneau
 

Hi Linda/All,

Hope all is well.  Earlier this week, Mark Reinhold posted an email proposing to move the release date of JDK 9 back to September 21 (http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html).  As such, do you believe that the proposed delay would have any impact on the release date of Java EE 8?  

Since Java EE 8 is going to align with Java SE 8, I imagine that there should be no major technical impact if Java EE 8 were released prior to Java SE 9, but I'm just not certain of Oracle's release plan. 

Thanks for your time and insight, it is appreciated.

Thanks
Josh Juneau
juneau001@...
61 - 80 of 89  
More
Home Messages Hashtags About Features Pricing Updates Terms Help Twitter