If you are happy with the functionality/service provided by env entries, then I would use property files or xml files. The files could be loaded using the thread context class loader and packaged into the jar containing your business logic classes (also if that is actually the ejb-jar). Some none-j2ee-environments (like tomcat) do not set up a thread context class loader in a way that you can load resources the "j2ee"-way. A possible work-around is to implement a classloader helper-class that tries to load the resource from the thread context classloader (which would work for j2ee application servers and main classes started as a standard runnable jar by Suns VM). If the resource is not found, the class loader helper could try the application classloader (which would work for Tomcat).
/johan Den 02-06-03 17.44, skrev "Mike Dunbar" <[EMAIL PROTECTED]>: > Hello, > I am wondering if some of you have already fought this battle and could > help me out before I do my own brainstorming. Basically, we don't want > to "hard-code" our business logic components into the EJB model. We > would like to develop the core components in plain ol' Java and > "wrap"/deploy them as EJBs when it makes sense. Basically, the EJB > would just delegate to the "wrapped" Java component. Sounds simply > enough, right? > > The part I need help with is: how to give the components access to > configurable properties in a way that works both when they are deployed > as an EJB, and when they are not deployed as an EJB? The most straight > forward way would seem to be putting such properties a Java properties > file, but I believe EJBs are not allowed to do file I/O - right? I > think EJBs usually get such information from JNDI entries specified > in the EJB's deployment descriptor as <env-entry>'s. Is there a uniform > mechanism that will work both when the components are deploy as EJBs > and when they are not? For example, maybe the components could always > access the properties via JNDI. Sometimes an application server would > have put them there (when deployed as an EJB), sometimes they would've > got there via another mechanism (when they are not deployed as an EJB). > But, I've heard that JNDI lookup's give pretty bad performance. This > would also require a naming server to present whenever they are > Deployed, which I think is more demanding than something like a simple > properties file. > > Has anyone else tried to do this? Could you point me in the right > dirction? This seems like a common approach people would want to use - > not tying your code to a given component model so it could be used > outside of that model also. > > Much Thanks for Your Help! > Mike > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
