Re: Some more deployment questions

David Jencks 27 Jan 2005 22:40:34 -0000


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
imagining when "later" would be.  Could you explain
what you have in
mind?
One thing to remember is the theoretical future
existence of jsr-88
tools to help you write the plans before the current
"deployment" step
:-)
many thanks,
david jencks
F:\geronimo\modules\assembly\target\geronimo-1.0-SNAPSHOT>java
-jar bin/deployer
.jar deploy I:\TestEjb.jar
Username: system
Password: manager
Deployment failed
  Server reports:
org.apache.geronimo.common.DeploymentException:
Unknown or amb
iguous resource name query:
geronimo.server:j2eeType=JCAManagedConnectionFactory
,J2EEServer=geronimo,J2EEApplication=null,name=jdbc/Connector,*
match count: 0
org.apache.geronimo.kernel.InternalKernelException:
org.apache.geronimo.common.D
eploymentException: Unknown or ambiguous resource
name
query: geronimo.server:j2
eeType=JCAManagedConnectionFactory,J2EEServer=geronimo,J2EEApplication=
null,name
=jdbc/Connector,* match count: 0
        at
org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.j
ava:232)
        at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(Dis
tributeCommand.java:86)
        at java.lang.Thread.run(Thread.java:534)
Caused by:
org.apache.geronimo.common.DeploymentException:
Unknown or ambiguous
resource name query:
geronimo.server:j2eeType=JCAManagedConnectionFactory,J2EESe

rver=geronimo,J2EEApplication=null,name=jdbc/Connector,*
match count: 0
        at
org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.locat
eResourceName(ConnectorModuleBuilder.java:788)
        at
org.apache.geronimo.connector.deployment.ConnectorModuleBuilder$$Fast
ClassByCGLIB$$a535b6aa.invoke(<generated>)
        at
net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
        at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
Invoker.java:38)
        at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:118)
        at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:658)
        at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
7)
        at
org.apache.geronimo.kernel.proxy.RawOperationInvoker.invoke(RawOperat
ionInvoker.java:36)
        at
org.apache.geronimo.kernel.proxy.ProxyMethodInterceptor.intercept(Pro
xyMethodInterceptor.java:92)
        at
org.apache.geronimo.j2ee.deployment.ResourceReferenceBuilder$$Enhance
rByCGLIB$$f168bc13.locateResourceName(<generated>)
        at
org.apache.geronimo.j2ee.deployment.RefContext.getConnectionFactoryCo
ntainerId(RefContext.java:277)
        at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.getResourceCon
tainerId(ENCConfigBuilder.java:206)
        at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addResourceRef
s(ENCConfigBuilder.java:188)
        at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponent
Context(ENCConfigBuilder.java:600)
        at
org.openejb.deployment.SessionBuilder.processEnvironmentRefs(SessionB
uilder.java:138)
        at
org.openejb.deployment.SessionBuilder.addEJBContainerGBean(SessionBui
lder.java:222)
        at
org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:
153)
        at
org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBu
ilder.java:446)
        at
org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b
20.invoke(<generated>)
        at
net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
        at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
Invoker.java:38)
        at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:118)
        at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Some more deployment questions

Reply via email to