On Sun, 21 Oct 2001 19:14, Erik Hatcher wrote:
> ----- Original Message -----
> From: "Peter Donald" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, October 20, 2001 8:47 PM
> Subject: Re: [Ant2] scoping of properties
>
> > Thats an interesting question. Should the container or the task implement
> > policy? Container implementing it is useful because that means it has
> > complete control over it and tasks always behave consistently. The
> > disadvantage being that you may sometimes want inconsistencies.
>
> Definitely an interesting topic. These are the same concepts that
> generated the J2EE container specifications. The container provides
> several implicit services which implement policy that previously required
> hand-coding and careful attention to detail (@see: distributed transaction
> processing, role based security, JNDI, JMS, and so on, and now being
> overlayed by things like SOAP).
Another interesting thing to note is the evolution of these systems. Consider
the servlet spec.
Originally designed for in process replacement of cgi. Overtime has added
features such as
* filters (similar to ants proposed aspects)
* a deployment format - .wars (like ants typelib)
* event notification for app wide changes (similar to ants listener interface)
* no longer can one servlet directly access another (allows much more safer
servlet development and distribution) - similar to why we chose for ant tasks
to operate via proxys/TaskModel
...
Lets just say that a lot of the design decisions have been influenced by the
same places the servlet/ejb/other designers were influenced by - I made sure
of that ;)
> How does a J2EE container address inconsistencies in people desiring to go
> "outside the box" and do things their own way? It doesn't stop them, it
> just makes it more difficult by things going against the grain not being
> considered "best practices".
well it really depends on what you are talking about. For instance consider
some of the limitations of EJBs (such as no thread access, no file access, no
socket access, no synchronization allowed etc). Some containers will allow
you to do this while others will completely break and fall down. I even heard
that some containers will scan the bytecode and detect these sort of things
in a validation phase and reject it then. (I don't know about that as I am
not much of an EJB guy).
So in that way EJB has an inviolatable policy for somethings. Im not sure if
we should have the same though.
> I'm not sure if I provided any useful view to this thread, but hopefully
> there is some synergy between Ant's target/task "container" and other
> "container" concepts in the Java world.
I hope so ;) If you are interested in the supporting theory there is a
relatively easy-to-read set of info on the Avalon web pages about "Inversion
of Control" and "Separation of Concerns". Avalon hasn't put up any literature
on "located" or "contextualization" APIs/Frameworks (which is the other part
of the container theory). However I think I have some references if you want
;)
--
Cheers,
Pete
-----------------------------------------------------------
If your life passes before your eyes when you die,
does that include the part where your life passes before
your eyes?
-----------------------------------------------------------
