Re: An idea for defining custom valves in config.xml

Joe Bohn Wed, 08 Oct 2008 13:55:40 -0700

Jason Warner wrote:

Thanks for the explanation, David. I don't disagree with anythingyou've explained, but I'm not sure you've addressed my concern about thedisparity in the effort required to deploy a custom valve on tomcat andon geronimo. Even with the a streamlined process involving a tomcatserver portlet and using the tomcat6 plugin as a base, the user stillhas to become a plugin developer to deploy their valve on geronimo. Ifthat's how it has to be, then I suppose that's how it has to be. I'mjust concerned that it could turn off users that might have otherwiselived happily with geronimo. I'm not really sure how widespread the useof custom valves are, though, so maybe it's just a small minority thiswould even effect. I'd be curious to get some feedback from some otherdevelopers and see if they have any thoughts on the matter. Anyone elseout there keeping an eye on this thread?

I've been keeping an eye on it and I agree with you Jason that there isa disparity in the work required to add a valve to tomcat versus thatrequired to add a valve to tomcat embedded in Geronimo. I also agreewith David that the current Tomcat process does not lend itself to areproducible configuration.

In cases like this I tend to think like a politician and advocate aboth/and rather than an either/or. I suspect that some users will wantthings in Geronimo to be as similar to Tomcat as possible ... and sowill want a simple configuration solution. Doing so might convince themto move over to Geronimo and over time they may gain a greaterappreciation for a more Geronimo like solution. Others might be comingin with more knowledge of Geronimo and expect something that is moreconsistent with Geronimo and can be reproduced. Can we give them bothwhat they want?

It seems like we could help the Tomcat centric folks with a simpleconfiguration attribute that we can use to extend the classpath. Forthe more sophisticated Geronimo user we can direct them torebuild/redeploy the Tomcat module with the additional dependency on thevalve jar ... perhaps using c-m-p and then their own custom assembly.Even while providing the first approach we can highly recommend thesecond approach.

It seems to me that the attribute/classpath extension is a simple thingto implement and will provide a high level of value to users that areaccustomed to Tomcat. The Tomcat module rebuild/redeploy is just amatter of documentation ... correct?

Joe

On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:



    On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:

    I'm not sure if these steps are reasonable from a purely user
    perspective.  When using plain old tomcat, you can download a
    binary, add your custom valve jar, make a config change and then
    use your server with its custom valve.  To accomplish the same
    task in geronimo, we are asking the user to download and install
    maven as well as grab source code for the tomcat plugin.  I'd
    really like to have a way we can accomplish the same goal while
    allowing the users to maintain a user level of interaction with
    geronimo.


    I think (1) is really a more realistic approach philosophically so
    I'll only discuss it more.

