You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Michael Allman <ms...@allman.ms> on 2006/01/08 13:20:38 UTC
deploying a resource adapter (fwd)
My question (below) didn't seem to make it to the list, so I'm resending
it. Apologies if this results in a duplicate.
---------- Forwarded message ----------
Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
From: Michael Allman <ms...@allman.ms>
To: user@geronimo.apache.org
Subject: deploying a resource adapter
Hello,
How do I configure several connection factories for a single (outbound)
resource adapter in Geronimo 1.0?
In JBoss 4, I copy a rar file into the "deploy" directory, and then I copy a
bunch of -ds.xml files into the same directory. Each -ds.xml references the
same rar file.
Thank you.
Michael
Re: deploying a resource adapter (fwd)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
> I think option 3 most closely approximates what I am doing with JBoss, but
> will it deploy three independent copies of the resource adapter archive?
> I'm developing said resource adapter, and when I rebuild it I would like
> to redeploy it once and have all the connection factories use the new
> archive.
>
> I've tried doing this with configurations that reference the configId of
> the resource adapter as the parentId. I only get a cryptic error message
> from the deployer.
I'm not sure you can do it with the parentId approach because we don't
have a notion of a RA deployment without any actual instances, so
there's nothing for the parent to hold.
If it was just the code that was going to change, you could put the RA
classes in a JAR in the repository and include it in the resource
adapter plans with an import element instead of packaging the JAR into
the RAR -- but then you'd need to restart Geronimo if you wanted to
switch to a newer JAR. And that still wouldn't help you if your
ra.xml changed.
It sounds like option 1 or 2 might be best, where you deploy all N
configurations as part of a single geronimo-ra.xml plan, and then when
your RAR is updated, you redeploy the new RAR with the same plan and
all N instances should update as part of the same operation.
David Jencks might have some more insight into this issue as well.
Aaron
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
On Mon, 9 Jan 2006, David Jencks wrote:
> no, in fact right now you can't deploy a separate plan and rar using the hot
> deployer, you would have to pack the plan into the rar. Personally I despise
> the hot deployer :-) but I will try to consider this anyway :-)
>
> <goes away and looks at the code>
>
> After looking at the hot deployer, I think we can make it deploy a plan that
> does not need to go with a j2ee artifact. There are 2 kinds of these, gbean
> plans and "synthetic ears" that include one or more ext-modules and no normal
> modules. If this works, you would be able to:
>
> -put the appropriately versioned rar in the geronimo repository
> -put your rar plan in a synthetic ear plan
> -copy the synthetic ear plan to the hot deploy dir (hot deployer will deploy
> it)
> -modify the rar in the geronimo repo (nothing will happen)
> -touch the synthetic ear plan in the hot deploy dir (hot deployer will
> redeploy it)
>
> Is this too much work?
Maybe not, but I want to deploy the resource adapter once as a standalone
module to
1. save memory,
2. save threads (each resource adapter instance creates a Timer instance
for administrative purposes).
Also, this is how I'm testing it on other app servers and I don't want to
maintain two deployment strategies.
So my wish is that, sometime in the future, geronimo supports
1. deployment and redeployment of a resource adapter as a standalone
module without any outbound connection factories defined,
2. the ability to deploy and undeploy outbound connection factories for a
deployed standalone resource adapter independently of each other.
If you agree that this is worthwhile functionality, I'd be interested in
helping flesh out the requirements, the design, and the implementation as
desired and as time permits.
I'll take back my request that geronimo be able to deploy any 1.5
compliant rar file without a deployment plan. In some cases this is an
unreasonable expectation. On deployment, the app server needs to
configure and start an instance of the resource adapter class, and it
can't do that if there are ra configuration properties with undefined
values. When default values are provided, I would suggest the app server
can and should use those. That's what JBoss does, and that's why I can
deploy my rar file to JBoss without a JBoss-specific descriptor. If I try
to deploy without default config property values, I get a deployment
error.
> Now let me complain about the hot deployer :-) What I don't like about it is
> that it doesn't integrate very will with automated builds. You can have your
> automated build copy an artifact into the hot deploy dir, but there is no way
> to determine that the deployment is complete or error-free, so effectively
> your build script has to have the copy as its last step. I prefer solutions
> where the build script does something that positively tells it whether the
> deployment worked. At the moment we have 2 ways to do this easily with maven
> 1 and one way to do it with a command line tool.
>
> command line: call the deployer java -jar bin/deployer.jar --user system
> --password manager deploy myrar.rar myplan.xml
>
> deploy to a running server using the maven deploy plugin, using something
> like this:
> <deploy:distribute
> uri="deployer:geronimo:jmx"
> username="system"
> password="manager"
> module="${maven.build.dir}/openejb-itests-$
> {pom.currentVersion}.jar" />
> <deploy:start
> uri="deployer:geronimo:jmx"
> username="system"
> password="manager"
> id="openejb/itests/${openejb_version}/car"/>
> With this method, I usually have some other maven scripting that use the
> deploy plugin to unpack and start a geronimo server in the same module. I
> think this is the easiest way to set up integration tests.
>
>
> build a server that includes your application: have one or more config
> modules similar to the configs/ in the geronimo build, and assemble a server
> with just the stuff you need, similar to an assembly/ in the geronimo build.
>
> The last approach is not really as easy as it should be yet. We are working
> on making it easier and more flexible.
>
> What do you think?
I prefer a deployment directory because it's easy to manage, but I don't
mind using a command line tool or an ant task. I'm used to manually
deploying stuff anyway.
Michael
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
On Jan 9, 2006, at 11:38 AM, David Jencks wrote:
>
> On Jan 9, 2006, at 4:15 AM, Michael Allman wrote:
>
>> On Mon, 9 Jan 2006, David Jencks wrote:
>>
>>>
>>> <snip>
>>>
>>>>>> I started looking into the daytrader app you mentioned. I
>>>>>> think I found its deployed instance in config-store/28, but it
>>>>>> looks like it bundles the activemq and tranql resource
>>>>>> adapters under the TradeDataSource and TradeJMS
>>>>>> subdirectories, respectively. Are you saying they don't need
>>>>>> to be there, that they could be referenced from the daytrader
>>>>>> app somehow?
>>>>> They are added by the configuration building process, the
>>>>> simplification is that you don't need to include the rars in
>>>>> your ear yourself. We are thinking about a way to make it so
>>>>> deploying a j2ee artifact does not copy any of it into the
>>>>> configuration but refers to it in some form in the repository,
>>>>> but this will require at least a new classloader and perhaps
>>>>> unpacking the nested jars into a flat structure.
>>>> I'm trying to get away from using JBoss because their software
>>>> is buggy and they're a pain in the ass, but their resource
>>>> adapter deployment and configuration is easier and more flexible
>>>> than what Geronimo currently offers. Aside from the issue of
>>>> being able to share a single rar among multiple applications, I
>>>> can also deploy a rar file to JBoss without any kind of JBoss-
>>>> specific configuration. (I understand said resource adapter is
>>>> useless without further configuration --- it's the principle
>>>> that I don't have to build multiple rar archives, one for each
>>>> app server implementation, that matters to me.)
>>>
>>> I think there's a communication problem here, but I'm not sure
>>> exactly what or where it is. I hope I can get you to explain
>>> what you mean in a way I can understand more easily.
>>> Unfortunately I don't remember all the details of how I wrote the
>>> jboss connector stuff, and they might have changed it somewhat in
>>> the last couple years, but... what do you mean by deploying a rar
>>> file without a plan? it seems to me that all that is possible is
>>> to get the classes into a classloader that can be referenced
>>> somehow. If you want a usable instance, you need a vendor plan
>>> and a reference to the ra.xml in the rar and some classloader
>>> with the classes in it.
>>
>> "A rar file without a plan" == a rar file packaged as required by
>> the J2EE connector spec and without any app server specific
>> configuration. I can take one of these and deploy it on a JBoss 4
>> instance by plopping it into one of the deploy directories. Like
>> I said, it needs further configuration to define actual connection
>> factory instances, but these can be added and modified ad hoc
>> without redeploying the rar file.
>>
>>> In geronimo, you do roughly the same thing. There are a couple
>>> ways to make the deployment happen, and which you choose depends
>>> a lot on whether you are trying to put together a special purpose
>>> server for your app or viewing geronimo as something you can't
>>> change and just want to deploy your app on. If you are trying to
>>> build a server or want to be able to distribute your deployed
>>> application, you should use the packaging plugin to build a
>>> configuration from the rar and your plan. (soon there will be a
>>> offline deployer to let you do this without needing maven). You
>>> can then assemble a server including the .car file generated. If
>>> you want to regard geronimo as immutable, you can use the online
>>> deployer, again with the rar file and your plan. I don't see the
>>> difference between putting the rar file in the maven repo or the
>>> geronimo repo (geronimo) or "deploying" it without a plan on jboss.
>>>
>>> If you build the car file, you will be able to include it in any
>>> geronimo server you want: it includes all its classes and is
>>> "predeployed". (the tool support for adding it to an existing
>>> server is not too good yet).
>>>
>>>
>>> I'm not familiar with Geronimo's deployment strategy, but it
>>> sounds like each deployment module gets its own classloader.
>>> Rather than copy dependencies, couldn't they be referenced via
>>> classloader delegation or a similar mechanism?
>>>
>>>
>>> We would like to come up with a way to avoid copying all the
>>> classes into a car file, but as I mentioned this will take some
>>> classloader tricks. However, I'm not sure how this affects a
>>> user. The copying is done by geronimo during deployment. As
>>> long as you only need to start with one copy of the rar, why do
>>> you care how many times geronimo copies it?
>>
>> Will the deployer transparently update all the copies if I
>> redeploy the rar file?
>
> no, in fact right now you can't deploy a separate plan and rar
> using the hot deployer, you would have to pack the plan into the
> rar. Personally I despise the hot deployer :-) but I will try to
> consider this anyway :-)
>
> <goes away and looks at the code>
>
> After looking at the hot deployer, I think we can make it deploy a
> plan that does not need to go with a j2ee artifact. There are 2
> kinds of these, gbean plans and "synthetic ears" that include one
> or more ext-modules and no normal modules. If this works, you
> would be able to:
>
> -put the appropriately versioned rar in the geronimo repository
> -put your rar plan in a synthetic ear plan
> -copy the synthetic ear plan to the hot deploy dir (hot deployer
> will deploy it)
> -modify the rar in the geronimo repo (nothing will happen)
> -touch the synthetic ear plan in the hot deploy dir (hot deployer
> will redeploy it)
>
> Is this too much work?
I've implemented this in geronimo head. I don't know if there are
any working nightly builds so you would probably have to build a copy
of geronimo for yourself.
thanks
david jencks
>
> Now let me complain about the hot deployer :-) What I don't like
> about it is that it doesn't integrate very will with automated
> builds. You can have your automated build copy an artifact into
> the hot deploy dir, but there is no way to determine that the
> deployment is complete or error-free, so effectively your build
> script has to have the copy as its last step. I prefer solutions
> where the build script does something that positively tells it
> whether the deployment worked. At the moment we have 2 ways to do
> this easily with maven 1 and one way to do it with a command line
> tool.
>
> command line: call the deployer java -jar bin/deployer.jar --user
> system --password manager deploy myrar.rar myplan.xml
>
> deploy to a running server using the maven deploy plugin, using
> something like this:
> <deploy:distribute
> uri="deployer:geronimo:jmx"
> username="system"
> password="manager"
> module="${maven.build.dir}/openejb-itests-$
> {pom.currentVersion}.jar" />
> <deploy:start
> uri="deployer:geronimo:jmx"
> username="system"
> password="manager"
> id="openejb/itests/${openejb_version}/car"/>
> With this method, I usually have some other maven scripting that
> use the deploy plugin to unpack and start a geronimo server in the
> same module. I think this is the easiest way to set up integration
> tests.
>
>
> build a server that includes your application: have one or more
> config modules similar to the configs/ in the geronimo build, and
> assemble a server with just the stuff you need, similar to an
> assembly/ in the geronimo build.
>
> The last approach is not really as easy as it should be yet. We
> are working on making it easier and more flexible.
>
> What do you think?
>
> thanks
> david jencks
>
>
>
>>
>> Thanks.
>>
>> Michael
>
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
On Jan 9, 2006, at 4:15 AM, Michael Allman wrote:
> On Mon, 9 Jan 2006, David Jencks wrote:
>
>>
>> <snip>
>>
>>>>> I started looking into the daytrader app you mentioned. I
>>>>> think I found its deployed instance in config-store/28, but it
>>>>> looks like it bundles the activemq and tranql resource adapters
>>>>> under the TradeDataSource and TradeJMS subdirectories,
>>>>> respectively. Are you saying they don't need to be there, that
>>>>> they could be referenced from the daytrader app somehow?
>>>> They are added by the configuration building process, the
>>>> simplification is that you don't need to include the rars in
>>>> your ear yourself. We are thinking about a way to make it so
>>>> deploying a j2ee artifact does not copy any of it into the
>>>> configuration but refers to it in some form in the repository,
>>>> but this will require at least a new classloader and perhaps
>>>> unpacking the nested jars into a flat structure.
>>> I'm trying to get away from using JBoss because their software is
>>> buggy and they're a pain in the ass, but their resource adapter
>>> deployment and configuration is easier and more flexible than
>>> what Geronimo currently offers. Aside from the issue of being
>>> able to share a single rar among multiple applications, I can
>>> also deploy a rar file to JBoss without any kind of JBoss-
>>> specific configuration. (I understand said resource adapter is
>>> useless without further configuration --- it's the principle that
>>> I don't have to build multiple rar archives, one for each app
>>> server implementation, that matters to me.)
>>
>> I think there's a communication problem here, but I'm not sure
>> exactly what or where it is. I hope I can get you to explain what
>> you mean in a way I can understand more easily. Unfortunately I
>> don't remember all the details of how I wrote the jboss connector
>> stuff, and they might have changed it somewhat in the last couple
>> years, but... what do you mean by deploying a rar file without a
>> plan? it seems to me that all that is possible is to get the
>> classes into a classloader that can be referenced somehow. If you
>> want a usable instance, you need a vendor plan and a reference to
>> the ra.xml in the rar and some classloader with the classes in it.
>
> "A rar file without a plan" == a rar file packaged as required by
> the J2EE connector spec and without any app server specific
> configuration. I can take one of these and deploy it on a JBoss 4
> instance by plopping it into one of the deploy directories. Like I
> said, it needs further configuration to define actual connection
> factory instances, but these can be added and modified ad hoc
> without redeploying the rar file.
>
>> In geronimo, you do roughly the same thing. There are a couple
>> ways to make the deployment happen, and which you choose depends a
>> lot on whether you are trying to put together a special purpose
>> server for your app or viewing geronimo as something you can't
>> change and just want to deploy your app on. If you are trying to
>> build a server or want to be able to distribute your deployed
>> application, you should use the packaging plugin to build a
>> configuration from the rar and your plan. (soon there will be a
>> offline deployer to let you do this without needing maven). You
>> can then assemble a server including the .car file generated. If
>> you want to regard geronimo as immutable, you can use the online
>> deployer, again with the rar file and your plan. I don't see the
>> difference between putting the rar file in the maven repo or the
>> geronimo repo (geronimo) or "deploying" it without a plan on jboss.
>>
>> If you build the car file, you will be able to include it in any
>> geronimo server you want: it includes all its classes and is
>> "predeployed". (the tool support for adding it to an existing
>> server is not too good yet).
>>
>>
>> I'm not familiar with Geronimo's deployment strategy, but it
>> sounds like each deployment module gets its own classloader.
>> Rather than copy dependencies, couldn't they be referenced via
>> classloader delegation or a similar mechanism?
>>
>>
>> We would like to come up with a way to avoid copying all the
>> classes into a car file, but as I mentioned this will take some
>> classloader tricks. However, I'm not sure how this affects a
>> user. The copying is done by geronimo during deployment. As long
>> as you only need to start with one copy of the rar, why do you
>> care how many times geronimo copies it?
>
> Will the deployer transparently update all the copies if I redeploy
> the rar file?
no, in fact right now you can't deploy a separate plan and rar using
the hot deployer, you would have to pack the plan into the rar.
Personally I despise the hot deployer :-) but I will try to consider
this anyway :-)
<goes away and looks at the code>
After looking at the hot deployer, I think we can make it deploy a
plan that does not need to go with a j2ee artifact. There are 2
kinds of these, gbean plans and "synthetic ears" that include one or
more ext-modules and no normal modules. If this works, you would be
able to:
-put the appropriately versioned rar in the geronimo repository
-put your rar plan in a synthetic ear plan
-copy the synthetic ear plan to the hot deploy dir (hot deployer will
deploy it)
-modify the rar in the geronimo repo (nothing will happen)
-touch the synthetic ear plan in the hot deploy dir (hot deployer
will redeploy it)
Is this too much work?
Now let me complain about the hot deployer :-) What I don't like
about it is that it doesn't integrate very will with automated
builds. You can have your automated build copy an artifact into the
hot deploy dir, but there is no way to determine that the deployment
is complete or error-free, so effectively your build script has to
have the copy as its last step. I prefer solutions where the build
script does something that positively tells it whether the deployment
worked. At the moment we have 2 ways to do this easily with maven 1
and one way to do it with a command line tool.
command line: call the deployer java -jar bin/deployer.jar --user
system --password manager deploy myrar.rar myplan.xml
deploy to a running server using the maven deploy plugin, using
something like this:
<deploy:distribute
uri="deployer:geronimo:jmx"
username="system"
password="manager"
module="${maven.build.dir}/openejb-itests-$
{pom.currentVersion}.jar" />
<deploy:start
uri="deployer:geronimo:jmx"
username="system"
password="manager"
id="openejb/itests/${openejb_version}/car"/>
With this method, I usually have some other maven scripting that use
the deploy plugin to unpack and start a geronimo server in the same
module. I think this is the easiest way to set up integration tests.
build a server that includes your application: have one or more
config modules similar to the configs/ in the geronimo build, and
assemble a server with just the stuff you need, similar to an
assembly/ in the geronimo build.
The last approach is not really as easy as it should be yet. We are
working on making it easier and more flexible.
What do you think?
thanks
david jencks
>
> Thanks.
>
> Michael
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
On Mon, 9 Jan 2006, David Jencks wrote:
>>>>
>
> <snip>
>
>>>> I started looking into the daytrader app you mentioned. I think I found
>>>> its deployed instance in config-store/28, but it looks like it bundles
>>>> the activemq and tranql resource adapters under the TradeDataSource and
>>>> TradeJMS subdirectories, respectively. Are you saying they don't need to
>>>> be there, that they could be referenced from the daytrader app somehow?
>>>
>>> They are added by the configuration building process, the simplification
>>> is that you don't need to include the rars in your ear yourself. We are
>>> thinking about a way to make it so deploying a j2ee artifact does not copy
>>> any of it into the configuration but refers to it in some form in the
>>> repository, but this will require at least a new classloader and perhaps
>>> unpacking the nested jars into a flat structure.
>>
>> I'm trying to get away from using JBoss because their software is buggy and
>> they're a pain in the ass, but their resource adapter deployment and
>> configuration is easier and more flexible than what Geronimo currently
>> offers. Aside from the issue of being able to share a single rar among
>> multiple applications, I can also deploy a rar file to JBoss without any
>> kind of JBoss-specific configuration. (I understand said resource adapter
>> is useless without further configuration --- it's the principle that I
>> don't have to build multiple rar archives, one for each app server
>> implementation, that matters to me.)
>
> I think there's a communication problem here, but I'm not sure exactly what
> or where it is. I hope I can get you to explain what you mean in a way I can
> understand more easily. Unfortunately I don't remember all the details of
> how I wrote the jboss connector stuff, and they might have changed it
> somewhat in the last couple years, but... what do you mean by deploying a rar
> file without a plan? it seems to me that all that is possible is to get the
> classes into a classloader that can be referenced somehow. If you want a
> usable instance, you need a vendor plan and a reference to the ra.xml in the
> rar and some classloader with the classes in it.
"A rar file without a plan" == a rar file packaged as required by the J2EE
connector spec and without any app server specific configuration. I can
take one of these and deploy it on a JBoss 4 instance by plopping it into
one of the deploy directories. Like I said, it needs further
configuration to define actual connection factory instances, but these can
be added and modified ad hoc without redeploying the rar file.
> In geronimo, you do roughly the same thing. There are a couple ways to make
> the deployment happen, and which you choose depends a lot on whether you are
> trying to put together a special purpose server for your app or viewing
> geronimo as something you can't change and just want to deploy your app on.
> If you are trying to build a server or want to be able to distribute your
> deployed application, you should use the packaging plugin to build a
> configuration from the rar and your plan. (soon there will be a offline
> deployer to let you do this without needing maven). You can then assemble a
> server including the .car file generated. If you want to regard geronimo as
> immutable, you can use the online deployer, again with the rar file and your
> plan. I don't see the difference between putting the rar file in the maven
> repo or the geronimo repo (geronimo) or "deploying" it without a plan on
> jboss.
>
> If you build the car file, you will be able to include it in any geronimo
> server you want: it includes all its classes and is "predeployed". (the tool
> support for adding it to an existing server is not too good yet).
>
>
> I'm not familiar with Geronimo's deployment strategy, but it sounds like each
> deployment module gets its own classloader. Rather than copy dependencies,
> couldn't they be referenced via classloader delegation or a similar
> mechanism?
>
>
> We would like to come up with a way to avoid copying all the classes into a
> car file, but as I mentioned this will take some classloader tricks.
> However, I'm not sure how this affects a user. The copying is done by
> geronimo during deployment. As long as you only need to start with one copy
> of the rar, why do you care how many times geronimo copies it?
Will the deployer transparently update all the copies if I redeploy the
rar file?
Thanks.
Michael
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
>>>
<snip>
>>> I started looking into the daytrader app you mentioned. I think
>>> I found its deployed instance in config-store/28, but it looks
>>> like it bundles the activemq and tranql resource adapters under
>>> the TradeDataSource and TradeJMS subdirectories, respectively.
>>> Are you saying they don't need to be there, that they could be
>>> referenced from the daytrader app somehow?
>>
>> They are added by the configuration building process, the
>> simplification is that you don't need to include the rars in your
>> ear yourself. We are thinking about a way to make it so deploying
>> a j2ee artifact does not copy any of it into the configuration but
>> refers to it in some form in the repository, but this will require
>> at least a new classloader and perhaps unpacking the nested jars
>> into a flat structure.
>
> I'm trying to get away from using JBoss because their software is
> buggy and they're a pain in the ass, but their resource adapter
> deployment and configuration is easier and more flexible than what
> Geronimo currently offers. Aside from the issue of being able to
> share a single rar among multiple applications, I can also deploy a
> rar file to JBoss without any kind of JBoss-specific
> configuration. (I understand said resource adapter is useless
> without further configuration --- it's the principle that I don't
> have to build multiple rar archives, one for each app server
> implementation, that matters to me.)
I think there's a communication problem here, but I'm not sure
exactly what or where it is. I hope I can get you to explain what
you mean in a way I can understand more easily. Unfortunately I
don't remember all the details of how I wrote the jboss connector
stuff, and they might have changed it somewhat in the last couple
years, but... what do you mean by deploying a rar file without a
plan? it seems to me that all that is possible is to get the classes
into a classloader that can be referenced somehow. If you want a
usable instance, you need a vendor plan and a reference to the ra.xml
in the rar and some classloader with the classes in it.
In geronimo, you do roughly the same thing. There are a couple ways
to make the deployment happen, and which you choose depends a lot on
whether you are trying to put together a special purpose server for
your app or viewing geronimo as something you can't change and just
want to deploy your app on. If you are trying to build a server or
want to be able to distribute your deployed application, you should
use the packaging plugin to build a configuration from the rar and
your plan. (soon there will be a offline deployer to let you do this
without needing maven). You can then assemble a server including
the .car file generated. If you want to regard geronimo as
immutable, you can use the online deployer, again with the rar file
and your plan. I don't see the difference between putting the rar
file in the maven repo or the geronimo repo (geronimo) or "deploying"
it without a plan on jboss.
If you build the car file, you will be able to include it in any
geronimo server you want: it includes all its classes and is
"predeployed". (the tool support for adding it to an existing server
is not too good yet).
I'm not familiar with Geronimo's deployment strategy, but it sounds
like each deployment module gets its own classloader. Rather than
copy dependencies, couldn't they be referenced via classloader
delegation or a similar mechanism?
We would like to come up with a way to avoid copying all the classes
into a car file, but as I mentioned this will take some classloader
tricks. However, I'm not sure how this affects a user. The copying
is done by geronimo during deployment. As long as you only need to
start with one copy of the rar, why do you care how many times
geronimo copies it?
thanks
david jencks
(looks like I confused the quoting in my mail program, sorry)
<snip>
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
On Sun, 8 Jan 2006, David Jencks wrote:
>
> On Jan 8, 2006, at 9:12 PM, Michael Allman wrote:
>
>> On Sun, 8 Jan 2006, David Jencks wrote:
>>
>>>
>>> On Jan 8, 2006, at 8:12 PM, Michael Allman wrote:
>>>
>>>> On Sun, 8 Jan 2006, David Jencks wrote:
>>>>> On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
>>>>>> I'm developing said resource adapter, and when I rebuild it I would
>>>>>> like to redeploy it once and have all the connection factories use the
>>>>>> new archive.
>>>>>> I've tried doing this with configurations that reference the configId
>>>>>> of the resource adapter as the parentId. I only get a cryptic error
>>>>>> message from the deployer.
>>>>> that ought to work, I've done it with a chain of about 6 resource
>>>>> adapters that share classes. However I think option 1 will be by far
>>>>> the most convenient for you.
>>>> Option 1 is not really a workable option for me because the connection
>>>> definitions support unrelated applications. I want to keep them in
>>>> separate files in separate projects.
>>>> I'm attaching a couple of deployment plans. The resource adapter I'm
>>>> deploying is for Sleepycat Software's Berkeley DB XML and can be found at
>>>> http://berkeley-dbxml-adapter.dev.java.net/.
>>>> The file "dbxml-ra.xml" is supposed to be the "minimal configuration"
>>>> plan I deploy with the resource adapter archive itself. The file
>>>> "dbxmltest-env1.xml" is one of the connection definition configurations.
>>>> It is my intention that it reference the resource adapter instance
>>>> deployed with the "dbxml-ra.xml" plan. So I do
>>>> java -jar bin/deployer.jar berkeley-dbxml.rar dbxml-ra.xml
>>>> and that works. Then I do
>>>> java -jar bin/deployer.jar dbxmltest-env1.xml
>>>> and that fails with
>>>> Error: Unable to distribute dbxmltest-env1.xml: Cannot deploy the
>>>> requested application module
>>>> (planFile=dbxmltest-env1.xml)
>>>> What am I doing wrong?
>>>
>>> I pretty much completely misunderstood what you were trying to do. To
>>> deploy a j2ee artifact you always need both the j2ee artifact and (for a
>>> connector anyway) the plan. So (except for the trick explained below) you
>>> need to follow (3) exactly as stated.
>>>
>>> What I had was a situation where one application used 6 different resource
>>> adapters that happened to have identical class jars inside, and where I
>>> needed to end up with only one copy of each class in the application. In
>>> order to do that I had to make a chain of the 6 resource adapters so only
>>> the classes from the first were actually used, even though there were
>>> separate classloaders for each rar.
>>>
>>> One trick we have that you might find useful is the ability to add modules
>>> to an ear plan, even though the module is not included in the ear itself.
>>> In fact you can make a "virtual ear" entirely out of external modules.
>>> That way you can get the db plan in with the rest of your app without
>>> physically including the rar in your ear. Some examples are the daytrader
>>> configs (starting with an ear) and the uddi-server configs (starting with
>>> just a war and creating a "virtual ear")
>>
>> I started looking into the daytrader app you mentioned. I think I found
>> its deployed instance in config-store/28, but it looks like it bundles the
>> activemq and tranql resource adapters under the TradeDataSource and
>> TradeJMS subdirectories, respectively. Are you saying they don't need to
>> be there, that they could be referenced from the daytrader app somehow?
>
> They are added by the configuration building process, the simplification is
> that you don't need to include the rars in your ear yourself. We are
> thinking about a way to make it so deploying a j2ee artifact does not copy
> any of it into the configuration but refers to it in some form in the
> repository, but this will require at least a new classloader and perhaps
> unpacking the nested jars into a flat structure.
I'm trying to get away from using JBoss because their software is buggy
and they're a pain in the ass, but their resource adapter deployment and
configuration is easier and more flexible than what Geronimo currently
offers. Aside from the issue of being able to share a single rar among
multiple applications, I can also deploy a rar file to JBoss without any
kind of JBoss-specific configuration. (I understand said resource adapter
is useless without further configuration --- it's the principle that I
don't have to build multiple rar archives, one for each app server
implementation, that matters to me.)
I'm not familiar with Geronimo's deployment strategy, but it sounds like
each deployment module gets its own classloader. Rather than copy
dependencies, couldn't they be referenced via classloader delegation or a
similar mechanism?
Michael
>>
>> I couldn't find the ear deployment plan either. Is that recoverable from
>> config.ser somehow, or am I looking in the wrong place?
>
> configs/daytrader-jetty/src/plan/plan.xml Note that dependencies and parents
> (imports) are from the marked dependencies in project.xml. I would rather
> project.xml was derived from the plan, but I don't think that will ever be
> possible :-) and it is certainly IMO better to have the dependencies listed
> in only one place.
>
> thanks
> david jencks
>>
>> Thank you.
>>
>> Michael
>>
>>> thanks
>>> david jencks
>>>
>>>> Thank you.
>>>> Michael
>>>>> thanks
>>>>> david jencks
>>>>>> Michael
>>>>>> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>>>>>>> I believe there are 3 ways you could do this:
>>>>>>> 1) Create a single geronimo-ra.xml with more than one resourceadapter
>>>>>>> entry in it, each of which defines a separate Geronimo configuration
>>>>>>> (including a separate outbound connection factory)
>>>>>>> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
>>>>>>> containing one outbound-resourceadapter, containing one
>>>>>>> connection-definition, containing multiple
>>>>>>> connectiondefinition-instance elements (each for a separate database
>>>>>>> or whatever the resource adapter connects to)
>>>>>>> 3) Create multiple geronimo-ra.xml files and deploy them each
>>>>>>> separately:
>>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>>>>>>> ...
>>>>>>> Of the three approaches, I think the last is the best in that you can
>>>>>>> start and stop and manage each of the configurations independently.
>>>>>>> However the first two let you combine your configurations into one
>>>>>>> deployment unit if you'd prefer to manage them all together (and would
>>>>>>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>>>>>>> prefer to).
>>>>>>> Thanks,
>>>>>>> Aaron
>>>>>>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>>>>>>> My question (below) didn't seem to make it to the list, so I'm
>>>>>>>> resending
>>>>>>>> it. Apologies if this results in a duplicate.
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>>>>>>> From: Michael Allman <ms...@allman.ms>
>>>>>>>> To: user@geronimo.apache.org
>>>>>>>> Subject: deploying a resource adapter
>>>>>>>> Hello,
>>>>>>>> How do I configure several connection factories for a single
>>>>>>>> (outbound)
>>>>>>>> resource adapter in Geronimo 1.0?
>>>>>>>> In JBoss 4, I copy a rar file into the "deploy" directory, and then I
>>>>>>>> copy a
>>>>>>>> bunch of -ds.xml files into the same directory. Each -ds.xml
>>>>>>>> references the
>>>>>>>> same rar file.
>>>>>>>> Thank you.
>>>>>>>> Michael
>>>
>
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
On Jan 8, 2006, at 9:12 PM, Michael Allman wrote:
> On Sun, 8 Jan 2006, David Jencks wrote:
>
>>
>> On Jan 8, 2006, at 8:12 PM, Michael Allman wrote:
>>
>>> On Sun, 8 Jan 2006, David Jencks wrote:
>>>> On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
>>>>> I'm developing said resource adapter, and when I rebuild it I
>>>>> would like to redeploy it once and have all the connection
>>>>> factories use the new archive.
>>>>> I've tried doing this with configurations that reference the
>>>>> configId of the resource adapter as the parentId. I only get a
>>>>> cryptic error message from the deployer.
>>>> that ought to work, I've done it with a chain of about 6
>>>> resource adapters that share classes. However I think option 1
>>>> will be by far the most convenient for you.
>>> Option 1 is not really a workable option for me because the
>>> connection definitions support unrelated applications. I want to
>>> keep them in separate files in separate projects.
>>> I'm attaching a couple of deployment plans. The resource adapter
>>> I'm deploying is for Sleepycat Software's Berkeley DB XML and can
>>> be found at http://berkeley-dbxml-adapter.dev.java.net/.
>>> The file "dbxml-ra.xml" is supposed to be the "minimal
>>> configuration" plan I deploy with the resource adapter archive
>>> itself. The file "dbxmltest-env1.xml" is one of the connection
>>> definition configurations. It is my intention that it reference
>>> the resource adapter instance deployed with the "dbxml-ra.xml"
>>> plan. So I do
>>> java -jar bin/deployer.jar berkeley-dbxml.rar dbxml-ra.xml
>>> and that works. Then I do
>>> java -jar bin/deployer.jar dbxmltest-env1.xml
>>> and that fails with
>>> Error: Unable to distribute dbxmltest-env1.xml: Cannot deploy the
>>> requested application module
>>> (planFile=dbxmltest-env1.xml)
>>> What am I doing wrong?
>>
>> I pretty much completely misunderstood what you were trying to do.
>> To deploy a j2ee artifact you always need both the j2ee artifact
>> and (for a connector anyway) the plan. So (except for the trick
>> explained below) you need to follow (3) exactly as stated.
>>
>> What I had was a situation where one application used 6 different
>> resource adapters that happened to have identical class jars
>> inside, and where I needed to end up with only one copy of each
>> class in the application. In order to do that I had to make a
>> chain of the 6 resource adapters so only the classes from the
>> first were actually used, even though there were separate
>> classloaders for each rar.
>>
>> One trick we have that you might find useful is the ability to add
>> modules to an ear plan, even though the module is not included in
>> the ear itself. In fact you can make a "virtual ear" entirely out
>> of external modules. That way you can get the db plan in with the
>> rest of your app without physically including the rar in your
>> ear. Some examples are the daytrader configs (starting with an
>> ear) and the uddi-server configs (starting with just a war and
>> creating a "virtual ear")
>
> I started looking into the daytrader app you mentioned. I think I
> found its deployed instance in config-store/28, but it looks like
> it bundles the activemq and tranql resource adapters under the
> TradeDataSource and TradeJMS subdirectories, respectively. Are you
> saying they don't need to be there, that they could be referenced
> from the daytrader app somehow?
They are added by the configuration building process, the
simplification is that you don't need to include the rars in your ear
yourself. We are thinking about a way to make it so deploying a j2ee
artifact does not copy any of it into the configuration but refers to
it in some form in the repository, but this will require at least a
new classloader and perhaps unpacking the nested jars into a flat
structure.
>
> I couldn't find the ear deployment plan either. Is that
> recoverable from config.ser somehow, or am I looking in the wrong
> place?
configs/daytrader-jetty/src/plan/plan.xml Note that dependencies and
parents (imports) are from the marked dependencies in project.xml. I
would rather project.xml was derived from the plan, but I don't think
that will ever be possible :-) and it is certainly IMO better to have
the dependencies listed in only one place.
thanks
david jencks
>
> Thank you.
>
> Michael
>
>> thanks
>> david jencks
>>
>>> Thank you.
>>> Michael
>>>> thanks
>>>> david jencks
>>>>> Michael
>>>>> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>>>>>> I believe there are 3 ways you could do this:
>>>>>> 1) Create a single geronimo-ra.xml with more than one
>>>>>> resourceadapter
>>>>>> entry in it, each of which defines a separate Geronimo
>>>>>> configuration
>>>>>> (including a separate outbound connection factory)
>>>>>> 2) Create a single geronimo-ra.xml with one resourceadapter
>>>>>> entry,
>>>>>> containing one outbound-resourceadapter, containing one
>>>>>> connection-definition, containing multiple
>>>>>> connectiondefinition-instance elements (each for a separate
>>>>>> database
>>>>>> or whatever the resource adapter connects to)
>>>>>> 3) Create multiple geronimo-ra.xml files and deploy them each
>>>>>> separately:
>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>>>>>> ...
>>>>>> Of the three approaches, I think the last is the best in that
>>>>>> you can
>>>>>> start and stop and manage each of the configurations
>>>>>> independently.
>>>>>> However the first two let you combine your configurations into
>>>>>> one
>>>>>> deployment unit if you'd prefer to manage them all together
>>>>>> (and would
>>>>>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>>>>>> prefer to).
>>>>>> Thanks,
>>>>>> Aaron
>>>>>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>>>>>> My question (below) didn't seem to make it to the list, so
>>>>>>> I'm resending
>>>>>>> it. Apologies if this results in a duplicate.
>>>>>>> ---------- Forwarded message ----------
>>>>>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>>>>>> From: Michael Allman <ms...@allman.ms>
>>>>>>> To: user@geronimo.apache.org
>>>>>>> Subject: deploying a resource adapter
>>>>>>> Hello,
>>>>>>> How do I configure several connection factories for a single
>>>>>>> (outbound)
>>>>>>> resource adapter in Geronimo 1.0?
>>>>>>> In JBoss 4, I copy a rar file into the "deploy" directory,
>>>>>>> and then I copy a
>>>>>>> bunch of -ds.xml files into the same directory. Each -ds.xml
>>>>>>> references the
>>>>>>> same rar file.
>>>>>>> Thank you.
>>>>>>> Michael
>>
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
On Sun, 8 Jan 2006, David Jencks wrote:
>
> On Jan 8, 2006, at 8:12 PM, Michael Allman wrote:
>
>> On Sun, 8 Jan 2006, David Jencks wrote:
>>
>>>
>>> On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
>>>
>>>> I'm developing said resource adapter, and when I rebuild it I would like
>>>> to redeploy it once and have all the connection factories use the new
>>>> archive.
>>>> I've tried doing this with configurations that reference the configId of
>>>> the resource adapter as the parentId. I only get a cryptic error message
>>>> from the deployer.
>>>
>>> that ought to work, I've done it with a chain of about 6 resource adapters
>>> that share classes. However I think option 1 will be by far the most
>>> convenient for you.
>>
>> Option 1 is not really a workable option for me because the connection
>> definitions support unrelated applications. I want to keep them in
>> separate files in separate projects.
>>
>> I'm attaching a couple of deployment plans. The resource adapter I'm
>> deploying is for Sleepycat Software's Berkeley DB XML and can be found at
>> http://berkeley-dbxml-adapter.dev.java.net/.
>>
>> The file "dbxml-ra.xml" is supposed to be the "minimal configuration" plan
>> I deploy with the resource adapter archive itself. The file
>> "dbxmltest-env1.xml" is one of the connection definition configurations. It
>> is my intention that it reference the resource adapter instance deployed
>> with the "dbxml-ra.xml" plan. So I do
>>
>> java -jar bin/deployer.jar berkeley-dbxml.rar dbxml-ra.xml
>>
>> and that works. Then I do
>>
>> java -jar bin/deployer.jar dbxmltest-env1.xml
>>
>> and that fails with
>>
>> Error: Unable to distribute dbxmltest-env1.xml: Cannot deploy the
>> requested application module
>> (planFile=dbxmltest-env1.xml)
>>
>> What am I doing wrong?
>
> I pretty much completely misunderstood what you were trying to do. To deploy
> a j2ee artifact you always need both the j2ee artifact and (for a connector
> anyway) the plan. So (except for the trick explained below) you need to
> follow (3) exactly as stated.
>
> What I had was a situation where one application used 6 different resource
> adapters that happened to have identical class jars inside, and where I
> needed to end up with only one copy of each class in the application. In
> order to do that I had to make a chain of the 6 resource adapters so only the
> classes from the first were actually used, even though there were separate
> classloaders for each rar.
>
> One trick we have that you might find useful is the ability to add modules to
> an ear plan, even though the module is not included in the ear itself. In
> fact you can make a "virtual ear" entirely out of external modules. That way
> you can get the db plan in with the rest of your app without physically
> including the rar in your ear. Some examples are the daytrader configs
> (starting with an ear) and the uddi-server configs (starting with just a war
> and creating a "virtual ear")
I started looking into the daytrader app you mentioned. I think I found
its deployed instance in config-store/28, but it looks like it bundles the
activemq and tranql resource adapters under the TradeDataSource and
TradeJMS subdirectories, respectively. Are you saying they don't need to
be there, that they could be referenced from the daytrader app somehow?
I couldn't find the ear deployment plan either. Is that recoverable from
config.ser somehow, or am I looking in the wrong place?
Thank you.
Michael
> thanks
> david jencks
>
>>
>> Thank you.
>>
>> Michael
>>
>>> thanks
>>> david jencks
>>>
>>>> Michael
>>>> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>>>>> I believe there are 3 ways you could do this:
>>>>> 1) Create a single geronimo-ra.xml with more than one resourceadapter
>>>>> entry in it, each of which defines a separate Geronimo configuration
>>>>> (including a separate outbound connection factory)
>>>>> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
>>>>> containing one outbound-resourceadapter, containing one
>>>>> connection-definition, containing multiple
>>>>> connectiondefinition-instance elements (each for a separate database
>>>>> or whatever the resource adapter connects to)
>>>>> 3) Create multiple geronimo-ra.xml files and deploy them each
>>>>> separately:
>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>>>>> ...
>>>>> Of the three approaches, I think the last is the best in that you can
>>>>> start and stop and manage each of the configurations independently.
>>>>> However the first two let you combine your configurations into one
>>>>> deployment unit if you'd prefer to manage them all together (and would
>>>>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>>>>> prefer to).
>>>>> Thanks,
>>>>> Aaron
>>>>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>>>>> My question (below) didn't seem to make it to the list, so I'm
>>>>>> resending
>>>>>> it. Apologies if this results in a duplicate.
>>>>>> ---------- Forwarded message ----------
>>>>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>>>>> From: Michael Allman <ms...@allman.ms>
>>>>>> To: user@geronimo.apache.org
>>>>>> Subject: deploying a resource adapter
>>>>>> Hello,
>>>>>> How do I configure several connection factories for a single (outbound)
>>>>>> resource adapter in Geronimo 1.0?
>>>>>> In JBoss 4, I copy a rar file into the "deploy" directory, and then I
>>>>>> copy a
>>>>>> bunch of -ds.xml files into the same directory. Each -ds.xml
>>>>>> references the
>>>>>> same rar file.
>>>>>> Thank you.
>>>>>> Michael
>>>
>
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
On Jan 8, 2006, at 8:12 PM, Michael Allman wrote:
> On Sun, 8 Jan 2006, David Jencks wrote:
>
>>
>> On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
>>
>>> I'm developing said resource adapter, and when I rebuild it I
>>> would like to redeploy it once and have all the connection
>>> factories use the new archive.
>>> I've tried doing this with configurations that reference the
>>> configId of the resource adapter as the parentId. I only get a
>>> cryptic error message from the deployer.
>>
>> that ought to work, I've done it with a chain of about 6 resource
>> adapters that share classes. However I think option 1 will be by
>> far the most convenient for you.
>
> Option 1 is not really a workable option for me because the
> connection definitions support unrelated applications. I want to
> keep them in separate files in separate projects.
>
> I'm attaching a couple of deployment plans. The resource adapter
> I'm deploying is for Sleepycat Software's Berkeley DB XML and can
> be found at http://berkeley-dbxml-adapter.dev.java.net/.
>
> The file "dbxml-ra.xml" is supposed to be the "minimal
> configuration" plan I deploy with the resource adapter archive
> itself. The file "dbxmltest-env1.xml" is one of the connection
> definition configurations. It is my intention that it reference the
> resource adapter instance deployed with the "dbxml-ra.xml" plan.
> So I do
>
> java -jar bin/deployer.jar berkeley-dbxml.rar dbxml-ra.xml
>
> and that works. Then I do
>
> java -jar bin/deployer.jar dbxmltest-env1.xml
>
> and that fails with
>
> Error: Unable to distribute dbxmltest-env1.xml: Cannot deploy the
> requested application module
> (planFile=dbxmltest-env1.xml)
>
> What am I doing wrong?
I pretty much completely misunderstood what you were trying to do. To
deploy a j2ee artifact you always need both the j2ee artifact and
(for a connector anyway) the plan. So (except for the trick
explained below) you need to follow (3) exactly as stated.
What I had was a situation where one application used 6 different
resource adapters that happened to have identical class jars inside,
and where I needed to end up with only one copy of each class in the
application. In order to do that I had to make a chain of the 6
resource adapters so only the classes from the first were actually
used, even though there were separate classloaders for each rar.
One trick we have that you might find useful is the ability to add
modules to an ear plan, even though the module is not included in the
ear itself. In fact you can make a "virtual ear" entirely out of
external modules. That way you can get the db plan in with the rest
of your app without physically including the rar in your ear. Some
examples are the daytrader configs (starting with an ear) and the
uddi-server configs (starting with just a war and creating a "virtual
ear")
thanks
david jencks
>
> Thank you.
>
> Michael
>
>> thanks
>> david jencks
>>
>>> Michael
>>> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>>>> I believe there are 3 ways you could do this:
>>>> 1) Create a single geronimo-ra.xml with more than one
>>>> resourceadapter
>>>> entry in it, each of which defines a separate Geronimo
>>>> configuration
>>>> (including a separate outbound connection factory)
>>>> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
>>>> containing one outbound-resourceadapter, containing one
>>>> connection-definition, containing multiple
>>>> connectiondefinition-instance elements (each for a separate
>>>> database
>>>> or whatever the resource adapter connects to)
>>>> 3) Create multiple geronimo-ra.xml files and deploy them each
>>>> separately:
>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>>>> ...
>>>> Of the three approaches, I think the last is the best in that
>>>> you can
>>>> start and stop and manage each of the configurations independently.
>>>> However the first two let you combine your configurations into one
>>>> deployment unit if you'd prefer to manage them all together (and
>>>> would
>>>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>>>> prefer to).
>>>> Thanks,
>>>> Aaron
>>>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>>>> My question (below) didn't seem to make it to the list, so I'm
>>>>> resending
>>>>> it. Apologies if this results in a duplicate.
>>>>> ---------- Forwarded message ----------
>>>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>>>> From: Michael Allman <ms...@allman.ms>
>>>>> To: user@geronimo.apache.org
>>>>> Subject: deploying a resource adapter
>>>>> Hello,
>>>>> How do I configure several connection factories for a single
>>>>> (outbound)
>>>>> resource adapter in Geronimo 1.0?
>>>>> In JBoss 4, I copy a rar file into the "deploy" directory, and
>>>>> then I copy a
>>>>> bunch of -ds.xml files into the same directory. Each -ds.xml
>>>>> references the
>>>>> same rar file.
>>>>> Thank you.
>>>>> Michael
>>
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
On Sun, 8 Jan 2006, David Jencks wrote:
>
> On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
>
>> I'm developing said resource adapter, and when I rebuild it I would like to
>> redeploy it once and have all the connection factories use the new archive.
>>
>> I've tried doing this with configurations that reference the configId of
>> the resource adapter as the parentId. I only get a cryptic error message
>> from the deployer.
>
> that ought to work, I've done it with a chain of about 6 resource adapters
> that share classes. However I think option 1 will be by far the most
> convenient for you.
Option 1 is not really a workable option for me because the connection
definitions support unrelated applications. I want to keep them in
separate files in separate projects.
I'm attaching a couple of deployment plans. The resource adapter I'm
deploying is for Sleepycat Software's Berkeley DB XML and can be found at
http://berkeley-dbxml-adapter.dev.java.net/.
The file "dbxml-ra.xml" is supposed to be the "minimal configuration" plan
I deploy with the resource adapter archive itself. The file
"dbxmltest-env1.xml" is one of the connection definition configurations.
It is my intention that it reference the resource adapter instance
deployed with the "dbxml-ra.xml" plan. So I do
java -jar bin/deployer.jar berkeley-dbxml.rar dbxml-ra.xml
and that works. Then I do
java -jar bin/deployer.jar dbxmltest-env1.xml
and that fails with
Error: Unable to distribute dbxmltest-env1.xml: Cannot deploy the
requested application module
(planFile=dbxmltest-env1.xml)
What am I doing wrong?
Thank you.
Michael
> thanks
> david jencks
>
>>
>> Michael
>>
>> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>>
>>> I believe there are 3 ways you could do this:
>>>
>>> 1) Create a single geronimo-ra.xml with more than one resourceadapter
>>> entry in it, each of which defines a separate Geronimo configuration
>>> (including a separate outbound connection factory)
>>>
>>> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
>>> containing one outbound-resourceadapter, containing one
>>> connection-definition, containing multiple
>>> connectiondefinition-instance elements (each for a separate database
>>> or whatever the resource adapter connects to)
>>>
>>> 3) Create multiple geronimo-ra.xml files and deploy them each separately:
>>>
>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>>> ...
>>>
>>> Of the three approaches, I think the last is the best in that you can
>>> start and stop and manage each of the configurations independently.
>>> However the first two let you combine your configurations into one
>>> deployment unit if you'd prefer to manage them all together (and would
>>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>>> prefer to).
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>>> My question (below) didn't seem to make it to the list, so I'm resending
>>>> it. Apologies if this results in a duplicate.
>>>>
>>>> ---------- Forwarded message ----------
>>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>>> From: Michael Allman <ms...@allman.ms>
>>>> To: user@geronimo.apache.org
>>>> Subject: deploying a resource adapter
>>>>
>>>> Hello,
>>>>
>>>> How do I configure several connection factories for a single (outbound)
>>>> resource adapter in Geronimo 1.0?
>>>>
>>>> In JBoss 4, I copy a rar file into the "deploy" directory, and then I
>>>> copy a
>>>> bunch of -ds.xml files into the same directory. Each -ds.xml references
>>>> the
>>>> same rar file.
>>>>
>>>> Thank you.
>>>>
>>>> Michael
>>>>
>>>
>
Re: deploying a resource adapter (fwd)
Posted by David Jencks <da...@yahoo.com>.
On Jan 8, 2006, at 7:38 PM, Michael Allman wrote:
> I think option 3 most closely approximates what I am doing with
> JBoss, but will it deploy three independent copies of the resource
> adapter archive?
yes
> I'm developing said resource adapter, and when I rebuild it I would
> like to redeploy it once and have all the connection factories use
> the new archive.
>
> I've tried doing this with configurations that reference the
> configId of the resource adapter as the parentId. I only get a
> cryptic error message from the deployer.
that ought to work, I've done it with a chain of about 6 resource
adapters that share classes. However I think option 1 will be by far
the most convenient for you.
thanks
david jencks
>
> Michael
>
> On Sun, 8 Jan 2006, Aaron Mulder wrote:
>
>> I believe there are 3 ways you could do this:
>>
>> 1) Create a single geronimo-ra.xml with more than one resourceadapter
>> entry in it, each of which defines a separate Geronimo configuration
>> (including a separate outbound connection factory)
>>
>> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
>> containing one outbound-resourceadapter, containing one
>> connection-definition, containing multiple
>> connectiondefinition-instance elements (each for a separate database
>> or whatever the resource adapter connects to)
>>
>> 3) Create multiple geronimo-ra.xml files and deploy them each
>> separately:
>>
>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
>> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
>> ...
>>
>> Of the three approaches, I think the last is the best in that you can
>> start and stop and manage each of the configurations independently.
>> However the first two let you combine your configurations into one
>> deployment unit if you'd prefer to manage them all together (and
>> would
>> also let you pack the geronimo-ra.xml file into the RAR if you'd
>> prefer to).
>>
>> Thanks,
>> Aaron
>>
>> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>>> My question (below) didn't seem to make it to the list, so I'm
>>> resending
>>> it. Apologies if this results in a duplicate.
>>>
>>> ---------- Forwarded message ----------
>>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>>> From: Michael Allman <ms...@allman.ms>
>>> To: user@geronimo.apache.org
>>> Subject: deploying a resource adapter
>>>
>>> Hello,
>>>
>>> How do I configure several connection factories for a single
>>> (outbound)
>>> resource adapter in Geronimo 1.0?
>>>
>>> In JBoss 4, I copy a rar file into the "deploy" directory, and
>>> then I copy a
>>> bunch of -ds.xml files into the same directory. Each -ds.xml
>>> references the
>>> same rar file.
>>>
>>> Thank you.
>>>
>>> Michael
>>>
>>
Re: deploying a resource adapter (fwd)
Posted by Michael Allman <ms...@allman.ms>.
I think option 3 most closely approximates what I am doing with JBoss, but
will it deploy three independent copies of the resource adapter archive?
I'm developing said resource adapter, and when I rebuild it I would like
to redeploy it once and have all the connection factories use the new
archive.
I've tried doing this with configurations that reference the configId of
the resource adapter as the parentId. I only get a cryptic error message
from the deployer.
Michael
On Sun, 8 Jan 2006, Aaron Mulder wrote:
> I believe there are 3 ways you could do this:
>
> 1) Create a single geronimo-ra.xml with more than one resourceadapter
> entry in it, each of which defines a separate Geronimo configuration
> (including a separate outbound connection factory)
>
> 2) Create a single geronimo-ra.xml with one resourceadapter entry,
> containing one outbound-resourceadapter, containing one
> connection-definition, containing multiple
> connectiondefinition-instance elements (each for a separate database
> or whatever the resource adapter connects to)
>
> 3) Create multiple geronimo-ra.xml files and deploy them each separately:
>
> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
> java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
> ...
>
> Of the three approaches, I think the last is the best in that you can
> start and stop and manage each of the configurations independently.
> However the first two let you combine your configurations into one
> deployment unit if you'd prefer to manage them all together (and would
> also let you pack the geronimo-ra.xml file into the RAR if you'd
> prefer to).
>
> Thanks,
> Aaron
>
> On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
>> My question (below) didn't seem to make it to the list, so I'm resending
>> it. Apologies if this results in a duplicate.
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
>> From: Michael Allman <ms...@allman.ms>
>> To: user@geronimo.apache.org
>> Subject: deploying a resource adapter
>>
>> Hello,
>>
>> How do I configure several connection factories for a single (outbound)
>> resource adapter in Geronimo 1.0?
>>
>> In JBoss 4, I copy a rar file into the "deploy" directory, and then I copy a
>> bunch of -ds.xml files into the same directory. Each -ds.xml references the
>> same rar file.
>>
>> Thank you.
>>
>> Michael
>>
>
Re: deploying a resource adapter (fwd)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I believe there are 3 ways you could do this:
1) Create a single geronimo-ra.xml with more than one resourceadapter
entry in it, each of which defines a separate Geronimo configuration
(including a separate outbound connection factory)
2) Create a single geronimo-ra.xml with one resourceadapter entry,
containing one outbound-resourceadapter, containing one
connection-definition, containing multiple
connectiondefinition-instance elements (each for a separate database
or whatever the resource adapter connects to)
3) Create multiple geronimo-ra.xml files and deploy them each separately:
java -jar bin/deployer.jar deploy foo.rar geronimo-ra-1.xml
java -jar bin/deployer.jar deploy foo.rar geronimo-ra-2.xml
java -jar bin/deployer.jar deploy foo.rar geronimo-ra-3.xml
...
Of the three approaches, I think the last is the best in that you can
start and stop and manage each of the configurations independently.
However the first two let you combine your configurations into one
deployment unit if you'd prefer to manage them all together (and would
also let you pack the geronimo-ra.xml file into the RAR if you'd
prefer to).
Thanks,
Aaron
On 1/8/06, Michael Allman <ms...@allman.ms> wrote:
> My question (below) didn't seem to make it to the list, so I'm resending
> it. Apologies if this results in a duplicate.
>
> ---------- Forwarded message ----------
> Date: Sat, 7 Jan 2006 20:06:34 -0500 (EST)
> From: Michael Allman <ms...@allman.ms>
> To: user@geronimo.apache.org
> Subject: deploying a resource adapter
>
> Hello,
>
> How do I configure several connection factories for a single (outbound)
> resource adapter in Geronimo 1.0?
>
> In JBoss 4, I copy a rar file into the "deploy" directory, and then I copy a
> bunch of -ds.xml files into the same directory. Each -ds.xml references the
> same rar file.
>
> Thank you.
>
> Michael
>