public class ClassLoaderHelper {
public static Class forName(String name)
throws ClassNotFoundException {
ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
return contextClassLoader == null ?
Class.forName(name) :
Class.forName(name, true, contextClassLoader);
}
}
----- Original Message -----
From: "Mike Dunbar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 04, 2002 6:47 AM
Subject: Re: Uniform Environment/Property Access for EJBs and Non-EJBs
> 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".
>
>
===========================================================================
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".
