[seam-dev] Followup to discussion of view co-existence

[Clint Popetz]

Hi,

(Thanks for all your welcome messages...I'm glad to be able to help
out.  And it looks like I'm active in Jira at last, so assign away!)

Pete asked me to follow-up to the list about the state of my attempts
to have multiple view layers, in particular jsf and wicket, co-exist
in the same deployment.  This comes down to needing to choose an
implementation-specific sublass of components like Manager and
StatusMessages on a per-request basis.

Working with Pete in IM, we were trying to invent a general mechanism
for this, and came up with the idea of an application-scoped
"instantiator" component that uses events to register possible
implementations.  The base component then uses this instantiator
within an @Unwrap.  So, in pseudocode:

@Scope(Event)
Manager
{
  @Unwrap unwrap()
  {
     return ((Instantiator<Manager>)
       Component.getInstance(ManagerInstantiator.class)).selectImplementation();
  }
}

And the instantiator:

@Scope(Application)
ManagerInstantiator extends Instantiator<Manager>
{
   @Create
    registerImplementations()
    {
       //use events to build a list of implementation components...components
       // like FacesManager listen to these events
    }

  public Manager
  selectImplementation()
  {
     //go through the list, find the active implementation, return it.
  }
}


It's a little more complicated than that because of re-entrancy
concerns and needing a default implementation for cases like
initialization, when there is no request and thus an implementation
cannot be chosen.  (See attached patch.)  But that's the basic idea.

This is currently working except for one problem: we need to be able
to use components.xml to configure things like the manager:

   <core:manager  conversation-id-parameter="myCidName"/>

and that configuration needs to be applied to the implementation,
which doesn't happen with @Unwrap or @Factory.  I see a couple options
at this point.

(1) Propagate properties from the base Manager to the selected
implementation by hand in my @Unwrap.  Not a good general solution,
error prone, etc.

(2) Use Component.forName("org.jboss.seam.Manager").initialize(selectedImpl)
to initialize the Manager subclass after we've selected it in @Unwrap.
 This is, I'm guessing, a subversion of the initialize() method, and
would work.  But it's not a general solution.

(3) Refactor Manager so that these configurable parameters are in a
separate ManagerSettings component that Manager then uses.  Possible,
still not a general solution, and this would require people to change
their components.xml to refer to this class, or to have
ManagerSettings have the "org.jboss.seam.core.Manager" name and make
the real manager have a different name, which breaks backward
compatibility for anyone referring to the manager by name and not
using injection or the static Manager.getInstance().

(4) Let xml-specified initialization properties be applied to the
results of @Factories by changing
Initialization.installComponentFromXmlElement to check for a @Factory
for the name/className if a class with a @Name cannot be found, and by
running any initializers in Component.handleFactoryMethodResult.

(5) Provide a new decorator that is similar to @Unwrap but describes a
method that returns a delegate component that should assume the name
of the original in the context, and should have configuration applied
to it.  So if you do:

Component.getInstance("org.jboss.seam.core.Manager",true)

and the instance isn't found, that component is created as usual, but
if it has a method annotated as:

@DelegateComponent
public Manager getDelegateManager()
{
  ...
}

then the following happens:

(1) initializers that describe the base Manager are applied to the
returned delegate
(2) the resulting object is placed in the context replacing the original

The latter is a performance issue, which is especially crucial for the
Manager component, which gets looked up many times per request and we
don't want to repeat the selectImplementation() process for each
lookup.  (Pete, I profiled this, and it was indeed an issue.)

Thanks for reading all of this, and I'd appreciate any feedback.  In
particular, I'd be interested if there's a direction that the design
of web beans would suggest we take.


Thanks,
-Clint
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi-view.patch
Type: application/octet-stream
Size: 18099 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/seam-dev/attachments/20081113/b0723c66/attachment.obj