Serge Knystautas wrote:
>>> How does depending on Avalon Framework limit reusability? You'll have a
>>> really tough time convincing me here...
>>
>
> I'll try my best. It's mainly a question of what it takes to be able to
> start using components, namely having a container to run the Avalon
> framework.
>
> Yes, the interfaces look nice and it's a relatively small dependency.
> But consider my current project. I have Java code that runs in these
> various environments:
>
> 1. Standalone server - an XML socket server to talk to Flash and other
> components, and some other fun stuff.
> 2. Web server - much of our code is here since its a webapp and I'm
> running with a web application server (Resin or Tomcat).
> 3. JUnit tests run from ant
> 4. Latka functional end-to-end tests
> 5. Swing-based, webstart-deployed app for some complex parts of the
> admin system (ok, not yet, but that's the plan this quarter)
>
> Right now from what I know about Avalon, the only convenient way to use
> the Avalon interfaces is from within Phoenix, so environment 1 works,
> but environment 2-5 I'm stunted. I have to write a bunch of code
> developing containers to support these other environments. Well, I
> could either do that to use Excalibur and some other existing
> components, or I could just use DBCP and hunt around for other pooling
> and other libraries. I have this one part of my webapp where I need to
> create a pool of threads to pull data from another server and has
> frustrating timeout issues, and I would love to use the Avalon thread
> manager to do this. Unfortunately, it's just not worth the effort.
Excalibur has a couple of convenient containers you can use. So,
#2,3,5 are all relatively easy to do. #4, I am not familiar with
Latka so I can't say anything intelligent there.
Excalibur has the ExcaliburTestCase that will load up a complete
container and environment to test your components. It uses The
ExcaliburComponentManager (a container that creates all the
components from an XML descriptor file). Cocoon is an example of
a webapp using Avalon components.
I'm sorry you don't feel it is worth the effort. Hopefully, we will
get our docs in order sometime this century and it won't seem like
such a tall order.
>
> Maybe if someone contributes a servlet context listener to be an Avalon
> container in webapps, an ant-based container, also very important -
> something to support unit testing (I'd note that I haven't seen any unit
> testing in Avalon and it's very frustrating within the James project to
> do testing because we're using Avalon), and possibly a generic
> command-line style container, the Avalon component architecture might
> see more widespread use.
:>
We have all of that. We just need better ways of pointing it out to
you.
>
> Anyway, hopefully that somewhat explains the obstacles in the of using
> me Avalon and why I turn to Commons stuff regularly.
Most of the issues can be addressed with documentation.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
