Re: deploying a resource adapter (fwd)
snipI 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?thanksdavid jencks(looks like I confused the quoting in my mail program, sorry)snip
Re: deploying a resource adapter (fwd)
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.
Re: deploying a resource adapter (fwd)
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
Re: deploying a resource adapter (fwd)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: user@geronimo.apache.org Subject: deploying a resource adapter
Re: deploying a resource adapter (fwd)
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
Re: deploying a resource adapter (fwd)
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