Lets consider the results of the modifications on tomcat and geronimo.

    In tomcat, the user has modified their server installation and has
    no built-in record of what they did.  If they install another server
    somewhere else they have to look in their notes or try to remember
    what they did or ??? to get the same result.

    In geronimo + maven they have a reproducible and automated way to
    generate the customization that is suitable for storing in scm,
    auditing, running through qa, etc etc.

    Its also possible to fish the plan out of the tomcat6 plugin, modify
    it a bit, and deploy it using gshell or (if you didn't start it)
    using the console.  I think you could add the geronimo-plugin.xml
    using the admin console and add the artifact-aias.  This on export
    would result in a reusable plugin.  I'm not sure if you could turn
    around and install the plugin on the server it was generated on to
    install the artifact alias so on the next startup you'd get the new
    tomcat plugin.

    My philosophical objection to adding valves to the existing tomcat
    config is that you've changed it in a fundamental way so you should
    have a new, replacement, plugin instead.  By this point you can add
    the extra jar(s) anyway as dependencies.

    Maybe we could have a tomcat server portlet that would help with
     generating tomcat server plans with custom valves and connectors
    and such stuff.  I think that right now that is still the hardest part.

    thanks
    david jencks



    On Wed, Oct 8, 2008 at 1:22 PM, David Jencks
    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:


        On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:

        David,

        Could you describe to me in a little more detail what you
        were thinking in regards to defining a new tomcat server in a
        child classloader?  I'm still working on creating an example,
        but I found some documentation confirming tomcat's use of a
        TCCL in loading components and would like to continue the
        discussion.  It seems you are proposing that a user create a
        plugin that defines a new tomcat instance that includes their
        custom valve.  Am I understanding correctly?  I've taken a
        look at the app-per-port sample you described and this does
        not seem like a trivial task.


        app-per-port is complicated by the additional features there of:
        - only one artifact (an ear) instead of 2 or 3 plugins
        - starting the connectors after the web app has started

        If neither of these features is needed you can just build a
        plugin with the tomcat server + custom valve.  There are two
        strategies:
        1. replace the tomcat6 plugin
        2. use the (stopped) tomcat6 plugin as a parent for the new
        plugin.

        In either case I'd build the new plugin with maven and start
        by copying the tomcat6 plugin and renaming it appropriately.
         Then modify the plan to include the custom valve.

        for (1), you'd just add the jar with the custom valve as a pom
        dependency.  Use an artifact-alias so your tomcat plugin will
        replace the usual tomcat6 plugin.
        for (2), you'd replace the pom dependencies with a dependency
        on the tomcat6 plugin, and add the custom valve jar
        dependency.  In the c-m-p configuration you'll want to specify
        the import on the tomcat^ plugin as "classes" so it wont get
        started.  An artifact alias won't work here so don't deploy
        things that depend on tomcat6 as that will result in the
        tomcat6 plugin starting and having port conflicts with your
        plugin.

        Building a custom server including your plugin or installing
        it on a framework server via gshell is likely to work better
        than trying to replace the tomcat6 plugin while it's running
        through the admin console.

        hope this helps
        david jencks



        Thanks,

        On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner
        <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:



            On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
            <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
            wrote:


                On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:



                On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
                <[EMAIL PROTECTED]
                <mailto:[EMAIL PROTECTED]>> wrote:


                    On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:



                    On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
                    <[EMAIL PROTECTED]
                    <mailto:[EMAIL PROTECTED]>> wrote:


                        On Oct 3, 2008, at 12:51 PM, Jason Warner
                        wrote:

                          Hey all.  I'm working on an idea for
                        allowing custom valves to be defined in
                        config.xml.  Currently this isn't possible
                        since the tomcat classloader would not

contain the custom classes for the valve.I've create a jira for tracking this issue

                        [1] and it contains a few links to
                        workarounds.  IMHO, The solution we should
                        be looking for is a way to add classes to
                        a module without having to undeploy,

modify the module config, and redeploying.


                        People have suggested stuff like this
                        before.  IMO it pretty much goes against
                        the fundamental idea of geronimo of having
                        fairly fixed plugins with only a few knobs
                        to turn to adjust things in config.xml and
                        config-substitutions.properties.

                        Why is changing the classloader contents in
                        config.xml a good idea?  What is so hard
                        about redeploying the app if you want to
                        change its classloader significantly?  If
                        you want to change a class in the app you
                        have to redeploy it.... why is this
                        situation different?


                    The specific instance I have in mind for this
                    change is using a custom valve for tomcat, so I
                    think the scope really should be limited to
                    just the tomcat module.  I can't think of
                    another instance where this would be useful, so
                    it's probably not necessary or desirable to
                    expand it further.  I believe this situation is
                    different because the structure of geronimo is
                    causing a disconnect between the functionality
                    of tomcat and the functionality of tomcat as it
                    is embedded in geronimo.  As Don just said in
                    the middle of my typing this, I don't believe
                    we should expect the average user to have to
                    rebuild one of our modules to add something
                    that can be added in a much simpler way within

tomcat itself.


                    Could you explain more about the circumstances
                    for this custom valve?  Is it intended to be for
                    every app deployed on this tomcat server
                    instance rather than for one particular app?
                     Will it work if it is in a child classloader of
                    the tomcat plugin classloader?


                    When a valve is added to the tomcat valve chain,

it becomes part of the request processing pipeline.Every request that is made to that tomcat server

                instance passes through this valve chain as it's
                processed regardless of whether the valve will act
                upon it or not.  It's possible that a single web app
                will be the only app to use the valve, and for that
                instance it is already possible to define the valve
                in the context of the web app rather than the tomcat
                server.  We need to be able to define a valve as
                part of tomcat server instance as well, though, to
                be consistent with tomcat.  Currently we can only

define the valves on the per web app basis.I don't think this would work in a child

                classloader of the tomcat plugin classloader.  When
                we start up the tomcat module now, the currently
                defined valves are processed and added to the
                engine.  The custom valves would need to be added to
                the valves already in the tomcat engine to be
                available in the way described previously.  Once the
                valves were added to the engine (which would be
                using the tomcat classloader, I believe) the class
                def not found issues we currently see would pop back
                up.  For this to work, the custom valve classes and
                the tomcat engine would need to share the same

classloader.


                Could you try this to be sure?  I would hope that
                tomcat would use a TCCL or supplied classloader for
                loading components rather than something like
                TomcatEngine.class.getClassLoader() which I believe
                is what you are suggesting it does.

                One example of an inconvenient tomcat configuration
                is the app-per-port sample where we set up a whole
                additional tomcat server in a child configuration.  I
                think all the server components in that example are
                also in a standard tomcat server but its a similar
                situation to what I'm thinking of here in terms of
                configuring a tomcat server in a child classloader.


            Sure.  It'll take me a bit as I don't actually have any

examples prepared yet.



                    At the moment I would MUCH rather see us make it
                    easier for users to deploy
                    new/different/modified tomcat servers (and other
                    plugins) than introduce a hack to modify
                    classloaders of existing plugins.  Our
                    customization story is already  too complicated,
                    IMO we don't need to glue on more bits that
                    don't actually fit well.

                    IMO the best end result for users is to have a
                    new tomcat plugin with the needed extra jars and
                    valve configuration.  Lets look for a way to
                    make it really easy for our users to get there.


                I agree that a whole new plugin with all desired
                functionality included would be best for users.  Any

ideas how to make this easier than it currently is?Perhaps the attribute idea mentioned by Joe could

                serve as a temporary solution until we can come up
                with something better.


                    How would you deal with this in an osgi or
                    spring environment?


                If anyone knows how osgi deals with situations like
                this I'd find it really helpful in considering
                alternative directions.
                thanks
                david jencks

                    thanks
                    david jencks



                    Thanks!


                        thanks
                        david jencks

                        I think this can be done by allowing a
                        user to indicate jars that should be

loaded by a module within the config.xml.These jars can then be added to the

                        module's classloader for use by the
                        module.  I'm not extremely familiar with
                        how our classloader works, but I've taken
                        a look through the code and I think the
                        ability to add to the classloader can be

implemented without too much difficulty.I'm not quite sure what type of scope to

                        give this change, though.  Should I leave
                        it as a change aimed solely at tomcat
                        valves or should it be expanded to
                        encompass any configuration?  I realize
                        this is only a rough idea of what i plan
                        to do, but I'm still working out the
                        details of how to proceed.  I'm hoping for
                        some feedback on what I intend to do and
                        possibly some alternate ideas if anyone
                        has some.< br>
                        Thanks!

[1]https://issues.apache.org/jira/browse/GERONIMO-4335

--~Jason Warner





--
~Jason Warner

Re: An idea for defining custom valves in config.xml

Reply via email to