> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
