[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432835 ] Sachin Patel commented on GERONIMO-2324: Also, I've come to the realization that this support is only valuable if you have jars/projects that only provide runtime dependencies and not compile time dependencies and that your projects are configured NOT to have explicit references to these runtime dependencies. If you projects are set up to always have references to shared-lib projects and jars regardless of their dependency type (runtime/compile) then this support is reduntant and the support for running resources out of the workspace (GERONIMO-1526) will automatically provide this support. Please clarrify on you configuration specifically on wether or not your web apps reference all shared-lib projects and jars. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432637 ] David Jencks commented on GERONIMO-2324: [ Show » ] Sachin Patel [16/Aug/06 07:32 PM] Actually we need to re-open this for discussion. The dummy jar won't solve the classes dir and modifying the config will require a server restart. I don't think is reasonable. - Can't we put a directory entry in manifest classpath in addition to actual jars? This would make modifying the classes attribute unnecessary - If that doesn't work, the classes attribute can be changed while the server is running using the kernel reflection methods, e.g. kernel.setAttribute(sharedLibGBeanName, classes, newValue); This can be called remotely: see the jmx deployment stuff for an example of how. When you change an attribute through the kernel like this the new value gets saved in config.xml Therefore I think that using a dummy jar is still quite workable. [ Show » ] Oleg Gusakov [01/Sep/06 03:53 PM] SharedLib might not be an ideal solution as David quite reasonably indicated, but here is the use case: * I develop a WAR project under Eclipse * this project depends on 15 Eclipse JAR projects (just java code) I need to debug * this project depends on 500 JAR artifacts that are attached (in Eclipse) via either Eclipse external jar or Maven plugin dependency * I need to debug my WAR under Geronimo o all my dependencies, both Eclipse project references and external JARs should be available o if I change a java file in one of the referenced projects - it should be re-published into Geronimo on the fly by the plugin o I may choose to convert one of those 500 dependency JARs into a full blown Eclipse project so + plugin may have to drop that jar from Geronimo + redeploy it as an Eclipse project Controlling all those jars and classes via Maven-like repository migh be a stretch - by definition Maven repository hosts finalized artifacts that have passed unit tests. (dj) - Are you really planning to work with code outside an open eclipse project that doesn't pass _unit_ tests? Maven repositories can certainly contain SNAPSHOT -versioned jars which I think of as being typically the compiled version of whatever code is on your machine currently. Maybe the impedance mismatch we're having is that I have a hard time remembering developing without maven and you don't use it :-) I, on the contrary, am trying to quickly manupulate half-baked code that really belongs to IDE, not even a JAR file. So SharedLib seems to be a logical candidate. Or some other GBean that would allow easy classloading changes, especially given the fact that all manipulations originate not from a user but from a plugin that is fairly well tested Another consideration - visibility of the published classes. It does not matter that much for development deployments. But even here - I can envision rather complex applications desiring to limit the visibility of their artifacts. This leads to another idea - there should a way to specify where this SharedDevLib classloaders attaches - server-wide, particular EAR or, even WAR. First, you can already attach shared-lib classloaders wherever you want. We just provide one that acts sort of like the tomcat shared/lib but you are free to create as many configurations containing one or more shared-lib gbeans and include these configurations as parents/dependencies of whatever app you want. However, if you are wanting to create complicated classloader structures I think that shared lib is an inappropriate tool and you should think harder about putting the jars into the maven repo structure (they can all be under e.g. com.myco.bigproject or you can separate them more) and using explicit dependencies in your geronimo plans. This might be painful in the short term but I suspect it would clarify and document the exact dependencies between the jars. At this point I think we are trying to cram too much into the existing repository and shared lib implementations. I think its becoming clearer that the needs of a development environment may not be appropriate to support in a production server. However, there are a lot of possible solutions: here are a couple of suggestions: 1. Geronimo can support any number of simultaneous repository gbeans. If you were willing to use explicit dependencies instead of shared-lib, we could write a repository implementation that pointed into the eclipse workspace(s) and used the eclipse-compiled classes in situ. Presumably it would be possible to make it look first in eclipse for opened projects and then in some other location for jars that are not currently opened as eclipse projects. I think this is the cleanest solution: when a jar or project changes, you just need to restart the configuration that actually uses
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432652 ] Sachin Patel commented on GERONIMO-2324: Ok, so running a quick test it seems you can put absolute locations for both directories and jars inside the manifest classpath entry even though the 1.4.2 jar specification seems to say otherwise... On comments above... (1) Eclipse workspaces are much more flexible now days, and each of the actual project contents can reside anywhere on the filesystem and the actual contents fo the workspace directory only contain eclipse configuration metadata. Also project stuctures can contain multiple outfolders so this could get compilcated quickly. I prefer to go down the dummy jar path and recycle sharedlib as the dummy jar changes. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432657 ] Sachin Patel commented on GERONIMO-2324: Oleg.. Could you clarrify what you are doing in the following situation currently??? Lets say you have a single project, WebProject-A in your workspace. This project has a classpath reference to an external jar foo.jar (which in production gets copied to the sharedlib. Now lets say you want to make modifcations to foo.jar and you import foo.jar into your workspace as project Foo. What are you doing with the classpath reference on WebProject-A to Foo.jar? Are you currently manually deleting it and replacng it with a project reference to project Foo? I see a problem in this especially if you are keeping your .project and .classpath file's under source control. Is this the case? If so then people could accidentally commit these and the next person who checks out the code would have a .classpath reference to a non existent project. This is dangerous. How do you plan to address this? Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432253 ] Oleg Gusakov commented on GERONIMO-2324: SharedLib might not be an ideal solution as David quite reasonably indicated, but here is the use case: * I develop a WAR project under Eclipse * this project depends on 15 Eclipse JAR projects (just java code) I need to debug * this project depends on 500 JAR artifacts that are attached (in Eclipse) via either Eclipse external jar or Maven plugin dependency * I need to debug my WAR under Geronimo ** all my dependencies, both Eclipse project references and external JARs should be available ** if I change a java file in one of the referenced projects - it should be re-published into Geronimo on the fly by the plugin ** I may choose to convert one of those 500 dependency JARs into a full blown Eclipse project so *** plugin may have to drop that jar from Geronimo *** redeploy it as an Eclipse project Controlling all those jars and classes via Maven-like repository migh be a stretch - by definition Maven repository hosts finalized artifacts that have passed unit tests. I, on the contrary, am trying to quickly manupulate half-baked code that really belongs to IDE, not even a JAR file. So SharedLib seems to be a logical candidate. Or some other GBean that would allow easy classloading changes, especially given the fact that all manipulations originate not from a user but from a plugin that is fairly well tested ;) Another consideration - visibility of the published classes. It does not matter that much for development deployments. But even here - I can envision rather complex applications desiring to limit the visibility of their artifacts. This leads to another idea - there should a way to specify where this SharedDevLib classloaders attaches - server-wide, particular EAR or, even WAR. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
GERONIMO-2324
So does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don't fully address the problem.(1) Need to be able to provide external individual jar entries to the shared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared lib config should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications of doing this, and agree that this should not be an in-production feature that we should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly does from a development standpoint.Input appreciated.-sachin
Re: GERONIMO-2324
Hi Sachin, I apologize in advance if I say anything exceedingly ignorant and/or foolish... Given that this functionality is meant for a relatively specific use case (utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within an external plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.org So does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don't fully address the problem. (1) Need to be able to provide external individual jar entries to the shared library (2) Need to be able to add additional external classes folder to the shared library (3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared lib config should need to be recycled. This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications of doing this, and agree that this should not be an in-production feature that we should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly does from a development standpoint. Input appreciated. -sachin - This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: GERONIMO-2324
I feel strongly that is should be stated: Testing is not a relatively specific use case but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. Testing and dubugging mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? ~olegOn 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that havingthis functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QAenvironment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer IIDSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patelcc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED]he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem.(1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires aserver restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications ofdoing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may notnecessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged,confidential, legally privileged, and/or exempt from disclosureunder applicable law.If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliancethereon) is STRICTLY PROHIBITED.Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient toensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediatelycontact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you.
Re: GERONIMO-2324
On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a "relatively specific use case" but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. "Testing and dubugging" mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then its certainly something to look into. And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up.~olegOn 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that havingthis functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QAenvironment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer IIDSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem.(1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires aserver restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications ofdoing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may notnecessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged,confidential, legally privileged, and/or exempt from disclosureunder applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliancethereon) is STRICTLY PROHIBITED. Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient toensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediatelycontact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you. -sachin
Re: GERONIMO-2324
On 8/17/06, Sachin Patel [EMAIL PROTECTED] wrote: On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a relatively specific use case but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. Testing and dubugging mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then itscertainlysomething to look into. Reference is just a name. What's deployed under that name - it could be the same SharedLib bean but with, possibly, another parameter, telling it to be more promiscuous. So IDE adapter can take control over it and manipulate it's bahavior? And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up. And SharedLib is one of those builders? ~oleg On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer II DSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patelcc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem. (1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications of doing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosureunder applicable law.If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED.Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you. -sachin
Re: GERONIMO-2324
On Aug 17, 2006, at 1:04 PM, System Architect wrote:On 8/17/06, Sachin Patel [EMAIL PROTECTED] wrote: On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a "relatively specific use case" but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. "Testing and dubugging" mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then its certainly something to look into. Reference is just a name. What's deployed under that name - it could be the same SharedLib bean but with, possibly, another parameter, telling it to be more promiscuous. So IDE adapter can take control over it and manipulate it's bahavior? And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up. And SharedLib is one of those builders? No shared lib is not a builder just a simple Gbean. Some examples of the builders we have are EARConfigBuilder, TomcatBuilder, JettyBuilder connectorbuilder, , etc.. IIUC the deployment process is namespace driven and based on the content of your plan the appropriate builders get visited to build up the configuration. These individual builders locate process the contents of the application they are interested in. ~oleg On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer II DSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem. (1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications of doing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosureunder applicable law
[jira] Assigned: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel reassigned GERONIMO-2324: -- Assignee: Sachin Patel Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel updated GERONIMO-2324: --- Attachment: GERONIMO-2324.patch Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Sachin Patel updated GERONIMO-2324: --- Issue Type: RTC (was: Improvement) Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428410 ] David Jencks commented on GERONIMO-2324: I'm not thoroughly convinced this is a good idea. Does tomcat offer a similar feature? Some of my concerns: - Can you get the same effect by changing the classes and libs properties of the existing gbean? - Why would we encourage people to use shared lib rather than explicit dependencies? I'd rather see the repo code modified to include links to the actual jar/exploded jar location so you could point bits of the repo into your development environment. - What is the value of writing out an empty externals file? I think if you don't supply a file, we should assume you are not interested in this feature and not modify the environment. Certainly if no externals file name is supplied, we shouldn't try to write a file. - Does this actually work for both classes directories and individual jars? A test would be nice. On a technical level, the e.printStackTrace should be replaced with a log statement. In general there look to be a lot of failure cases that aren't taken care of. If an externals file is listed and not present, it's possible we should fail startup. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428413 ] Sachin Patel commented on GERONIMO-2324: Keep in mind this is to support development scenarios only. If a project in an IDE references jars in lets say a maven repo. We need the ability to add individual entries to the shard lib, without having to copy each individual jar over to the shared library.So the answer to your first question is no, this is not the same, there is no way to add invidivial entries. I don't quite understand your second bullet. Third bullet, true, just thought it would be nice to have an empty template. Yes, agree a test case should be added. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428429 ] Paul McMahan commented on GERONIMO-2324: I agree this is an important feature, I would use this in Eclipse all the time. The patch didn't apply cleanly for me on branches/1.1: bash-3.1$ patch -p0 ../patches/GERONIMO-2324.patch patching file configs/sharedlib/src/plan/plan.xml patching file modules/system/src/java/org/apache/geronimo/system/sharedlib/SharedLib.java Hunk #1 FAILED at 16. 1 out of 3 hunks FAILED -- saving rejects to file modules/system/src/java/org/apache/geronimo/system/sharedlib/SharedLib.java.rej bash-3.1$ Also, I'm wondering if adding the external jars via SharedLib is ideal since as I understand it SharedLib makes the classes available server wide and this might cause complications when two applications in the development environment want to use different versions of an external jar. But maybe I am misunderstanding SharedLib . Could the Eclipse plugin add the external dependencies into the application's MANIFEST.MF instead? Might be cleaner since it's application specific. One more question :-) What happens when the application is exported from Eclipse? Are the external references exported somehow or is that left to be resolved later at deployment time? Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428431 ] Sachin Patel commented on GERONIMO-2324: Modifying the application's manifest isn't the solution to the problem. The problem is we need to be able to provide support in an IDE to allow projects who reference the sharedlib and have external references to jars and what to represent those external jars as shared-lib entries. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428439 ] Paul McMahan commented on GERONIMO-2324: OK, I think I understand the usage scenario better now. i.e. these users are *already* using SharedLib and just want more/better support for it in the dev tooling(?). I'll watch for an updated patch and test it out. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428473 ] Sachin Patel commented on GERONIMO-2324: I think this is a perfectly reasonable feature request... if we're going to provide features in the runtime, we need to be sure a development enviorment can propertly support it as well. Otherwise, I suggest we compltely take out the sharedlib support so that users don't treat it as a deployment mechanism. Thus avoiding feature reqests such as this. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=all ] Joe Bohn updated GERONIMO-2324: --- Attachment: GERONIMO-2324.patch I couldn't get the original patch to apply clean. Here is an updated patch that does apply (at least for me). The content of this patch is the same as the original (none of the comments/recommendations have been implemented in this patch ... it just applies now). Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428525 ] David Jencks commented on GERONIMO-2324: To clarify my earlier points, in order - It is certainly possible to get support for exploded jars by adding more entries to the classes attribute. If each jars were to be all by itself in a directory it would be possible to add an entry to libs for each jar. I think that the runtime refresh characteristics of both solutions would be the same. I'm not convinced dragging xml into this class is worth it for the minimal gains in functionality, namely not pulling in all the jars in a directory in which you only have one jar you want. - IMO the shared lib is a bad idea that is included only for those who are not willing to explicitly specify their dependencies. Adding extra-fancy features to it doesn't make it a better idea. I think we should be encouraging people to use the geronimo/maven repo. A corresponding feature for the repo would be some metadata in the repo that says, actually the artifact is over here, unpacked I'd rather see that feature than this one. - I think writing out the externals file will fail in a lot of scenarios. - tests are still good In addition: - I think that exactly the same effect can be obtained with no code change by putting a jar in shared/lib with a manifest classpath that points to the locations of interest - I would also much rather see a solution that does not require restarting the shared lib config in order to pick up changes. (I'm not actually sure about the behavior of shared lib -- maybe someone who knows can clarify) Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12428534 ] Sachin Patel commented on GERONIMO-2324: From talking to Joe, modifying the config to add additional entries requires a server restart, modifying the contents of the sharedLib folder requires only a config restart. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Fix For: 1.x The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
