Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] Weld 5 CR release is now available
Right, there has been no change to the platform spec or TCK at this point, so dealing with a security manager would be required. Even if we do decide to relax the requirements in the finalization of the spec and platform TCKs, we would not preclude implementations from supporting a security manager since it has not been removed from any available Java runtime.

On Feb 24, 2022 at 7:53:50 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
This conversation does not sound like a specification issue, rather an implementation preference.  Shouldn't this be taken up with the implementation community?

Regardless, for EE 10, I do believe the specification has defined behavior for when a security manager is present.  There is no change there.  Even on Java 18 an implementation can launch Java with options to allow a security manager to be set, at least last time I checked Java 18 still allowed "-Djava.security.manager=allow" (see https://openjdk.java.net/jeps/411).  That means even on Java 18 we must be able to function properly with a security manager if it is present.


Tom
From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of Matej Novotny <manovotn@xxxxxxxxxx>
Sent: Thursday, February 24, 2022 7:38 AM
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cdi-dev] Weld 5 CR release is now available
 
On Thu, Feb 24, 2022 at 2:18 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote: Hi, On Thu, Feb 24, 2022 at 11:19 AM Matej Novotny <manovotn@xxxxxxxxxx> wrote: EE 10 is targetting JDK 11 and 17, so I am afraid I don't see how crashing ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd


On Thu, Feb 24, 2022 at 2:18 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Thu, Feb 24, 2022 at 11:19 AM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
EE 10 is targetting JDK 11 and 17, so I am afraid I don't see how crashing users that aren't even on 18 sends the right signal?

It sounds negative when you put it like that, we never want to crash users, but yes, that's what it amounts to. I mean, by adding security actions you are essentially inviting users to start using the security manager now (since presumably they could not use it before because of those omissions), where we should be motivating them to start moving away.

I am sorry, I tend to put things the way I see it whether it sounds negative or otherwise :-)
And I get your point but I don't see aligning this new piece of code with existing bits as an invitation but rather as a consistency matter. If SM indeed becomes optional, then we can move away from it and I'll be more than happy to get rid of that code throughout Weld.

Also note that Weld is consumed by various EE vendors all of which would have to adopt the same policy which I am not quite sure is the case ATM.
 

Moving away will be a long process, so it has to start soon. If people gradually start reducing their usage of the security manager now, they may be ready on time for when the next LTS is released.

Again, it's like fixing bugs in Applets and inviting users to move new code to Applets, when you know it's going away soon.
 
Or are you telling me GlassFish will forbid usage of SM even as it releases EE 10 compatible version?

Well, indeed. The EE 10 TCK should probably make running with the security manager optional, and then GlassFish would indeed not necessarily pass anymore with the security manager enabled (as it's required now).

A similar thing was done with e.g. JSP support in Faces. We long ago knew it was going to be removed, so new features were explicitly not specified to be usable with JSP (even as there was technically no such barrier). Supporting JSP still would send the wrong signal, as it was something we wanted to move people away from, not towards.

In order to make GlassFish run on JDK 18 I indeed had to remove some usages of the security manager already.
 
Once JDK 18+ gets supported, I suppose we'll have to use an MR JAR (or maybe there is a better solution, haven't thought about it much) but until then, we are bound to support it somehow :-/

IFF EE 10 makes running with the security manager optional (and there was indeed discussion about this) then you may not be bound to that so much, at least not in new code (new version of products).

Interesting, I didn't know that discussion took place (but I am glad it did!). Do you have a link to it?
 

Kind regards,
Arjan Tijms

 

Regards
Matej


On Wed, Feb 23, 2022 at 5:14 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Wed, Feb 23, 2022 at 4:19 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
I do know that SM should be removed in the future, but we're no there yet. But maybe I am missing something. 

That future is getting closer and closer, since JDK 18 is about to be released which throws exceptions when the securitymanager is set. To that end, adding security actions where we maybe should be removing them instead, seems to send the wrong signal.

Kind regards,
Arjan
 
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top