james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: OSGi: First steps with Knopflerfish
Date Tue, 03 Oct 2006 15:59:47 GMT
On 10/2/06, Stefano Bagnara <apache@bago.org> wrote:
> Bernd Fondermann wrote:
> >> You anyway need this: you can try framework that try to mix them up, or
> >> try to autodiscover one or both of them, or uses interfaces or
> >> annotations for them, but you'll need both anyway.
> >> E.g: The xinfo could be generated by XDoclet and javadocs in the avalon
> >> components.
> >
> > Why, if I have to do a lookup via ServiceManager with the full
> > qualifed classname anyway?
>
> I've lost you: where do we need the fully qualified classname of our
> implementations? In dependent code you lookup the service via the
> service interface name...

OK, interface name rather than classname, but we do a lookup although
the component already _declared_ the dependency to the component it is
looking up _plus_ the assembly.xml contains a declaration that it has
to be so. Either one could aready be sufficient to resolve the
dependency.

> >> > This is bad (IMHO) even if you do _not_ want to change container.
> >> > For example, look at the unit tests and the setup() methods. much too
> >> > much has to be done there to execute a simple test. this is mock-up
> >> > hell ;-)
> >>
> >> This complexity is not given by Avalon, but by the fact that we have
> >> components with a lot of dependencies. I did a lot to reduce the
> >> inter-component visibilities from 2.2.0 to 2.3.0 because of this, but
> >> when you use many services you have to mock things.
> >
> > The service() lifecycle method does all kinds of service lookups. If a
> > lookup cannot be resolved, the ServiceManager is throwing an
> > exception. So even if I don't want to test all dependent components
> > for the tested component, I have to provide them (or mocks) because I
> > want some code to be run/tested, which is enclosed between code using
> > all the other components. boo.
>
> Yes, we already agreed that we have to refactor the service methods to
> lookup services and call setters so that we can test components without
> to call the service method: not sure this is easy for all of our
> components, but we should do this everywhere we can.

The setters are in place (modulo a handful remains).
service(), configure(), intitialize() are still containing substantial
logic. adding the setters was peanuts compared to refactoring those
lifecycle methods.

> > What I'd like to have though, is the shear possibility to deploy James
> > in a hosted environment, like a J2EE container.
>
> I never did this, but I think people already do this:
> http://wiki.apache.org/james/Embedded

Brave men! ;-) -- I thought of something more lightweight and
portable, like JCA... But I dont expect to have something like that in
less than 1 or 2 years from now.

>
> > ok, hopefully I am able to get back to this thread [about changing James Configuration
architecture] sooner or later.
>
> Don't hurry, I think we can delay the discussion to the time someone
> will find the time to really work on this: we already have plenty of
> features to implement on the current architecture.

ok, probably a good idea.

> >> Imho configuration will never be a container agnostic thing:

ok, but the component could - and in my opinion should - be
configuration agnostic, if you are targetting
a. component reuse in another container
b. hot-reconfiguration
c. hot-redeployment

all of this is not top priority, of course.

> > mhh. the interesting question for me is: how is the configuration
> > propagated to the component?
> > a1. By using the container-specific data structures (James today)
> > a2. By using some other "generic" data structure or common
> > configuration framework
> > b. By component specific data structure
> > c. By injecting from configuration file into the component (see XBeans)
> >
> > If you have a look at how components are interwoven with the
> > configuration datastructure currently, hot re-configuration is hard to
> > achieve. At first, all the Avalon Configuration stuff would have to be
> > pulled back into the configure() method and the (at some places quite
> > substantial) configuration logic be separated from that.
>

<snip agreed="true" />

> b. This [= configuration by component specific data structure] would mean that a parent
object knows how to parse configuration

Not necessarily. Postage has a part for parsing configuration into
configuration objects (analog to a O/R-mapper it maps from
configuration to object) which are propagated later to the configured
object. the parent or any other third object involved has no knowledge
of child configurations.

> c. I don't know how it works.

see http://geronimo.apache.org/xbean/custom-xml.html for an example.
this is only for the general approach which is quite elegant.
(I won't comment on the dead links to codehaus and how development is
handled by the geronimo community. :-/ )

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message