You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Carlin Rogers <ca...@gmail.com> on 2005/06/24 18:26:22 UTC

Move the NetUI generic Factory in to the utils or core package?

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

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Eddie O'Neil <ek...@bea.com>.
   CIL...

Carlin Rogers wrote:
> Hi Eddie,
> 
> Thanks for the input.
> 
> 1) Sure, I could move the factory classes from 
> org.apache.beehive.netui.core down into 
> org.apache.beehive.netui.core.factory. Easy enough.
> 
> 2) Factory.getFactory(ServletContext, Class, FactoryConfig)
> is already in the src trunk.
> 
> 3) How about a class named FactoryUtils with the 
> static factory methods?
> 

   Yep -- that'd work for me.

   Everything else sounds good.



> 4) yes, you're correct. From the javadoc on factory,
> it the client would call reinit(), passing in the 
> ServletContext.
> 
> Anyone have some additional thoughts? I can make these 
> changes shortly and submit a patch for review if this looks
> right.
> 
> Carlin
> 
> On 7/4/05, Eddie O'Neil <ek...@bea.com> wrote:
> 
>>   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 <ri...@gmail.com> 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 <ri...@gmail.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
> 


Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Carlin Rogers <ca...@gmail.com>.
Hi Eddie,

Thanks for the input.

1) Sure, I could move the factory classes from 
org.apache.beehive.netui.core down into 
org.apache.beehive.netui.core.factory. Easy enough.

2) Factory.getFactory(ServletContext, Class, FactoryConfig)
is already in the src trunk.

3) How about a class named FactoryUtils with the 
static factory methods?

4) yes, you're correct. From the javadoc on factory,
it the client would call reinit(), passing in the 
ServletContext.

Anyone have some additional thoughts? I can make these 
changes shortly and submit a patch for review if this looks
right.

Carlin

On 7/4/05, Eddie O'Neil <ek...@bea.com> wrote:
> 
>    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 <ri...@gmail.com> 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 <ri...@gmail.com> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
> >
> 
>

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Eddie O'Neil <ek...@bea.com>.
   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 <ri...@gmail.com> 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 <ri...@gmail.com> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>
>>>>
>>>>     
>>
>>
>>  
>>
> 


Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Rich Feit <ri...@gmail.com>.
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 <ri...@gmail.com> 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 <ri...@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>
>>>      
>>>
>
>  
>

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Carlin Rogers <ca...@gmail.com>.
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 <ri...@gmail.com> 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 <ri...@gmail.com> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Rich Feit <ri...@gmail.com>.
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 <ri...@gmail.com> 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
>>>
>>>
>>>
>>>      
>>>
>
>  
>

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Carlin Rogers <ca...@gmail.com>.
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 <ri...@gmail.com> 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
> >
> >
> >
>

Re: Move the NetUI generic Factory in to the utils or core package?

Posted by Rich Feit <ri...@gmail.com>.
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
>
>  
>