You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Sandip Ghayal <sg...@yahoo.com> on 2005/01/27 21:10:34 UTC
Some more deployment questions
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 ?
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.
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.ModuleBuilder$$EnhancerByCGLIB$$9
e45a280.addGBeans(<generated>)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfigurati
on(EARConfigBuilder.java:346)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLI
B$$38e56ec6.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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$
$7a1ca0ae.buildConfiguration(<generated>)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:200)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:80)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i
nvoke(<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:684)
at
org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:308)
at
org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:121)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.in
voke(<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:684)
at
org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:308)
at
org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServer
Delegate.java:117)
at
mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java
:222)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:36)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjec
tInvoker.java:98)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionS
ubjectInvoker.java:32)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjec
tInvoker.java:89)
at
java.security.AccessController.doPrivileged(Native
Method)
at
javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
at
mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:151)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnecti
onSubjectInvoker.java:85)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubje
ctInvoker.java:79)
at $Proxy0.invoke(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImp
l.java:224)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at
sun.rmi.transport.Transport$1.run(Transport.java:148)
at
java.security.AccessController.doPrivileged(Native
Method)
at
sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4
60)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:701)
... 1 more
Thanks,
Sandip Ghayal
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Some more deployment questions
Posted by David Jencks <dj...@gluecode.com>.
On Jan 28, 2005, at 9:51 AM, Sandip Ghayal wrote:
> Just continuing our discussion from yesterday.
>
> I am little confused.
>
> As I understand from yesterdays discussion, I need to
> deploy Resoruce first and then the EJB
yes, unless they are both in an ear
>
> So I tried to deploy connector rar file first and then
> my EJB which would have refrence to this, but then I
> get error as below (Error#1) when trying to deploy
> connector
>
> I was under the impression that plans are created on
> the fly and users does not have to do anything much
> for that. Is there any thing I need to do before I can
> deploy this connector ? (The connector is standard
> J2EE 1.4 connector)
You always need a plan for a connector. We can talk about this more,
but to me the ra.xml is really a description of a type rather than an
instance. All other j2ee dds describe what I consider an instance.
Maybe you can convince me there is a way to reasonably extract a
default instance description from the ra.xml :-)
>
> I looked at the docs and found that there was
> requirement to create geronimo-ra.xml file before one
> can deploy connectors. I think this requirement has
> been removed (after watching up some of the deployment
> related messages). But still I created geronimo-ra.xml
> and put it into the Connector rar file. After doing
> this I get different error (as per error#2)
You don't need to put the plan in the connector, you can deploy it
standalone instead, but you still need a plan.
>
> Next thing I tried was to combine connector rar and my
> EJB's JAR file into a EAR file and try to deploy that
> EAR file. I also created application.xml file for this
> purpose, but again during deployment I got error#2.
>
> Command that I used to start Geronimo Server:
> # java -jar bin\server.jar
> org/apache/geronimo/RuntimeDeployer
> org/apache/geronimo/DebugConsole
>
that is reasonable, but you should be able to just say
java -ea -jar bin/server.jar
and due to the persistent configuration list everything should start
(famous last words :-)
> Command that I used to do deployment:
> # java -jar bin\deployer.jar deploy I:\TestEar.ear
>
looks good
> I have a feeling that I am missing some crucial part
> in entire deployment process and some how its either
> not mention in the docs or I am looking at the wrong
> docs.
I think you've found our least informative and most frustrating error
message :-)
Most likely something is preventing some of the deployer gbeans from
starting. You can check geronimo.log (basedir/var/log/geronimo.log)
for messages like
waiting to start: .... cause...
Information on non-started gbeans should also show up on the console at
the end of server startup.
Hope this helps... if not can you send me privately the geronimo.log?
thanks
david jencks
>
> ----------------------------------------------------------------------
> ERROR#1:
> ----------------------------------------------------------------------
> Deployment failed
> Server reports:
> org.apache.geronimo.common.DeploymentException: A
> connector module must be deployed using a plan
> org.apache.geronimo.kernel.InternalKernelException:
> org.apache.geronimo.common.DeploymentException: A
> connector module must be
> deployed using a plan
> at
> org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.jav
> a:232
> )
> at
> org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(Distr
> ibute
> Command.java:86)
> at java.lang.Thread.run(Thread.java:534)
> Caused by:
> org.apache.geronimo.common.DeploymentException: A
> connector
> module must be deployed using a plan
> at
> org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.creat
>
> -----------------------------------------------------------------------
> --------------
> Error #2:
> -----------------------------------------------------------------------
> --------------
> Deployment failed
> Server reports:
> org.apache.geronimo.common.DeploymentException: Syntax
> error i
> n deployment plan or no deployer service available
> (currently I can't tell the d
> ifference):,
> moduleFileC:\DOCUME~1\sghayal\LOCALS~1\Temp\deployer34036.tmpdir\JD
> BCwhitebox-tx.rar
> org.apache.geronimo.kernel.InternalKernelException:
> org.apache.geronimo.common.D
> eploymentException: Syntax error in deployment plan or
> no deployer service avail
> able (currently I can't tell the difference):,
> moduleFileC:\DOCUME~1\sghayal\LOC
> ALS~1\Temp\deployer34036.tmpdir\JDBCwhitebox-tx.rar
> 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)
>
> -----------------------------------------------------------------------
> --------
>
>
> Thanks,
>
> Sandip Ghayal
> --- Sandip Ghayal <sg...@yahoo.com> wrote:
>
>> I agree with point 1 and 2 completely.
>>
>> Thanks once again.
>>
>> Cheers,
>>
>> Sandip
>> --- David Jencks <dj...@gluecode.com> 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 <dj...@gluecode.com> 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
>>
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - What will yours do?
> http://my.yahoo.com
>
Re: Some more deployment questions
Posted by Jeremy Boynes <jb...@apache.org>.
Sandip Ghayal wrote:
> Just continuing our discussion from yesterday.
>
> I am little confused.
>
> As I understand from yesterdays discussion, I need to
> deploy Resoruce first and then the EJB
>
> So I tried to deploy connector rar file first and then
> my EJB which would have refrence to this, but then I
> get error as below (Error#1) when trying to deploy
> connector
>
> I was under the impression that plans are created on
> the fly and users does not have to do anything much
> for that. Is there any thing I need to do before I can
> deploy this connector ? (The connector is standard
> J2EE 1.4 connector)
>
Plans are not created on the fly - they are the server-specific
configuration information needed to get the module to run (aka a vendor
deployment descriptor). For some modules, especially WARs, there are
common cases where no additional information is needed and we can figure
out how to make it run based on the standard deployment descriptor and a
set of default rules. I believe, however, that there is insufficient
information in a standard ra.xml for that to work and hence we need a plan.
> I looked at the docs and found that there was
> requirement to create geronimo-ra.xml file before one
> can deploy connectors. I think this requirement has
> been removed (after watching up some of the deployment
> related messages). But still I created geronimo-ra.xml
> and put it into the Connector rar file. After doing
> this I get different error (as per error#2)
You can put it inside, or leave the RAR file as is and specify the plan
on the command line.
What is happening with Error #2 is that we are unable to validate the
plan and so can't tell if it is actually a malformed geronimo-ra.xml or
something else entirely. This is a known issue which we are still
stuggling to resolve neatly.
Common problems are not specifying the right namespace on the root
element, or having a pre-1.4 plan without a DOCTYPE element. Or, just
having a malformed or invalid document.
--
Jeremy
Re: Some more deployment questions
Posted by Sandip Ghayal <sg...@yahoo.com>.
Just continuing our discussion from yesterday.
I am little confused.
As I understand from yesterdays discussion, I need to
deploy Resoruce first and then the EJB
So I tried to deploy connector rar file first and then
my EJB which would have refrence to this, but then I
get error as below (Error#1) when trying to deploy
connector
I was under the impression that plans are created on
the fly and users does not have to do anything much
for that. Is there any thing I need to do before I can
deploy this connector ? (The connector is standard
J2EE 1.4 connector)
I looked at the docs and found that there was
requirement to create geronimo-ra.xml file before one
can deploy connectors. I think this requirement has
been removed (after watching up some of the deployment
related messages). But still I created geronimo-ra.xml
and put it into the Connector rar file. After doing
this I get different error (as per error#2)
Next thing I tried was to combine connector rar and my
EJB's JAR file into a EAR file and try to deploy that
EAR file. I also created application.xml file for this
purpose, but again during deployment I got error#2.
Command that I used to start Geronimo Server:
# java -jar bin\server.jar
org/apache/geronimo/RuntimeDeployer
org/apache/geronimo/DebugConsole
Command that I used to do deployment:
# java -jar bin\deployer.jar deploy I:\TestEar.ear
I have a feeling that I am missing some crucial part
in entire deployment process and some how its either
not mention in the docs or I am looking at the wrong
docs.
----------------------------------------------------------------------
ERROR#1:
----------------------------------------------------------------------
Deployment failed
Server reports:
org.apache.geronimo.common.DeploymentException: A
connector module must be deployed using a plan
org.apache.geronimo.kernel.InternalKernelException:
org.apache.geronimo.common.DeploymentException: A
connector module must be
deployed using a plan
at
org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.java:232
)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(Distribute
Command.java:86)
at java.lang.Thread.run(Thread.java:534)
Caused by:
org.apache.geronimo.common.DeploymentException: A
connector
module must be deployed using a plan
at
org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.creat
-------------------------------------------------------------------------------------
Error #2:
-------------------------------------------------------------------------------------
Deployment failed
Server reports:
org.apache.geronimo.common.DeploymentException: Syntax
error i
n deployment plan or no deployer service available
(currently I can't tell the d
ifference):,
moduleFileC:\DOCUME~1\sghayal\LOCALS~1\Temp\deployer34036.tmpdir\JD
BCwhitebox-tx.rar
org.apache.geronimo.kernel.InternalKernelException:
org.apache.geronimo.common.D
eploymentException: Syntax error in deployment plan or
no deployer service avail
able (currently I can't tell the difference):,
moduleFileC:\DOCUME~1\sghayal\LOC
ALS~1\Temp\deployer34036.tmpdir\JDBCwhitebox-tx.rar
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)
-------------------------------------------------------------------------------
Thanks,
Sandip Ghayal
--- Sandip Ghayal <sg...@yahoo.com> wrote:
> I agree with point 1 and 2 completely.
>
> Thanks once again.
>
> Cheers,
>
> Sandip
> --- David Jencks <dj...@gluecode.com> 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 <dj...@gluecode.com> 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
Re: Some more deployment questions
Posted by Sandip Ghayal <sg...@yahoo.com>.
I agree with point 1 and 2 completely.
Thanks once again.
Cheers,
Sandip
--- David Jencks <dj...@gluecode.com> 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 <dj...@gluecode.com> 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
Re: Some more deployment questions
Posted by David Jencks <dj...@gluecode.com>.
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 <dj...@gluecode.com> 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
Posted by Sandip Ghayal <sg...@yahoo.com>.
Hi David,
Thanks for response David and sorry to bug you guys
with this issues.
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.
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.
Thanks,
Sandip
--- David Jencks <dj...@gluecode.com> 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
Posted by David Jencks <dj...@gluecode.com>.
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.
> 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.ModuleBuilder$$EnhancerByCGLIB$$9
> e45a280.addGBeans(<generated>)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfigurati
> on(EARConfigBuilder.java:346)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLI
> B$$38e56ec6.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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$
> $7a1ca0ae.buildConfiguration(<generated>)
> at
> org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:200)
> at
> org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:80)
> at
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i
> nvoke(<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:684)
> at
> org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:308)
> at
> org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:121)
> at
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.in
> voke(<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:684)
> at
> org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:308)
> at
> org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServer
> Delegate.java:117)
> at
> mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java
> :222)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at
> java.lang.reflect.Method.invoke(Method.java:324)
> at
> mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:36)
>
> at
> mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjec
> tInvoker.java:98)
> at
> mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionS
> ubjectInvoker.java:32)
> at
> mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjec
> tInvoker.java:89)
> at
> java.security.AccessController.doPrivileged(Native
> Method)
> at
> javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
> at
> mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:151)
> at
> mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnecti
> onSubjectInvoker.java:85)
> at
> mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubje
> ctInvoker.java:79)
> at $Proxy0.invoke(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImp
> l.java:224)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at
> java.lang.reflect.Method.invoke(Method.java:324)
> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at
> sun.rmi.transport.Transport$1.run(Transport.java:148)
> at
> java.security.AccessController.doPrivileged(Native
> Method)
> at
> sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4
> 60)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
> .java:701)
> ... 1 more
>
> Thanks,
>
> Sandip Ghayal
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>