Hi Berin, answer inline,
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 3:06 PM
>
> Paulo Gaspar wrote:
>
> ...
> >
> > There is so much in a word....
> >
> > For me an URL is a component. Really! But...
>
>
>
> That's the problem with the word Component. It is overused so many
> times, and noone defines it very well. Maybe I should write a book ;)
Yeah, that is why I like better the "Service" expression that Peter
just used.
> > ...
> >
> > I mean, my "Sitemap" does a lot of the same that Cocoon's
> Sitemap does and
> > I just use my standard ComponentManager and Configurator
> functionality for
> > that. They have to do a lot more manually I think.
>
>
> Yea. I was looking at your code snippet, and I finally have a couple of
> comments. First, I was really looking for how a Client component uses the
> ComponentManager you have, ...
Do you know Cocoon's Environment, that holds the request, response and
object model objects + any other stuff used to process a request?
Well, that one also references the ComponentManager but only exposes the
lookup and release methods, which are basically implemented like this:
public class WebEnvironment
{
private ComponentManager m_componentManager;
...
public Object lookup(Class i_role, String i_name)
{
return m_componentManager.lookup(this, i_role, i_name);
}
public Object release(Object i_component)
{
return m_componentManager.release(i_component);
}
}
So, the environment object is used as the "token".
The above "release()" method was never used yet since components always
have some other way of being released. For instance, when a pooled
Connection is close that returns it to the pool. The pool has a
notification mechanism that signals the custom factory that the
Connection was released and this one calls ComponentManager.release().
Notice that:
- My Database Connection Pool does not depend on the framework. Only
its factory does;
- The Connection is actually returned to the pool before being
"released" by the component manager. This just removes from the
tracking list in this case, avoiding that the CM tries to release
the Connection again after the request is processed...
After the request is processed all components not yet released are
(released) by calling:
m_componentManager.releaseAll(webEnv);
> ... and how the ComponentManager itself is set up.
Well, the syntax is not so important here, but it is very similar to
the mechanisms used by Cocoon and Avalon.
Basically, there is one (or more) XML configuration file that
configures all Roles and Types which specifies their names,
interfaces (role), class factories (type), etc.
Then there is one (or more) XML files that configure the sitemap.
Note: A "type" is a specific implementation of a "role" and a role
is an interface just as in Avalon.
What details are you interested on?
> Second, your system is based on the JavaBeans approach, and features an
> Active configuration system. By that I mean that you expose all sorts
> of configuration points via setters and getters as opposed to reading
> a passive configuration object and configuring the component based on
> that.
>
> I prefer the passive configuration system that Avalon uses due to the fact
> that I have tight control over what settings are applied and when.
Believe me, I have no less control here.
Remember that I just put values converted to the right types on the
configuration beans, but ONLY after that do I use those values to do
something.
In the primary version I sent you there was no validation BUT it is
not like that in the final version of that component (which, however,
is too confusing).
During type conversion, a bad format (e.g.: a number expressed as
"XPTO") will trigger an Exception and stop the configuration.
After the values are at the bean, I can check if they make sense and
I can check if they were filled (if not they are null).
For most components it is not necessary to do any checking:
- Thread safe components are immediately built and their constructor
usually checks if the parameters are valid;
- Same with Pools!
> Secondly,
> I prefer it due to the fact that the interface of the Component
> isn't muddied
> by what amounts to Configuration points.
Hey, you got it wrong.
I sent you the FACTORY code. The component has NO configuration
points and in this case is not even dependent on the framework.
> However, that is a matter of preference.
Actually, from what you say we have the same preferences. I just
have to do a better job of explaining my ideas.
Or, probably, we just have to keep talking. There are many parts
involved and it is hard to transmit it all that was built and
tried and transformed during several months in just a couple of
days.
Hey, I am still learning why some things in Avalon are as they
are. Very often I end up learning that something I though was
non-sense is actually very useful.
> >>token == transaction of components ? Nice idea. SO for each
> >>"symphony" you
> >>are guarenteed that you release your components and so forth
> >>right? This is
> >>more aimed at a request based architecture rather than
> persistent service
> >>based architecture ?
> >>
> >
> > Yes, you understood it well.
> >
> > Even in a persistent Architecture it would help to ensure that all
> > resources are released when you shut it down, but for such architecture
> > you would probably not need the "token".
> >
> > However, most persistent Architectures have some bit where they could
> > use this token thing:
> > - Imagine James providing access to (my flavor of) components for a
> > mailet and ensuring all resources used for a request would be
> > closed;
> > - Imagine webapp reload on a Servlet Container. With Servlet
> > containers providing things like user validation via database and
> > some J2EE services, you want to clean up that kind of stuff when
> > you reload a webapp;
> > - Same thing for mailet reload?
>
>
> Actually, the Token approach would work quite well for Cocoon who wants
> the ability to lookup a component to use for the life of a request,
> and release them all when the request is over.
=:o)
Together with the "active configuration" and the Converter, its my
favorite new feature.
But the "active configuration" and Converter ideas I got from Peter and
his work at Ant-Myrmidon.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
