Originally posted by Mark Herschberg:
You can just put the rest of the code in a code block to mimic this behavior. Isn't that what Java does under the hood anyway with a break?
--Mark
Originally posted by Shiaber Shaam:
[QB]Hi all,
Could anyone please provide me a link of basic EJB Tutorial.
/QB]
Originally posted by Ulf Dittmer:
The theory is that the user is in charge of his own machine (and is trusted to do the right thing), whereas the application by default is not. If the user feels that the application can be trusted, he can allow it to do more things than an untrusted application. Since that requires a conscious act of the user, that is considered OK.
Originally posted by Ulf Dittmer:
Actually, I don't think that this is a case of using a security manager. It sounds to me like many (or all) actions inside of the application will be guarded by JAAS, though (which may use a security manager internally, but it sets that up itself).
The critical issue here isn't so much how the application interacts with the system it's running on (which is what is governed by policy files enforced by security managers), but rather what a properly authenticated user is authorized to do within the application - which is something JAAS can do.
I'm no expert on JAAS, so I'm not sure how it would pick up the Windows login information (unless you want to have the user enter it, and then re-verify it against an LDAP/AD server).
Originally posted by Ulf Dittmer:
I'm not quite clear on what you are trying to achieve by using Permissions and security managers inside of the application. If the application is trusted, it can be run without a security manager and all is well (because it is allowed to do everything). If it is not trusted, then it should be run using a security manager, and any permissions it needs must be part of an external security policy. After all, if it's untrusted, then you wouldn't want the app to specify its own security policy, now would you![]()
I guess I'm missing something here.
Originally posted by Paul Clapham:
If it was in the root of the jar thenshould not find it. But you said initially that it did. That's what led me to believe you didn't put it in the root of the jar.
Originally posted by Paul Clapham:
But do make sure you put it in the root of the jar, where the classpath points to. One of your earlier examples seemed to suggest you had put it in a directory inside the jar file.