geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "System Architect" <>
Subject Re: GERONIMO-2324
Date Thu, 17 Aug 2006 15:46:47 GMT
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?


On 8/17/06, <> 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
> 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
>              <sppatel2@gmail.c
>              om>                                                        To
>              Sent by: Sachin 
>              Patel                                                      cc
>              <
>              m>                                                    Subject
>                                        GERONIMO-2324
>              08/17/2006 08:06
>              AM
>              Please respond to
>              dev@geronimo.apac
> 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.

View raw message