On 10/28/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
You know ... one of the nice things about social bonding at ApacheCon is that I really don't want to hit you anymore. :-p
And I met you on expenses, Great Value than ApacheCon. ;-)
Actually, I don't recall where we each came down on the various sides of this, so I am just teasing.
I know you are. :-)
A property could be any Java object, including a service or locator service as desired.
I can totally see how this would *work* but the problem is that it isn't really portable, no two containers would have to offer the same basic services, nor would they have to make them available in the same way. The API needs to restrict peoples choices in order to ensure that every different mailet container is a similar environment. There *is* tension between service ocation and injection, J2EE has problems where no standard exists for looking up the global transaction manager in JNDI, but the the API provides direct access to security services. I really think we need both approaches, strict and flexible.
I am not concerned about the specific syntax, just suggesting the concept of declaring properties that will be inspected and injected by the container, either by value or by reference (e.g., name, URL, etc.).
<snip>
So I believe that the above could satisfy the needs behind your comments that: > A framework for deploying and accessing optional services is required.
Agree, optional ones. What you haven't done is to explain why you don't think repositories should be mandatory or in some way a special case...
> We need to have a service discovery function defined by the API so > that new services can be registered and found without having to > release new versions of the API. but with respect to: > I propose that these services (eg datasources, spam scanners, dns etc) > be looked up in JNDI and that the API include a naming convention for > their registration. As much as I personally like JNDI, and agree that a service locator is useful, the pattern adopted for the latest revision of several J2EE Specifications differs.
OK I put JNDI in there because I thought we'd reached some historical agreement, that consensus appears not to exist, I hereby withdraw that detail in favour of whatever else we eventually agree on !
