On Jan 9, 2008, at 11:32 AM, Andreas Fischer wrote:
> Thank you for the fast reply!
> The reason why I put it into ext-webapp was because the persistence
> unit code and the authenticator using it are in the same .jar file.
> When I just put the .jar file in the lib folder for this virtual host
> (I don't want to put it into the main lib or ext folder as it should
> not interact with other hosts) I got a class loader error when it
> tried to access the enhanced classes. It was something about a "live
> instance" etc. Once I moved it to ext-webapps the error went away and
> I could use the persistence unit in servlets on different webapps.
Right. I wasn't thinking properly. It does need to be outside the
system classloader for the class enhancing to work.
You could put it in the <host> or <cluster> context if you wanted,
> One question right now is... Even if the authenticator is not webbeans
> aware, why does a simple lookup over JNDI does not get me the
> PersistenceUnit or PersistenceContext ?
It should be fixed in the snapshot.
It's a timing issue during initialization. The Authenticator was
getting initialized before the JPA contexts were available.
> Andreas Fischer
> On Jan 9, 2008, at 10:53 AM, Scott Ferguson wrote:
>> On Jan 8, 2008, at 8:26 PM, Andreas Fischer wrote:
>>> I try to write an Authenticator that uses a persistence unit that
>>> stores users identities.
>>> The unit is stored in ext-webapps so multiple applications can use
>> I've just added a bug report for this. The <authenticator> isn't
>> webbeans-aware at the moment.
>> By the way, the unit could be in resin/lib (or resin/ext), not ext-
>> The only purpose of ext-webapps is to support those libraries that
>> aren't classloader-aware, i.e. that can only work in a single web-app
>> at one time.
>> -- Scott
>>> If I try to use annotations only null is passed as the persistence
>>> manager. If I try to look either the persistence context up in the
>>> authenticator over JNDI I get a name not found. Even if I try to
>>> the actual lookup until loginImpl is called the Unit / Context can
>>> still not be found.
>>> Looking up the same context in an example servlet works over
>>> It shouldn't be such an uncommon case for an authenticator to access
>>> infomration from a persistence context? I mean it is easy to work
>>> arround the problem by using SQL queries but using the persistence
>>> unit approach would make things easier.
>>> resin-interest mailing list
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list