I don't know if this would be useful for you but what we've have done to try
solve a similar (I think) problem we had was basically made a BeanFactory
that uses BuilderFactoryLogic to build beans a-la BuilderFactory.
We basically quickly hacked out a combination of
BeanFactoryBuilder/BeanFactory and BuilderFactory... we ended up with a
BeanFactory wich gives us new instances of ojects everytime we ask and each
instance gets its dependencies setted up with a BuilderFactoryLogic.
Example:
<service-point id="AFactory"
interface="org.apache.hivemind.lib.BeanFactory">
<invoke-factory service-id="pampa.common.XBeanFactoryBuilder">
<factory
vend-class="gov.afip.pampa.services.xbean.test.Interfaz"
configuration-id="AFactory"
default-cacheable="false"/>
</invoke-factory>
</service-point>
<configuration-point id="AFactory"
schema-id="pampa.common.XBeanFactoryContribution"/>
<contribution configuration-id="AFactory">
<bean name="uno">
<construct class="gov.afip.pampa.services.xbean.test.Final1">
<set property="zaraza" value="pedrito"/>
</construct>
</bean>
<bean name="dos">
<construct class="gov.afip.pampa.services.xbean.test.Final2">
<set-service property="logService"
service-id="pampa.logging.LogService"/>
</construct>
</bean>
</contribution>
Then we can do:
BeanFactory bf = (BeanFactory) registry.getService("AFactory",
BeanFactory.class);
Interfaz i1 = (Interfaz) bf.get("uno");
Interfaz i2 = (Interfaz) bf.get("dos");
To get freshly instantiated beans instantiated and builded with
BuilderFactoryLogic (ie. we get autowiring, etc.).
Some issues remain unsolved in this experiment:
1. how to get interceptors applied to the created beans
2. how to reuse some/all the <construct> part in multiple bean definitions
3. how the "default-cacheable" & "cacheable" attributes works.
Maybe Howard can tell us how healthy this can be... hehe.
(I can post code on request)
El Mar 11 Ene 2005 04:36, Liebig, Stefan escribi�:
> I have looked at the ThreadedServiceModel and I can not see how
> I can realize that I get for each service request a new instance
> of my service. The only thing I can do is to get for each method
> invocation on a service a new instance. But this is different from
> what I want.
> Am I missing something?
>
>
> Prototype? I would not associate this term with that what I need.
> Isn�t a prototype not something unique?
>
>
> Stefan
> email: [EMAIL PROTECTED]
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Mon 10.01.2005 14:33
> To: [email protected]
> Subject: Re: Trying to create a �new instance" service model, but ..
>
> A good name for this would be "prototype", because that's what Spring
> uses for the same concept.
>
> Look at how ThreadedServiceModel works.
>
> You basically need a proxy that obtains a fresh instance from the
> ServiceModel for each method invocation.
>
>
> On Mon, 10 Jan 2005 02:04:33 -0800, Liebig, Stefan
>
> <[EMAIL PROTECTED]> wrote:
> > I tried to create a �new instance� service model. This service model
> > should create for each service request a new instance. But as I found
out
> > this is not possible because ServicePointImpl �caches� the service once
> > created.
> >
> > My question - independent on how usefull a �new instance� service model
> > might be - is:
> > Shouldn�t this caching not be part of the specific service model? I
think
> > the current solution limits the usage of service models.
> >
> > Stefan
> >
> > email: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Pablo I. Lalloni <[EMAIL PROTECTED]>
Tel�fono +54 (11) 4347-3177
Proyecto Pampa
Direcci�n Inform�tica Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<james> abuse me. I'm so lame I sent a bug report to
debian-devel-changes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
