Why is there a dep? That's just xml
Le 23 août 2012 07:55, Enrico Olivelli eolive...@gmail.com a écrit :
Thank you
Your impl is great!
But with this LazyRealm the app needs to depend compile-time from
tomcat-catalina realm interface (even if it can be created with CDI, so I
think that in
Managed bean != cdi right?
Le 23 août 2012 02:35, David Blevins david.blev...@gmail.com a écrit :
If there is anyone looking for something to do, there is a ton of
validation work to be done.
Nearly all the validation code we have now is run on EJBs only, but much
of it applies universally.
Because realmClass needs to be a implementation of
org.apache.catalina.Realm
and so in my app I will always need to add a compile time dep on tomcat
in my app
I would like not to have any compile time dep neither on Tomcat nor on
OpenEJB/TomEE if possibile
Il 23/08/2012 08:48, Romain
hmm that's another need.
Here how i see things:
1) the LazyRealm manage the classloader stuff
2) another realm (DelegatorRealm?) does the same using bean matching
(almost) signatures of realm using java types (java == not tomcat) and uses
reflection to invoke the delegate
wdyt?
*Romain
I love it
remember that Tomcat wants a GenericPrincipal not a simple Principal
so application code have to be proxyed according to this need
My goal is that the app only needs to provide an EJB or CDI Bean with a
authenticate method which takes username/password and answers with the
list of
Yes, the problem in Tomcat JAAS Realm is that you have to bundle your
LoginModule with the container
It would be very nice to let the app provide a LoginModule
do not drop LazyRealm, it fills a gap in Tomcat Realm standard
implementations (what about giving it, without CDI, to Tomcat
you added org.quartz.scheduler.jmx.export=true
then Quartz published a MBean for each Scheduler (instanceName)
I this is enough to cleanup orphan triggers
thanks
Il 22/08/2012 19:19, Romain Manni-Bucau ha scritto:
getting the HEAD you should get some info through JMX
*Romain Manni-Bucau*
i don't get it, you can define your LoginModule in the webapp i think, you
even have the useContextClassLoader parameter
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/23 Enrico Olivelli eolive...@gmail.com
Yes, the problem in Tomcat JAAS Realm
i think so too
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/23 Enrico Olivelli eolive...@gmail.com
you added org.quartz.scheduler.jmx.**export=true
then Quartz published a MBean for each Scheduler (instanceName)
I this is enough to cleanup
I'm sorry
in http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JAASRealm
there is no documentation of useContextClassloader
I will give it a try
Il 23/08/2012 11:40, Romain Manni-Bucau ha scritto:
i don't get it, you can define your LoginModule in the webapp i think, you
even have the
I made same tests
Tomcat JAASReam creates a LoginContext in this way
//JAASRealm.java at line 372 on Tomcat trunk
loginContext = new LoginContext(appName, callbackHandler);
this constructor uses the JVM system wide JAAS configuration (default
JAAS Configuration)
so if you want to use your own
right, if you have a single application in the tomcat that's not an issue
otherwise it can be
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/23 Enrico Olivelli eolive...@gmail.com
I made same tests
Tomcat JAASReam creates a LoginContext in this
reworked it after a small talk with D. Blevins.
here the current config (a bit more general):
https://gist.github.com/8ca9f734f781946f2b8a
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Romain Manni-Bucau rmannibu...@gmail.com
Hi,
we
On Aug 23, 2012, at 2:37 PM, Romain Manni-Bucau wrote:
probably the ejbname usage is the issue, if the deployment is global the id
should be ;)
So your vote would be for using the deployment id?
AppContext
BeanContext id=fooApp/greenModule/CalculatorBean
/BeanContext
On Aug 23, 2012, at 3:22 PM, David Blevins wrote:
On Aug 23, 2012, at 2:37 PM, Romain Manni-Bucau wrote:
probably the ejbname usage is the issue, if the deployment is global the id
should be ;)
So your vote would be for using the deployment id?
AppContext
BeanContext
A couple of things...
What about a typesafe Java Configuration descriptor? Would it be possible to
use both a compiled class and a .java file? I don't think either of these
have been tried on a ApplicationServer (yet!)
If OpenEJB/TomEE stays XML, I would greatly prefer to have an XSD that has
On Aug 23, 2012, at 3:37 PM, exabrial wrote:
A couple of things...
What about a typesafe Java Configuration descriptor? Would it be possible to
use both a compiled class and a .java file? I don't think either of these
have been tried on a ApplicationServer (yet!)
We actually have (close
17 matches
Mail list logo
