You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gonzalo Diethelm <go...@aditiva.com> on 2002/05/10 05:13:56 UTC
Basic questions
Hello,
I have been doing some reading on Framework and components,
trying to understand the basic concepts behind their design.
I have some honest questions, not intended to express any
opinion on anything at all, just looking for answers. In fact, I
think I know the answers to some of the questions, but I'm asking
them anyway to check my understanding.
Say I write a class with some kind of business logic:
class Foo { public String getAnswer(String data) { ... } }
The class would in principle benefit with some of the life cycle
abstractions in Framework. For example, the class could need
some kind of configuration and logging, so it could be declared
as:
class Foo implements LogEnabled, Configurable { ... }
Now, I start by testing this class from a simple command line
program. At this point:
1. Do I gain anything by having Foo implement LogEnabled and
Configurable?
2. Who will call the proper configure() method in the class?
Does the class have to be put into a component manager? This
seems to me to be the case, and if this is so, then it is kind of
useless to have a component "living by itself", not as part of a
component manager. Is this correct?
3. If the "component by itself" does indeed not make sense: the
docos talk about running components as stand-alone programs (such
as my test case). In this case, the test program is responsible
for taking the component through the life cycle, right? In this
case, and supposing the component will ONLY be run from a test
program, is there any value at all in making this class a
component and having it implement Configurable? I mean, someone
will have to call the configure() method anyway; why not have the
component call it itself when appropriate?
The second scenario is running this business logic from a
servlet-based application. Under this scenario, the user
interface is handled with Struts; the user enters some data,
clicks on a button, and a Struts Action class is reached. At
this point, the Action class grabs the entered data and is ready
to call the business logic component.
4. Is there any benefit in using a ComponentManager here? After
all, the Action class could simply create an instance of Foo,
pass the parameters and grab the result, right?
5. My understanding is that the ComponentManager at least would
be helpful in providing some kind of pooling of components. If
this is the case, would the ComponentManager be a Singleton? If
yes, who instantiates it? Who ensures it really IS a singleton?
The Struts scenario is more than just an hypothetic example; it
is EXACTLY the way we plan to build our applications. So, my
last questions are:
6. Anybody is using Struts + Framework? Can anybody share
comments, hints, caveats, etc.? For example, can you use LogKit
on the Struts Action classes and on the Components, and have all
output treated uniformly? Or does Struts REQUIRE using log4j?
7. Anybody can provide a real working example of the Struts +
Framework combination?
Sorry if the questions seem basic or confused, and thanks in
advance for any help.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 09:41, Pete Carapetyan wrote:
> Peter, I would be interested in knowing more about your use of Struts
> with Avalon. Did you use Struts as an Avalon component, or did you use
> it outside the container? If you used it as a component, did you have to
> refactor it? Struts is my first order of business as far as
> implementing Avalon,
Actually there was very little intergation between Avalon and struts. I reused
the struts configuration file to set up the actions and mapping etc. I also
used the default struts logging that just printed out to console (or was it
to the servlet log file?).
I could have redirected all my logging to one place and wrote a custom servlet
like ActionServlet but it was easier (and faster to develop) if I didn't. For
a larger product I would have tried to centralize logging and configuration
but in my case I didn't.
Anyways my basic actions looks something like the following. (Note I still
haven't looked at my old code so the exact signatures may be off but you
should get the idea).
public class MyAction extends BaseAction
{
public ActionForward execute( ... )
{
final ComponentManager cm =
(ComponentManager)servlet.getServletContext().
getAttribute(ComponentManager.class.getName());
SomeComponent sc = (SomeComponent)cm.lookup( SomeComponent.ROLE );
if( sc.doSomething() )
{
return ActionForward(...);
}
else
{
return ActionError(...)
}
}
}
Then I had another servlet that on startup would put the ComponentManager in
the servlet context.
>
> Peter Donald wrote:
> >On Sat, 11 May 2002 07:37, Leo Simons wrote:
> >>>7. Anybody can provide a real working example of the Struts +
> >>>Framework combination?
> >>
> >>Struts is a pragmatically developed framework where the developers chose
> >>to work with a fundamentally crappy idea (JSP) because it is in
> >>widespread use (this is a big assumption :).
>
> Is it jsps that are crappy per se, or just the fact that they can be,
> and are often, abused?
Both. JSP compilers have never made it easy to locate source of errors and
generally the compile cycle is way longer than it needs to be. Combine that
with the fact that taglibs require way too much configuration IMHO and are
painful to write leads to lots of scriptlets and uglies. Add to the fact that
you basically require programmers to write the pages and it adds up to
ickiness.
Recently with JSTL and enough prepackaged taglibs, the negatives can be
reduced significantly but you still basically require programmers to manage
it.
Personally I still prefer templating engines but when more stuff gets
standardized in JSPs and they becomes less painful to use maybe this will
change ;)
> >I pretty much put all biz logic in Avalon components, placed these
> > components in ServletSession via startup servlets and then had each
> > Action retrieve the required components/services from ServletSession and
> > work from there. Each action basically called some avalon components then
> > stuffed the results back in a Velocity context and that was it.
>
> Ouch. All in the session? Hmm. I prefer keeping the key in the session,
> and everything else possible in the persistence layer. Scalability could
> be a bit of a problem, otherwise.
Theres only 3-4 objects I put in the ServletSession. These servlets are either
another directory service (like ComponentManager) or act as facades onto
complex buisness logic.
While this approach is a little less type safe and relies on order of loadup
of servlets and when stuff gets put in the session it seems to be the "J2EE"
way :)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Peter Donald <pe...@apache.org>.
On Sun, 12 May 2002 12:53, Pete Carapetyan wrote:
> Peter Donald wrote:
> >>>Anybody can provide a real working example of the Struts +
> >>>Framework combination?
> >
> > I used struts <snip including _with Avalon_>
>
> Peter, I would be interested in your use of Struts with Avalon,
> particularly the process of using Struts as a component. There are many
> of us who use Struts who are not up to the Avalon speed yet, but would
> like to be. In particular, I am wondering if I would have to refactor
> Struts, which would be bad because Struts itself is an Apache product,
> and I would like to keep it in sync with all the latest builds as they
> mature. But at the same time it would seem a shame to keep it outside
> the Avalon structure.
>
> Do you have any comments in this regard that could help me along the
> way? Especially comments as to how you would bring it in as a component
> or set of components?
Well I guess it depends on how far you want to go. It should be possible to
have a set of ActionMappings configured using Avalon practices, and maybe
have an AvalonAction that was composed via standard Avalon lifecycle. You
could also easily configure logging to redirect to a central location.
Unfortunately I can't help you as I have not yet done that ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Peter Donald wrote:
>>>Anybody can provide a real working example of the Struts +
>>>Framework combination?
>>>
> I used struts <snip including _with Avalon_>
>
Peter, I would be interested in your use of Struts with Avalon,
particularly the process of using Struts as a component. There are many
of us who use Struts who are not up to the Avalon speed yet, but would
like to be. In particular, I am wondering if I would have to refactor
Struts, which would be bad because Struts itself is an Apache product,
and I would like to keep it in sync with all the latest builds as they
mature. But at the same time it would seem a shame to keep it outside
the Avalon structure.
Do you have any comments in this regard that could help me along the
way? Especially comments as to how you would bring it in as a component
or set of components?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Peter, I would be interested in knowing more about your use of Struts
with Avalon. Did you use Struts as an Avalon component, or did you use
it outside the container? If you used it as a component, did you have to
refactor it? Struts is my first order of business as far as
implementing Avalon,
Peter Donald wrote:
>On Sat, 11 May 2002 07:37, Leo Simons wrote:
>
>>>7. Anybody can provide a real working example of the Struts +
>>>Framework combination?
>>>
>>Struts is a pragmatically developed framework where the developers chose
>>to work with a fundamentally crappy idea (JSP) because it is in
>>widespread use (this is a big assumption :).
>>
Is it jsps that are crappy per se, or just the fact that they can be,
and are often, abused? I keep my jsps scriplet free, use taglibs, and
have no real problem with them any more, either philosophically or from
a practical standpoint. But I would agree that other approaches are fine
too, especially when they become set up to work within Avalon, which no
doubt they will be as soon as Avalon is discovered !
>I pretty much put all biz logic in Avalon components, placed these components
>in ServletSession via startup servlets and then had each Action retrieve the
>required components/services from ServletSession and work from there. Each
>action basically called some avalon components then stuffed the results back
>in a Velocity context and that was it.
>
Ouch. All in the session? Hmm. I prefer keeping the key in the session,
and everything else possible in the persistence layer. Scalability could
be a bit of a problem, otherwise.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 07:37, Leo Simons wrote:
> > 7. Anybody can provide a real working example of the Struts +
> > Framework combination?
>
> Struts is a pragmatically developed framework where the developers chose
> to work with a fundamentally crappy idea (JSP) because it is in
> widespread use (this is a big assumption :).
You can use Struts with other presentation layers. I used struts + Velocity +
Avalon for some stuff. It was a little more work than struts + Velocity at
the time but I believe that the Velocity people have added a base servlet to
help struts <---> velocity integration now.
I pretty much put all biz logic in Avalon components, placed these components
in ServletSession via startup servlets and then had each Action retrieve the
required components/services from ServletSession and work from there. Each
action basically called some avalon components then stuffed the results back
in a Velocity context and that was it.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Leo Simons <le...@apache.org>.
> Hello,
Hi!
Berin's answered your questions pretty well, I think, but I'll put it a
little more bluntly ;)
> Say I write a class with some kind of business logic:
>
> class Foo { public String getAnswer(String data) { ... } }
>
> The class would in principle benefit with some of the life cycle
> abstractions in Framework. For example, the class could need
> some kind of configuration and logging, so it could be declared
> as:
>
> class Foo implements LogEnabled, Configurable { ... }
>
> Now, I start by testing this class from a simple command line
> program. At this point:
>
> 1. Do I gain anything by having Foo implement LogEnabled and
> Configurable?
yes. You get a nice design with less thought, plus you get to reuse
other stuff that follows the same design. Finally, when you decide you
want to reuse Foo after all, you can bring it into any avalonised app.
> 2. Who will call the proper configure() method in the class?
When testing, that should be the testcase. When you have a Foo.main()
method, the quick hack is to do have main() act as a container. This is
mild violation of IoC as main() should really be considered separate
from your class.
> Does the class have to be put into a component manager? This
> seems to me to be the case, and if this is so, then it is kind of
> useless to have a component "living by itself", not as part of a
> component manager. Is this correct?
No. You need to put it in a container, not a component manager. I don't
use the ECM very much, but I use avalon a lot =)
> 3. If the "component by itself" does indeed not make sense: the
> docos talk about running components as stand-alone programs (such
> as my test case). In this case, the test program is responsible
> for taking the component through the life cycle, right? In this
> case, and supposing the component will ONLY be run from a test
> program, is there any value at all in making this class a
> component and having it implement Configurable? I mean, someone
> will have to call the configure() method anyway; why not have the
> component call it itself when appropriate?
This is never "appropriate" when talking about components. In the army,
a soldier never tells himself what he should do. He has someone to do
that for him.
If you don't want someone who can function in the army, but you do want
Arnold Swarzenegger (whatever his name is), there is no benefit in COP.
Just an analogy. Arnold may seem like the ideal solution to your
problem; the truth is we've got all these soldiers lined up to help you,
except they don't work to well with Arnie.
Not everything should be a component. Especially not in java.
> The second scenario is running this business logic from a
> servlet-based application. Under this scenario, the user
> interface is handled with Struts; the user enters some data,
> clicks on a button, and a Struts Action class is reached. At
> this point, the Action class grabs the entered data and is ready
> to call the business logic component.
>
> 4. Is there any benefit in using a ComponentManager here? After
> all, the Action class could simply create an instance of Foo,
> pass the parameters and grab the result, right?
You could do this. However, this is not a very smart design. You want
the Action class (whatever it is; I know zip 'bout struts) to talk to
something that provides it with results. You don't want it to "create an
instance".
mycomp =
myJNDIthing.lookup("my.component.that.can.handle.this.action.role");
mycomp.stop();
mycomp.reconfigure("myActionSpecifcData");
mycomp.start();
myresult = mycomp.getResult();
mycomp = null
as opposed to
mycomp = new mycomp();
mycomp.initialize();
mycomp.enableLogging("blabla"); // what do we call this again
mycomp.configure("myActionSpecifcData");
mycomp.start();
mycomp.stop();
mycomp.dispose();
mycomp = null;
You will see I mention JDNI instead of a ComponentManager. ECM has
features all different from JNDI. The good part about JNDI is that it is
a standard understood by many existing apps.
> 5. My understanding is that the ComponentManager at least would
> be helpful in providing some kind of pooling of components. If
> this is the case, would the ComponentManager be a Singleton? If
> yes, who instantiates it? Who ensures it really IS a singleton?
You're talking about ExcaliburComponentManager now, I guess. Within a
servlet w/ JSP environment, your best bet is to keep it out of the
servlet environment, and put it in a registry (ie JNDI).
The alternative is a "master" servlet that takes all your requests,
creating the CM there once, where this servlet ensures the singleton
setup. Off course, this means you cannot use JSP to talk to the CM
(which is a good thing).
I think that the thing that should ensure "singletoniness" within struts
would be the Controller servlet.
> 6. Anybody is using Struts + Framework? Can anybody share
> comments, hints, caveats, etc.?
I don't think so. I don't know much about Struts. One thing I do know
about it is that it breaks IoC. I don't know how much that happens, but
it would make integration somewhat more difficult than with projects
like Turbine or Velocity (where it is quite easy).
> For example, can you use LogKit
> on the Struts Action classes and on the Components, and have all
> output treated uniformly?
> Or does Struts REQUIRE using log4j?
no idea. Think you should ask the struts people =)
> 7. Anybody can provide a real working example of the Struts +
> Framework combination?
Struts is a pragmatically developed framework where the developers chose
to work with a fundamentally crappy idea (JSP) because it is in
widespread use (this is a big assumption :). Avalon is more of the "only
use the well-designed, pure stuff" mentality.
Integrating the two in a tightly coupled way would probably result in
bruises on both sides. Loose coupling via JNDI, JMX, RMI, AltRMI, EJB,
EOB, Sockets, Corba etc should work rather well, I'm guessing.
My gut feeling is that what would work best to enhance struts is a
singleton model, whereas avalon does not like the singleton model very
much (though it does work), because static methods in components are
considered evil.
> Sorry if the questions seem basic or confused, and thanks in
> advance for any help.
cheers! Hope it really does help =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Basic questions
Posted by Paul Hammant <Pa...@yahoo.com>.
Gonzalo,
>Say I write a class with some kind of business logic:
>
> class Foo { public String getAnswer(String data) { ... } }
>
>The class would in principle benefit with some of the life cycle
>abstractions in Framework. For example, the class could need
>some kind of configuration and logging, so it could be declared
>as:
>
> class Foo implements LogEnabled, Configurable { ... }
>
>Now, I start by testing this class from a simple command line
>program. At this point:
>
>1. Do I gain anything by having Foo implement LogEnabled and
>Configurable?
>
>
Not from the point of view of testing. .....
>2. Who will call the proper configure() method in the class?
>Does the class have to be put into a component manager? This
>seems to me to be the case, and if this is so, then it is kind of
>useless to have a component "living by itself", not as part of a
>component manager. Is this correct?
>
>
But it is not so hard for a Unit Test to Fake a container. Even if you
'test' is a home grown mainable class, the lifecycle methods
can still be activated. Granted configure(..) is harder than
enableLogging(..) but there once made, the reusability is high.
There is an 'ObjectMother' pattern that makes test setup easier.
>3. If the "component by itself" does indeed not make sense: the
>docos talk about running components as stand-alone programs (such
>as my test case). In this case, the test program is responsible
>for taking the component through the life cycle, right? In this
>case, and supposing the component will ONLY be run from a test
>program, is there any value at all in making this class a
>component and having it implement Configurable? I mean, someone
>will have to call the configure() method anyway; why not have the
>component call it itself when appropriate?
>
IoC pattern on avvalon-framework website.
I'll not answer you other questions, as the Cocoon guys can do so with
more authority. Good newbie stuff though.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Basic questions
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gonzalo Diethelm [mailto:gonzalo.diethelm@aditiva.com]
<snip/>
>
> class Foo implements LogEnabled, Configurable { ... }
>
> Now, I start by testing this class from a simple command line
> program. At this point:
>
> 1. Do I gain anything by having Foo implement LogEnabled and
> Configurable?
You do if you call the methods in the right order. That is why we
posted the order of the lifecycle methods.
>
> 2. Who will call the proper configure() method in the class?
> Does the class have to be put into a component manager? This
> seems to me to be the case, and if this is so, then it is kind of
> useless to have a component "living by itself", not as part of a
> component manager. Is this correct?
It needs a Container. A container is the code that manages the
instances of the component. The componentmanager is just the interface
used to get at the component you want. The ExcaliburComponentManager
combines the concepts of the CM and container into one class. There
are other containers available.
>
> 3. If the "component by itself" does indeed not make sense: the
> docos talk about running components as stand-alone programs (such
> as my test case). In this case, the test program is responsible
> for taking the component through the life cycle, right? In this
> case, and supposing the component will ONLY be run from a test
> program, is there any value at all in making this class a
> component and having it implement Configurable? I mean, someone
> will have to call the configure() method anyway; why not have the
> component call it itself when appropriate?
If you have no intention of using a component in a running system,
don't make it a component. You are right it does not make any sense.
However, you do want to make sure you don't confuse calling any old
object a component. If you want an object to read configuration
data from any source, and configure itself, then you shouldn't do it
through a component. Such a practice is called Subversion of Control,
and it is a nasty bug-in-waiting if you apply it to components.
Keep in mind that Excalibur has a testcase package that will read
configuration information that you can use in your tests. It will
also prepopulate a Logger, a Container, a Context, your Configuration
tree, and manage your components for you. All you have to do is
write the tests that exercise your component.
> The second scenario is running this business logic from a
> servlet-based application. Under this scenario, the user
> interface is handled with Struts; the user enters some data,
> clicks on a button, and a Struts Action class is reached. At
> this point, the Action class grabs the entered data and is ready
> to call the business logic component.
>
> 4. Is there any benefit in using a ComponentManager here? After
> all, the Action class could simply create an instance of Foo,
> pass the parameters and grab the result, right?
The process of creating and destroying a component can be costly.
Especially if you have to keep reading the same config data each time.
You also add unnecessary overhead to the garbage collector.
Cocoon is an example of a very powerful servlet built on Avalon
components.
It uses the ComponentManager to get the instances of the components
you need.
However, in JSP environments, you effectively have many different
servlets (each JSP is converted to a servlet). What you can do is to
bind the ComponentManager to JNDI, and have each Action or JSP get
the instance of the component from the CM in JNDI.
You still need the container because each component might have
what I call different lifestyles. One component could be ok with
being a Singleton (i.e. one instance for all clients to share),
while another requires a unique instance per thread. The container
takes care of instance management policies.
>
> 5. My understanding is that the ComponentManager at least would
> be helpful in providing some kind of pooling of components. If
> this is the case, would the ComponentManager be a Singleton? If
> yes, who instantiates it? Who ensures it really IS a singleton?
You do. Static accessors are the enemy of Inversion of Control.
You do want to ensure your components can't talk directly to their
container.
That said, you had a two pronged question. Is the ComponentManager
a singleton? The answer is it depends on the container. The
ComponentManager interface is an access mechanism. The Excalibur
ComponentManager is a combination of a container and a componentmanager.
It kind of grew without being properly designed. However many people
find it easy to get up and running with.
The real question is how do I ensure the container is a singleton?
In a servlet/webapp environment, you can use the approach I mentioned
above.
You have a master servlet whose responsibility is to set up the root
container, and bind it to the JNDI context. That servlet would be
auto-loaded with the highest precedence to ensure that the container
is set up.
The servlet would check to see if the container is already bound. If
not, it creates and binds the container. If it has been bound already,
the servlet does nothing.
>
>
> The Struts scenario is more than just an hypothetic example; it
> is EXACTLY the way we plan to build our applications. So, my
> last questions are:
>
> 6. Anybody is using Struts + Framework? Can anybody share
> comments, hints, caveats, etc.? For example, can you use LogKit
> on the Struts Action classes and on the Components, and have all
> output treated uniformly? Or does Struts REQUIRE using log4j?
I must admit ignorance on this point. I have looked at Struts in the
past, but never really had time to mess with it. If Struts uses
Commons Logging, then you can use LogKit in both scenarios.
>
> 7. Anybody can provide a real working example of the Struts +
> Framework combination?
No, but I can point you at Cocoon. It's a beast, but it does answer
some questions about using Framework in a servlet environment.
>
> Sorry if the questions seem basic or confused, and thanks in
> advance for any help.
>
No problem man.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>