Menu
▾
▴
springframework-developer
|
From: Luke T. <ne...@fr...> - 2004-03-08 21:14:04
|
Looking at the code for the EJB base classes, unless I'm missing something obvious (not unheard of), it seems that by default a separate bean factory is created for each bean instance. http://monkeymachine.co.uk/spring/xref/org/springframework/ejb/support/AbstractEnterpriseBean.html Is this the desired behaviour? I would have expected them to share one for each JNDI key that is used. At the moment, I have a single beans xml file which holds the configuration for my DAOs, AOP stuff etc. and which is used by a set of stateless session beans. Each session bean only uses one DAO but it seems that if I follow this approach I will end up with an exponentially growing number of objects as I add new EJBs. Even if I split each bean's configuration into a separate file it still seems inefficient and counterintuitive that I end up with an application context per EJB instance. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Alef A. <al...@jt...> - 2004-03-08 22:45:24
|
> Looking at the code for the EJB base classes, unless I'm missing > something obvious (not unheard of), it seems that by default a separate > bean factory is created for each bean instance. Well, to put it bluntly: you're not mistaken; it's the way it is. As far as I'm concerned, the issue basically is that without violated any rules that apply to implementing EJBs, it's just not possible to get an ApplicationContext shared across multiple multiple beans of different types, not even across multiple instances of the same type. For one because resources instantiated as fields of EJBs should either be serializable (which the ApplicationContext isn't, not even mentioning any beans inside it), or transient (or closed and thrown away on passivation). Another solution would be (and I hate to say this, but this is what we're currently using in one of our applications that is still based on EJBs but in the process of being migrated to Spring) to bind the context in a JNDI tree, but here, the Serializable argument also applies. So that (when applying the rules really strict) is one to throw away as well. Of course when using certain EJB container, you won't have to worry about serializable issues when not accessing the JNDI from outside the VM the server is running in. Also, having the ApplicationContext defined as a singleton or something (ughh!) wouldn't result in too many problems using a simple EJB container, but I guess that's not really an option we (Spring) are eager to offer. The same applies to providing an approach based on static fields. Ohh, there is something like the BeanFactoryLocator, but this only reads in BeanFactory I believe. Basically my approach is to avoid the use EJBs where possible and if needed, implement an EJB using Spring's EJB layer and don't worry about one or two applicationcontexts too much being created. I mean, afterall, one of the reasons I choose Spring in the first place is to be able to get rid of EJBs. (I won't start a rant here, that might just be personal ;-). I don't know if this satisfies or if somebody else has opinions? Alef |
|
From: Colin S. <col...@ex...> - 2004-03-08 23:18:57
|
Actually, you can quite successfully use the BeanFactoryLocator variants
to share the same ApplicationContext or BeanFactory instance(s) across
multiple EJBs in a webapp. I am doing this in JBoss (although happilly
am almost done removing all ejbs). Just override the default
setSessionContext in a fashion similar to:
/*
* (non-Javadoc)
* @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext sessionContext) {
super.setSessionContext(sessionContext);
setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
setBeanFactoryLocatorKey(ServicesConstants.PRIMARY_CONTEXT_ID);
}
then if you want to delegate to a real POJO service doing the work, you
would also have something like:
/*
* (non-Javadoc)
* @see
org.springframework.ejb.support.AbstractStatelessSessionBean#onEjbCreate()
*/
protected void onEjbCreate() throws CreateException {
_appController = (ApplicationControllerService)
getBeanFactory().getBean(
CORE_SERVICES_APPLICATION_CONTROLLER_SERVICE);
}
where _appController is the pojo service object all methods will
delegate to. As for passivation/activation, it's not an issue for
stateless beans, as those are not legal states. For stateful beans, you
will get an unload and reload on the passivation/activation, but this is
not for real if there is already a shared instance, all that will be
unloaded/reloaded is the reference to the shared context/beanfactory.
Regards,
Colin
Alef Arendsen wrote:
>>Looking at the code for the EJB base classes, unless I'm missing
>>something obvious (not unheard of), it seems that by default a separate
>>bean factory is created for each bean instance.
>>
>>
>Well, to put it bluntly: you're not mistaken; it's the way it is.
>
>As far as I'm concerned, the issue basically is that without violated any
>rules that apply to implementing EJBs, it's just not possible to get an
>ApplicationContext shared across multiple multiple beans of different types,
>not even across multiple instances of the same type.
>
>For one because resources instantiated as fields of EJBs should either be
>serializable (which the ApplicationContext isn't, not even mentioning any
>beans inside it), or transient (or closed and thrown away on passivation).
>
>Another solution would be (and I hate to say this, but this is what we're
>currently using in one of our applications that is still based on EJBs but
>in the process of being migrated to Spring) to bind the context in a JNDI
>tree, but here, the Serializable argument also applies. So that (when
>applying the rules really strict) is one to throw away as well.
>
>Of course when using certain EJB container, you won't have to worry about
>serializable issues when not accessing the JNDI from outside the VM the
>server is running in. Also, having the ApplicationContext defined as a
>singleton or something (ughh!) wouldn't result in too many problems using a
>simple EJB container, but I guess that's not really an option we (Spring)
>are eager to offer. The same applies to providing an approach based on
>static fields.
>
>Ohh, there is something like the BeanFactoryLocator, but this only reads in
>BeanFactory I believe.
>
>Basically my approach is to avoid the use EJBs where possible and if needed,
>implement an EJB using Spring's EJB layer and don't worry about one or two
>applicationcontexts too much being created. I mean, afterall, one of the
>reasons I choose Spring in the first place is to be able to get rid of EJBs.
>(I won't start a rant here, that might just be personal ;-).
>
>I don't know if this satisfies or if somebody else has opinions?
>
>Alef
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: Alef A. <al...@jt...> - 2004-03-08 23:43:13
|
> As for passivation/activation, it's not an issue for > stateless beans, as those are not legal states. Oops, you're right. It seems like I'm already forgetting some of that horrible stuff I've been using for the last 3 years (of which I'm glad ;-). By the way, I was looking for that really big warning you had put up in the SingletonBeanFactoryLocator (wasn't it), but couldn't find it anymore. No warnings anymore ;-)? Alef > For stateful beans, you > will get an unload and reload on the passivation/activation, but this is > not for real if there is already a shared instance, all that will be > unloaded/reloaded is the reference to the shared context/beanfactory. > > Regards, > Colin > > > Alef Arendsen wrote: > > >>Looking at the code for the EJB base classes, unless I'm missing > >>something obvious (not unheard of), it seems that by default a separate > >>bean factory is created for each bean instance. > >> > >> > >Well, to put it bluntly: you're not mistaken; it's the way it is. > > > >As far as I'm concerned, the issue basically is that without violated any > >rules that apply to implementing EJBs, it's just not possible to get an > >ApplicationContext shared across multiple multiple beans of different > types, > >not even across multiple instances of the same type. > > > >For one because resources instantiated as fields of EJBs should either be > >serializable (which the ApplicationContext isn't, not even mentioning any > >beans inside it), or transient (or closed and thrown away on > passivation). > > > >Another solution would be (and I hate to say this, but this is what we're > >currently using in one of our applications that is still based on EJBs > but > >in the process of being migrated to Spring) to bind the context in a JNDI > >tree, but here, the Serializable argument also applies. So that (when > >applying the rules really strict) is one to throw away as well. > > > >Of course when using certain EJB container, you won't have to worry about > >serializable issues when not accessing the JNDI from outside the VM the > >server is running in. Also, having the ApplicationContext defined as a > >singleton or something (ughh!) wouldn't result in too many problems using > a > >simple EJB container, but I guess that's not really an option we (Spring) > >are eager to offer. The same applies to providing an approach based on > >static fields. > > > >Ohh, there is something like the BeanFactoryLocator, but this only reads > in > >BeanFactory I believe. > > > >Basically my approach is to avoid the use EJBs where possible and if > needed, > >implement an EJB using Spring's EJB layer and don't worry about one or > two > >applicationcontexts too much being created. I mean, afterall, one of the > >reasons I choose Spring in the first place is to be able to get rid of > EJBs. > >(I won't start a rant here, that might just be personal ;-). > > > >I don't know if this satisfies or if somebody else has opinions? > > > >Alef > > > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: IBM Linux Tutorials > >Free Linux tutorial presented by Daniel Robbins, President and CEO of > >GenToo technologies. Learn everything from fundamentals to system > >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > >_______________________________________________ > >Springframework-developer mailing list > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-03-09 00:38:44
|
I think the warning should still be in BeanFactoryLocator, with references to it in the actual impl. classes... Alef Arendsen wrote: >>As for passivation/activation, it's not an issue for >>stateless beans, as those are not legal states. >> >> >Oops, you're right. It seems like I'm already forgetting some of that >horrible stuff I've been using for the last 3 years (of which I'm glad ;-). > >By the way, I was looking for that really big warning you had put up in the >SingletonBeanFactoryLocator (wasn't it), but couldn't find it anymore. No >warnings anymore ;-)? > >Alef > > > > > >>For stateful beans, you >>will get an unload and reload on the passivation/activation, but this is >>not for real if there is already a shared instance, all that will be >>unloaded/reloaded is the reference to the shared context/beanfactory. >> >>Regards, >>Colin >> >> >>Alef Arendsen wrote: >> >> >> >>>>Looking at the code for the EJB base classes, unless I'm missing >>>>something obvious (not unheard of), it seems that by default a separate >>>>bean factory is created for each bean instance. >>>> >>>> >>>> >>>> >>>Well, to put it bluntly: you're not mistaken; it's the way it is. >>> >>>As far as I'm concerned, the issue basically is that without violated any >>>rules that apply to implementing EJBs, it's just not possible to get an >>>ApplicationContext shared across multiple multiple beans of different >>> >>> >>types, >> >> >>>not even across multiple instances of the same type. >>> >>>For one because resources instantiated as fields of EJBs should either be >>>serializable (which the ApplicationContext isn't, not even mentioning any >>>beans inside it), or transient (or closed and thrown away on >>> >>> >>passivation). >> >> >>>Another solution would be (and I hate to say this, but this is what we're >>>currently using in one of our applications that is still based on EJBs >>> >>> >>but >> >> >>>in the process of being migrated to Spring) to bind the context in a JNDI >>>tree, but here, the Serializable argument also applies. So that (when >>>applying the rules really strict) is one to throw away as well. >>> >>>Of course when using certain EJB container, you won't have to worry about >>>serializable issues when not accessing the JNDI from outside the VM the >>>server is running in. Also, having the ApplicationContext defined as a >>>singleton or something (ughh!) wouldn't result in too many problems using >>> >>> >>a >> >> >>>simple EJB container, but I guess that's not really an option we (Spring) >>>are eager to offer. The same applies to providing an approach based on >>>static fields. >>> >>>Ohh, there is something like the BeanFactoryLocator, but this only reads >>> >>> >>in >> >> >>>BeanFactory I believe. >>> >>>Basically my approach is to avoid the use EJBs where possible and if >>> >>> >>needed, >> >> >>>implement an EJB using Spring's EJB layer and don't worry about one or >>> >>> >>two >> >> >>>applicationcontexts too much being created. I mean, afterall, one of the >>>reasons I choose Spring in the first place is to be able to get rid of >>> >>> >>EJBs. >> >> >>>(I won't start a rant here, that might just be personal ;-). >>> >>>I don't know if this satisfies or if somebody else has opinions? >>> >>>Alef >>> >>> >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: IBM Linux Tutorials >>>Free Linux tutorial presented by Daniel Robbins, President and CEO of >>>GenToo technologies. Learn everything from fundamentals to system >>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Luke T. <ne...@fr...> - 2004-03-08 23:48:37
|
Thanks Colin... I'll try that :). Colin Sampaleanu wrote: > Actually, you can quite successfully use the BeanFactoryLocator variants > to share the same ApplicationContext or BeanFactory instance(s) across > multiple EJBs in a webapp. I am doing this in JBoss (although happilly > am almost done removing all ejbs). Just override the default > setSessionContext in a fashion similar to: > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Luke T. <ne...@fr...> - 2004-03-08 23:44:46
|
Unfortunately migration to an entire Spring solution isn't always an option for political reasons - my current client has invested a lot of time reading EJB books and I don't think they'd swallow it if I said we were going to ditch them altogether. I'm just using local stateless session beans which do nothing other than delegating calls to other business objects, but they aren't really serving any purpose other than getting in the way of a nicely configured application. Maybe I'll try extending JndiBeanFactoryLocator and implement createBeanFactory to just load the bean factory once, then set the locator in my EJBs. I'm only using stateless beans and I don't really care about the spec if it works... or perhaps I'll just bite the bullet and suggest that we get rid of them altogether. Alef Arendsen wrote: >>Looking at the code for the EJB base classes, unless I'm missing >>something obvious (not unheard of), it seems that by default a separate >>bean factory is created for each bean instance. > > Well, to put it bluntly: you're not mistaken; it's the way it is. > > As far as I'm concerned, the issue basically is that without violated any > rules that apply to implementing EJBs, it's just not possible to get an > ApplicationContext shared across multiple multiple beans of different types, > not even across multiple instances of the same type. > > For one because resources instantiated as fields of EJBs should either be > serializable (which the ApplicationContext isn't, not even mentioning any > beans inside it), or transient (or closed and thrown away on passivation). > > Another solution would be (and I hate to say this, but this is what we're > currently using in one of our applications that is still based on EJBs but > in the process of being migrated to Spring) to bind the context in a JNDI > tree, but here, the Serializable argument also applies. So that (when > applying the rules really strict) is one to throw away as well. > > Of course when using certain EJB container, you won't have to worry about > serializable issues when not accessing the JNDI from outside the VM the > server is running in. Also, having the ApplicationContext defined as a > singleton or something (ughh!) wouldn't result in too many problems using a > simple EJB container, but I guess that's not really an option we (Spring) > are eager to offer. The same applies to providing an approach based on > static fields. > > Ohh, there is something like the BeanFactoryLocator, but this only reads in > BeanFactory I believe. > > Basically my approach is to avoid the use EJBs where possible and if needed, > implement an EJB using Spring's EJB layer and don't worry about one or two > applicationcontexts too much being created. I mean, afterall, one of the > reasons I choose Spring in the first place is to be able to get rid of EJBs. > (I won't start a rant here, that might just be personal ;-). > > I don't know if this satisfies or if somebody else has opinions? > > Alef > > > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Alef A. <al...@jt...> - 2004-03-09 00:05:59
|
> Maybe I'll try extending JndiBeanFactoryLocator and implement > createBeanFactory to just load the bean factory once, then set the > locator in my EJBs. I'm only using stateless beans and I don't really > care about the spec if it works... or perhaps I'll just bite the bullet > and suggest that we get rid of them altogether. Well, you can always try to of course ;-). In the meantime I hope you've read Colin's take on it. Regards, Alef > > Alef Arendsen wrote: > > >>Looking at the code for the EJB base classes, unless I'm missing > >>something obvious (not unheard of), it seems that by default a separate > >>bean factory is created for each bean instance. > > > > Well, to put it bluntly: you're not mistaken; it's the way it is. > > > > As far as I'm concerned, the issue basically is that without violated > any > > rules that apply to implementing EJBs, it's just not possible to get an > > ApplicationContext shared across multiple multiple beans of different > types, > > not even across multiple instances of the same type. > > > > For one because resources instantiated as fields of EJBs should either > be > > serializable (which the ApplicationContext isn't, not even mentioning > any > > beans inside it), or transient (or closed and thrown away on > passivation). > > > > Another solution would be (and I hate to say this, but this is what > we're > > currently using in one of our applications that is still based on EJBs > but > > in the process of being migrated to Spring) to bind the context in a > JNDI > > tree, but here, the Serializable argument also applies. So that (when > > applying the rules really strict) is one to throw away as well. > > > > Of course when using certain EJB container, you won't have to worry > about > > serializable issues when not accessing the JNDI from outside the VM the > > server is running in. Also, having the ApplicationContext defined as a > > singleton or something (ughh!) wouldn't result in too many problems > using a > > simple EJB container, but I guess that's not really an option we > (Spring) > > are eager to offer. The same applies to providing an approach based on > > static fields. > > > > Ohh, there is something like the BeanFactoryLocator, but this only reads > in > > BeanFactory I believe. > > > > Basically my approach is to avoid the use EJBs where possible and if > needed, > > implement an EJB using Spring's EJB layer and don't worry about one or > two > > applicationcontexts too much being created. I mean, afterall, one of the > > reasons I choose Spring in the first place is to be able to get rid of > EJBs. > > (I won't start a rant here, that might just be personal ;-). > > > > I don't know if this satisfies or if somebody else has opinions? > > > > Alef > > > > > > > > > > -- > Luke Taylor. Monkey Machine Ltd. > PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
