Hi All, I've found a simple solution (of sorts) to my problem, simply put @ejb.util generate="physical"
In the bean tags, which should make the util object use the generated.LocalHome.JNDI_NAME always instead of the generated.LocalHome.COMP_NAME This will allow you to test beans from the web tier as the util always uses the JNDI lookup. Not as efficent as the solution which uses JNDI_NAME as a backup in event of COMP_NAME (JNDI ENC) failure but it works! Oisin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Oisin Kim Sent: 29 January 2003 10:44 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Xdoclet-user] Re: Different util classes being created depending on Bean Type Thanks Simone but I don't think that addresses the problem - I do understand that if we follow good coding practice in our production code we shouldn't use Entities directly, but in some cases it makes sense to use entities directly from the web tier, like when you unit test your entity beans from a test framework like JUnitee - which is specifiically designed for this type of usage of entity beans. This leads me to think then - why am I using JUnitee and not JUnit, if all I can test from the web tier is sesssion facades. There is no need for JUnitee at all - the fact that JUnitee exists and is widely used leads me to believe that one of two things need to happen: (a)Xdoclet needs to make its util class work for using Local references from the web tier - i.e. support lookup using jndi name and java:comp references Or (b)Application Servers need to allow web tiers have access to the java:comp/env variables. I think it makes sense for (a) to happen, we can actually do it in abot 3 lines of code changes to xdoclet without breaking the current xdoclet release the easiest wway I can think of this is to do the following: Generate the util class something like as follows for entity beans: if (cachedLocalHome == null) { // Obtain initial context InitialContext initialContext = new InitialContext(); //try the java:comp first try { cachedLocalHome = (generated.CounterLocalHome) initialContext.lookup(generated.LocalHome.COMP_NAME); } catch(javax.naming.NameNotFoundException nnfe) { //here try to look up using the generated.LocalHome.JNDI_NAME - this would work for the web tier when the java:comp reference wouldn't cachedLocalHome = (generated.CounterLocalHome) initialContext.lookup(generated.LocalHome.JNDI_NAME); //allow the exception to be thrown from here - maybe saying that both generated.LocalHome.COMP_NAME and generated.LocalHome.JNDI_NAME were not //available } finally { initialContext.close(); } } This way we support both types of lookup, from entities transparently from the web tier. How do I post this as a feature request? I think this makes xdoclet more flexible and would be a welcome addition for those who use JUnitee to test their entities. Thanks for your help on this, and apologies for the long email again. Oisin PS: For those who don't know JUnitee is a testing framework build upon JUnit which allows you to test local references from a servlet - see more at http://www.junitee.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: 29 January 2003 09:20 To: [EMAIL PROTECTED] Subject: [Xdoclet-user] Re: Different util classes being created depending on Bean Type I believe is good practice not to call Entity beans directely from Web Server but always to use a Remote Session bean facade. Simone ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
