It looks like both my UserRealm and SimplePrincipal implementations need to be
Serializable.
This will most likely involve a rewrite of their current implementations.
Before I do this could someone confirm that this is the case and perhaps explain the
reasons behind this requirement, so that I
Hi Jules,
You beat me to it on the JBossUserRealm fix :-)
This fixes a problem in 3.0 WebIntegrationUnitTestCase.
Until Marc finishes the classloader stuff, local
invocations will continue to be Marshalled by the
JRMPContainerInvoker :-(
Regards,
Adrian
So is this only a temporary problem ?
If so, then there is no point in rewriting the authentication integration.
Jules
Adrian Brock wrote:
Hi Jules,
You beat me to it on the JBossUserRealm fix :-)
This fixes a problem in 3.0 WebIntegrationUnitTestCase.
Until Marc finishes the classloader
>From the integration point, it is a non-trivial (and unecessary) change.
If you have a simple hack from the JBoss side - go for it.
Jules
Jules Gosnell wrote:
So is this only a temporary problem ?
If so, then there is no point in rewriting the authentication integration.
Jules
Adrian
Hi,
Oops, should have said JRMPInvokerProxy.
There might still be some bizarre case where it
needs to go over a wire.
But, I would have thought the servlet always wants to
invoke a local bean. That's the whole point of
web integration isn't it?
Regards,
Adrian
IMHO, the JBossUserPrincipal has to be serializable. You can't always
assume that the bean invocations from the web tier will be local. Be that
for clustering or whatever. My current project is wide-area distribution
of j2ee apps, where we take an EAR configured to run on a single node and
For the moment, I am not implementing the Security integration between
Jetty and JBoss as Serializable.
I understand why you feel it should be a requirement for the future,
and agree with you. Unfortunately, it is not simply a case of shipping
a string since the same Principal object has to be
Hi, Jules,
I've used the following hack, which, in fact worked. In
JBossUserPrincipal, where you set SecurityAssociation, instead of setting
the principal to 'this', set it to 'new
SimplePrincipal(this.getName())'. JBoss security checking will not care if
it is a new object every time.
It happens when the ClassLoader that created the java:comp/env context
for the war is not the war ClassLoader, or a parent of the war ClassLoader.
The current WebIntegrationUnitTestCase.testENCServlet case is working
so this looks to be setup correctly at least for the testcase ear.
Another
