Now, *this* solution I really like. Can you point me to any sample code or other documents for this?
Thanks, Mike --- Johan Eltes <[EMAIL PROTECTED]> wrote: > 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". > > > __________________________________________________ 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".
