Coming a little late to the party, but a couple of comments...
1) how about putting the factory classes in
org.apache.beehive.netui.core.factory? This seems like infrastructure
that could grow over time; would be nice to contain this growth in one
place. :)
2) it's great to have the ability to create a Factory object in a way
that doesn't require XMLBeans. In a world where a webapp's
configuration lives inside of Spring or HiveMind, it seems good to keep
knowledge of XMLBeans for config optional. The method:
Factory.getFactory(ServletContext, Class, FactoryConfig)
serves this purpose well.
3) how about splitting the static getFactory(...) methods out of the
abstract Factory base class and into a separate utility class? Just
keeps these static factory methods (which some web-tier folks oppose)
off of the Factory abstract base class. Though, the name FactoryFactory
bothers me for some reason. :)
4) are Factory instances ever serialized? It seems like they could be
given that they're Serializable. In the case where a Factory is
serialized, is it up to a Factory client to reinit the ServletContext?
Rich Feit wrote:
For my part, that sounds like a good place!
Rich
Carlin Rogers wrote:
Yes, thanks Rich.
Also I was wondering if anyone felt strongly about where I move the
Factory and FactoryConfig class. How about the
org.apache.beehive.netui.core package?
Carlin
On 6/24/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I think you're right about all this -- seems like what needs to happen
is that there should be a method like this:
public static Factory getFactory(ServletContext servletContext,
Class factoryType, FactoryConfig config)
which would be called by the current XmlBean-based getFactory().
Sound good?
Rich
Carlin Rogers wrote:
Sure, good idea. So the ServletContainerAdapter interface would
have a new method getFactory( Class factoryClass ) where
Factory.class.isAssignableFrom( factoryClass ) must be true?
In my case, URLTemplatesFactory would need to extend Factory
and would implement the init() method where I'd use the
static method Factory.getFactory(). I noted that the Factory
class implementation takes a PageflowFactory object
(which extends an xmlbeans XmlObject) as an argument to
the static getFactory() method containing a String
for the class name of the factory... and then uses
DiscoveryUtils to get a class loader. Not sure this jibes
with what you were asking for.
For a generic Factory from the container adapter, I'm not sure
we'd always have an XmlObject to pass in. I'm now a little
confused as to how best to use the Factory class. Rich,
do you have more thoughts on this?
Thanks,
Carlin
On 6/24/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Hi Carlin,
This makes sense to me. As to getting a Factory from the
ServletContainerAdapter, would it be possible to have the method
signature take a base Class instead of String? Seems like we can
avoid
finding a classloader and loading the class each time, and in most
cases
we'd be passing a statically-known Class.
Rich
Carlin Rogers wrote:
All,
I'm implementing a way to get a URLTemplateFactory from the
ServletContainerAdapter. However, I'm not sure a specific
method like this follows with the other methods that a
ServletContainerAdapter implementation provides.
One thought would be I'd like to have a generic way to get
a Factory from the the ServletContainerAdapter given a
class name.
We already do this using class names from the config file.
The generic Factory class is in the pageflow package.
It would be great to move this to the utils or core package
of NetUI. Then I could also add this to the ServletContainerAdapter.
I would also move the FactoryConfig class as well as we
already have other Config support in utils.
I don't think Factory or FactoryConfig are used by or
exposed to beehive users. It should be a safe move to make.
Opinions or concerns? Or other ideas for providing a generic
way to create a Factory from a container specific implementation?
Thanks,
Carlin
