By mentioning JNDI I guess you are talking about ServiceLocator pattern, right?
It is considered as anti-pattern.
So using Context inside your component is definitely a BAD idea.
Google for discussion of this antipattern, since I see that I am not very good at conviencing :)
Noel J. Bergman wrote:
Alexander Zhukov wrote:
Noel J. Bergman ÐÐÑÐÑ:
Really? I didn't even know that I knew how to ÐÐÑÐÑ. How cool!
With respect to Groovy, I see that fitting into a startup role, and we should be open to seeing multiple technologies able to fill that role.
Let me stress again that JamesNGs configuration can be written in whatever language you want (certainly java included)
Primary configuration could be defined via JNDI, and we finally have a good set of code to address that area. We also have http://jakarta.apache.org/commons/configuration/ available.
please no JNDI configuration this throws all POJO efforts away
That is absolutely not true. POJO and JNDI are orthogonal. Furthermore, JNDI is the standard for all J2EE activities. And Commons Configuration allows us to use XML, JNDI and other media for configuration information.
JNDI also means that we can administer things dynamically and across a cluster, which would be a major bonus.
- again ALL (not the some but ALL) objects requiring configuration have to now about external entity.
We can use JNDI directly, e.g., context.lookup("services/DNSService"), where the InitialContext is context-sensitive based upon configuration information for the component given that JNDI context, and/or we can pass Commons Configuration objects into components.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
