Re: Some more deployment questions

David Jencks 28 Jan 2005 18:17:16 -0000


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 <[EMAIL PROTECTED]> wrote:
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
=== message truncated ===
                
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com

Re: Some more deployment questions

Reply via email to