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. If you are not the intended
