There are two problems with this.
1. The LoginConfigInterceptor is not considering operation in an aggregate
deployment like an ear that can have multiple login-config.xml descriptors. It
would just work if very login-config.xml was distinct, but it will fail if
there are overlapping
I have a working prototype of the EJBDeployer that can be enhanced with a
LoginConfigInterceptor either statically or dynamically. It detects the
presense of META-INF/login-config.xml and creates/destroys the security domains
upon deployment undeployment of an ejb jar.
I modified slightly
I came across an interesting problem: Deployers register to the MainDeployer
using their direct reference (this), so calls don't go through the MBeanServer
and thus cannot be intercepted.
I can trick this by registering a dynamic proxy instead, but there seem to be
some problems with deployers
Not without looking at the code, which you can do just as well as I can.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3858733#3858733
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3858733
Ok, I was looking in the code anyway, the question was really if there are any
known/obvious issues with dynamic proxies and equality, e.g proxies
added/removed from LinkedList.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3858771#3858771
Reply to the post :
The only reason for that downcast is to get at global resources
for the bootstrap context. It is not downcasting to use the object as a
deployer.
This is just lazy/bad design on my part.
It should really be using injection, i.e. the deployer does the following
during deployment
Thanks, I'm slowly seeing other issues as well:
Do you know how proxies generated by either MBeanServerInvocationHandler or
MBeanProxyExt handle hashCode() and equals() ?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3858718#3858718
Reply to the post :
If I understand, DynamicLoginConfig is associated with a new deployment in
order to add optional security domain configuration information.
(BTW, since this new security domain information is registered to the
XMLLoginConfig reporitory, it can be used by any module, so there is no scoping
for
Ok, I've found some links, so I'll take it from there.
http://www.jboss.org/wiki/Wiki.jsp?page=DynamicLoginConfig
http://www.jboss.com/?module=bbop=viewtopict=56620
http://www.jboss.org/index.html?module=bbop=viewtopicp=3856209#3856209
View the original post :
There is no explicit user of the DynamicLoginConfig in the server codebase as
this is handled statically via the login-config.xml. This service is used by
deployments that want to be able to augment the login-config as part of their
deployment process. The testsuite security unit tests make use
It seems to me the primary goal is to write an interceptor that does the
security domain addition/removal.
Whether this interceptor gets injected statically to a XMBean-ized deployer or
dynamically seems to be less important.
In the latter case, I guess the usecase would be that you want to
Correct, except that there is no restriction on what deployers may need this
interceptor. Any deployment can have a component that uses the security service
and if the deployment bundles the security domain configuration it would need
this interceptor.
Another equivalent example would be a
So the still missing piece is a generalization of the deployment that
eliminates all of the duplicate file and url processing that exists today for
manipulating resources in the deployment, including unpacking of the deployment
into the tmp/deploy directory.
A simple initial test usecase is to
13 matches
Mail list logo
