|
From: Colin S. <col...@ex...> - 2003-11-14 20:22:01
|
Ok, to allow spec compliance for the MDB, I have changed things so that
- AbstractEnterpriseBean#loadBeanFactory throws BootstrapException,
not CreateException
- AbstractMessageDrivenBean#ejbCreate no longer throws
CreateException, the BootstrapException will just flow through
- AbstractStatelessSessionBean#ejbCreate, since it was calling
loadBeanFactory, it is able to catch BootStrapException, and rethrow it
as CreateException, to behave just as before.
- AbstractStatefulSessionBean#loadBeanFactory no longer throwns
CreateException, it will just let the BootStrapException from its super
flow through.
I am quite confused as to why AbstracteStatelessSessionBean has an
ejbCreate impl and automatically calls loadBeanFactory, while
AbstractStatefulSessionBean doesn't do this, simply overriding
loadBeanFactory to allow subclasses to call it if needed. This
difference between the two seems very arbitrary. Can someone explain?
Colin Sampaleanu wrote:
> Now the only question is what to do with loadBeanFactory in
> AbstractEnterpriseBean, which throws CreateException. It could either
> be left that way, and AbstractMessageDrivenBean could rewrap it is
> something derived from RuntimeException or alternately just pull out
> the BootstrapException and throw that. However, I think it is cleaner
> for loadBeanFactory to just throw BootstrapException directly, and
> AbstractSessionBean will itself wrap it with a CreateException, while
> AbstractMessageDrivenBean just lets it flow through.
>
>
> Colin Sampaleanu wrote:
>
>> It may work in some versions of JBoss. JBoss 3.2.2 doesn't deploy the
>> bean at all though:
>> ----
>> 12:22:35,853 ERROR [MainDeployer] could not create deployment:
>> file:/C:/dev/jbos
>> s-3.2.2/server/default/deploy/core-app.ear
>> org.jboss.deployment.DeploymentException: Verification of Enterprise
>> Beans faile
>> d, see above for error messages.
>> at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:491)
>> at
>> org.jboss.deployment.MainDeployer.create(MainDeployer.java:786)
>> at
>> org.jboss.deployment.MainDeployer.create(MainDeployer.java:778)
>> at
>> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>> ...
>> 12:22:36,118 ERROR [URLDeploymentScanner] MBeanException: Exception
>> in MBean ope
>> ration 'checkIncompleteDeployments()'
>> Cause: Incomplete Deployment listing:
>> Packages waiting for a deployer:
>> <none>
>> Incompletely deployed packages:
>> [org.jboss.deployment.DeploymentInfo@47111691 {
>> url=file:/C:/dev/jboss-3.2.2/ser
>> ver/default/deploy/core-app.ear }
>> deployer: org.jboss.deployment.EARDeployer@4977e2
>> status: Deployment FAILED reason: Verification of Enterprise Beans
>> failed, see
>> above for error messages.
>> state: FAILED
>> watch: file:/C:/dev/jboss-3.2.2/server/default/deploy/core-app.ear
>> lastDeployed: 1068830549227
>> ----
>>
>> So I don't see much choice but to change it. That is, I think it
>> makes more sense that it's compliant and works in JBoss, and works
>> with compliant code in other app servers, and breaks some
>> non-compliant code in other app servers, than the current situation
>> where we force non-compliant code, which can't run on JBoss at all.
>>
>> Regardless of Spring, the real question is if there is an app-server
>> out there that breaks without the CreateException. If that's the
>> case, it would kill cross-server compatibility...
>>
>>
>>
>> Rod Johnson wrote:
>>
>>> Yes, as the bug entries say I took the decision that it is incorrect
>>> according to the spec, but the WebLogic examples do throw
>>> CreateException.
>>> And the user reported that it _did_ still work in JBoss, so I
>>> figured that I
>>> didn't want to have to go test it in all EJB containers. (Ie I
>>> didn't have
>>> time to retest it in WLS.)
>>>
>>> However, you probably should change it.
>>>
>>> Regards,
>>> Rod
>>>
>>> ----- Original Message ----- From: "jürgen höller [werk3AT]"
>>> <jue...@we...>
>>> To: <spr...@li...>
>>> Sent: Friday, November 14, 2003 5:40 PM
>>> Subject: Re: [Springframework-developer] AbstractMessageDrivenBean's
>>> ejbCreate method is not spec compliant, I am going to change it
>>>
>>>
>>> There's a bug entry on SourceForge for this:
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=823990&group_id=73357&atid=537539
>>>
>>>
>>> Juergen
>>>
>>> ________________________________
>>>
>>> Von: spr...@li... im
>>> Auftrag von
>>> Colin Sampaleanu
>>> Gesendet: Fr 14.11.2003 18:41
>>> An: spr...@li...
>>> Betreff: [Springframework-developer] AbstractMessageDrivenBean's
>>> ejbCreate
>>> method is not spec compliant, I am going to change it
>>>
>>>
>>>
>>> AbstractMessageDrivenBean currently has the following ejbCreate method:
>>>
>>> /**
>>> * Lifecycle method required by the EJB specification but not
>>> * the MessageDrivenBean interface.
>>> * <p>This implementation loads the BeanFactory. Don't override it
>>> * (although it can't be made final): code your initialization in
>>> * onEjbCreate(), which is called when the BeanFactory is available.
>>> * <p>Unfortunately we can't load the BeanFactory in
>>> setSessionContext(),
>>> * as ResourceManager access isn't permitted and the BeanFactory may
>>> require it.
>>> */
>>> public void ejbCreate() throws CreateException {
>>> loadBeanFactory();
>>> onEjbCreate();
>>> }
>>>
>>> This is actually not spec compliant. If you look at the spec, section
>>> 15.7.3, it states that MessageDrivenBeans must not throw application
>>> exceptions. CreateException is an application exception, and in fact
>>> JBoss, for example, will not allow an MDB with this create method to
>>> load.
>>>
>>> So I am going to change this to remove the exception, after I get back
>>> from lunch. If anybody disagrees with me, before or after that, please
>>> let me know.
>>>
>>> (lucky me, still putzin' around with legacy EJB code...)
>>>
>>> Regards,
>>> Colin
>>>
>>>
>>>
>>
>>
>
>
|