> :) Basically, the same reason web applications and struts applications
> need a container. :)
hmm... disagreed. Web applications need a container so they don't need
to handle the http protocol theirself, handle jsps, taglibs and all the
other stuff.
struts itself is a framework, not a container.
> Being able to instantiate objects using a XML driven factory is very,
> very convenient, and make programing strategies possible that would be
> otherwise impractical.
You are describing an abstract factory, which is a well known pattern
and can be implemented with 3 classes.
>
> Consider how difficult a Struts application would be to code if you
> had to create all the objects in the struts-config through calls to
> new. Possible, but, very messy and very verbose.
See above. Actually I had my own 'struts' for year ago, and moved to
struts because of the taglibs.
>
> Also, in practice, you often end up making some (or all) of your
> business objects singletons. Containers like Spring give you a quick
> and consistent way to create singletons, when you need them, and
> instant classes when you don't.
I have an eclipse template for that :-)
private static ${enclosing_type} instance;
private ${enclosing_type}(){
}
public static synchronized ${enclosing_type} getInstance(){
if (instance==null){
instance = new ${enclosing_type}();
}
return instance;
}
I'm using a web container because:
I don't want to handle http.
I don't want to compile jsps.
I don't want to provide taglib handling.
The lifecycle of my code is defined by the web-page and very well
implemented in the web container.
I do not use an application container because:
I have none of the above problems there.
I don't want anything to eat away resources.
The lifecycle of the component is defined by application design.
In other words:
Why should I use a container instead of a framework.
The difference between container and framework as I see it is the flow
of control:
Container defines the lifecycle of a component and the communication
between components.
Framework provides tools to define the lifecycle of a component and
abstraction layers for the communication.
In other words: A container defines how you have to write your code
(e.g. ejb), a framework gives you possibilities to use already written
code.
Am I missing something?
Leon
>
> -Ted.
>
> On Fri, 11 Mar 2005 15:38:01 +0100, Leon Rosenberg
> <[EMAIL PROTECTED]> wrote:
> >
> > Why do you need a container? Or why do I need a container?
> >
> > Leon
> >
> > On Fri, 2005-03-11 at 07:27 -0600, NetSQL wrote:
> > > I used Hivemind and switch to CoR, which I consider a light weight
> > > container.
> > > Good article on CoR at onJava.com.
> > >
> > > .V
> > >
> > > Manfred Wolff wrote:
> > > >
> > > > Ted.
> > > >
> > > > +1 to this approach. I prefer leightweight container such as hivemind to
> > > > manage the entrypoints to the business logic. Hivemind is easy to learn
> > > > and you have the benefit, that the lifecycle of the business components
> > > > may be steered too (such as pooled components, singletons etc.). Other
> > > > containers like spring or picocontainer are also well.
> > > >
> > > > -Manfred
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
