I agree with point 1 and 2 completely.
Thanks once again.
Cheers,
Sandip
--- David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Jan 27, 2005, at 2:11 PM, Sandip Ghayal wrote:
>
> > Hi David,
> >
> > Thanks for response David and sorry to bug you
> guys
> > with this issues.
>
> No problem, maybe we'll learn something :-)
> >
> > This is what I am trying to achieve.
> >
> > 1) Deploy EJB. (without resolving any references)
> > 2) Deploy Resource 1.
> > 3) Modify EJB plan (some how) to point to Resource
> 1.
> > 4) Deploy Resource 2.
> > 5) Change EJB plan (some how) to point to Resource
> 2.
> >
>
> Currently there is no way to do this in geronimo.
> So, we can discuss
> whether this is a good idea and how it might be
> possible to implement
> it.
>
> > Though this is not required for passing J2EE1.4
> TCK
> > but I do think this could be the most common
> > applications users would like to do. (1) if
> Resource 1
> > is brought down for maintenance, users may want to
> > switch to using backup Resource2. Best way to do
> that
> > is to use steps 4 and 5 (2) If in current user
> testing
> > there is no need to test any Resource operations
> then
> > at this time they can avoid deploying Resource. I
> can
> > expand this to if there is a single implementation
> of
> > stateless session bean. And it has been envisioned
> > that usage of Resource is not compulsory for
> operation
> > of this bean. So if Resource is there then its
> good
> > and if its not there then also bean can operate.
> > Operation could be context.lookup("JNDI NAME")
> throws
> > back exception and bean marks that the current
> > deployment is not using Resource. As per current
> > design users will be forced to deploy Resource if
> they
> > want to use this Session Bean or create another
> > session bean that does not refer to resource.
> >
> > What I am seeing is just different way of looking.
> You
> > are looking at it as plan-first then deploy. I am
> > looking at is Server should not enforce plan-first
> > philosophy. Deploy and plan could happen in any
> > sequence.
>
> I think there are 2 scenarios you are proposing:
>
> 1. optional resource refs. If a resource-ref isn't
> configured to point
> to anything, the application can still deploy, but
> if it tried to look
> up the resource it will get a naming error. One
> easy way to implement
> this would be with a tag in the plan indicating that
> the resource-ref
> is optional. We could try to resolve the link and
> ignore failure. If
> an entire target name is supplied we bind a
> reference to it, and if the
> gbean is missing at runtime, you'll get an error
> when you try to look
> it up (can't make a proxy). The second could cause
> a problem when
> starting the configuration if we turned the jndi
> references into gbean
> dependencies, something I am in favor of. (see also
> (2))
>
> 2. changing what a resource-ref is pointing to at
> runtime, while the
> app is running. This IMO is harder and some
> implementations are
> counter to some of our philosophical bases (or
> biases). One of the
> basic ideas of the deployment system is that we
> convert whatever
> plans/modules/whatever you deploy into binary
> configurations in which
> all references are completely resolved. You can
> digitally sign these,
> pass them around, deploy on multiple servers, etc,
> and have (through
> the signature) some good evidence of what is running
> where. IMO
> completely resolving all references before building
> the binary
> configuration is an important part of auditability
> of the configuration
> when it is running. So, being able to swap what's
> underneath a running
> program might conflict with this idea.
>
> What I'd prefer to see is a good versioning system
> for configurations,
> together with the ability to hot-switch between
> different versions of
> the same app. What you'd do is configure and deploy
> a new version of
> your app so the ejbs are pointing to resource 2
> rather than resource 1,
> deploy the second version, and undeploy the first
> version.
>
> Assuming we could actually implement this, do you
> think it would cover
> what you want?
>
> many thanks,
> david jencks
>
> >
> > Thanks,
> >
> > Sandip
> > --- David Jencks <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> On Jan 27, 2005, at 12:10 PM, Sandip Ghayal
> wrote:
> >>
> >>> I have one more question/issue.
> >>>
> >>> I facing issue when trying to deploy simple
> >> EJB.jar
> >>> file which has a resource reference to
> connector.
> >> The
> >>> issue is as this is Jar file there is no
> connected
> >>> embedded into this jar file. Also the connector
> >> was
> >>> not previously deployed.
> >>>
> >>> So during deployment I get exception as below.
> The
> >>> exception is complaining that there is no
> >>> corresponding resource reference.
> >>>
> >>> Is it expected behaviour ? Should not Geronimo
> >> allow
> >>> users to do mapping of resources at later stage.
> >> Is
> >>> there any kind of workaround for this situation
> ?
> >>
> >> The deployment process is expected to resolve all
> >> references. There's
> >> a lot of "magic" that lets you specify only a
> little
> >> bit of the
> >> resource name, and the deployer will find the
> rest
> >> for you, but for
> >> this to work the resource has to be available
> while
> >> you are doing the
> >> deployment. Currently the only way to reliably
> make
> >> this happen is to
> >> put the resource in the parent or ancestor of the
> >> package/plan you are
> >> trying to deploy. This has the other effect of
> >> putting the resource in
> >> your classpath which is often unnecessary and
> >> possibly undesirable.
> >>
> >> You should be able to avoid this problem if you
> >> specify the entire
> >> jsr-77 object name of the managed connection
> >> factory wrapper gbean in
> >> a target-name element. I find the only reliable
> way
> >> to find out what
> >> this might be is to deploy the resource and copy
> the
> >> name out of the
> >> log.
> >>
> >> We might have paradigm mismatch here. :-) I'm
> >> having trouble
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
