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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Jeff Genender wrote on 08/ 2/17 12:08 PM: 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

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

I’m with you! -Jason

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

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

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 ;-)