> Why can't the binding decision be recorded at deployment time so that it
> can only fail as above when the app is redeployed?
That's certainly possible. Still, it'll be surprising to an admin that an
application suddenly causes a deployment error because he or someone else
had deployed another resource adapter.
> -----Original Message-----
> From: dev-return-5382-frank.kieviet=sun.com_at_glassfish.dev.java.net
> [mailto:dev-return-5382-frank.kieviet=sun.com_at_glassfish.dev.java.net] On
> Behalf Of Bill Shannon
> Sent: Sunday, January 27, 2008 20:17
> To: dev_at_glassfish.dev.java.net
> Subject: Re: Non-JMS MDB needs JMS?
>
> Frank Kieviet wrote:
> > [fkieviet] I respectfully disagree with this: a solution that "through
> > magic" works in most cases but not in all cases, or suddenly may stop
> > working, is worse than no solution at all. Say that you have
> successfully
> > deployed a few EJBs that all use RAR 1 and that Glassfish bound the EJBs
> to
> > RAR 1 by comparing interfaces. Now say that a few weeks later, you
> deploy
> > RAR 2 that uses the same interfaces. Say that the server is restarted:
> > suddenly the EJBs can no longer be unambiguously bound to RAR 1 or RAR
> 2,
> > and a startup failure of the previously successfully deployed EJBs will
> > occur. This may be surprising to the admin since he cannot readily
> correlate
> > deployment of RAR 2 to the failure in the previously successfully
> deployed
> > EJBs.
>
> Why can't the binding decision be recorded at deployment time so that it
> can only fail as above when the app is redeployed?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net