geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Add name-value configuration entry for the deployment scope ?
Date Sun, 08 Apr 2012 16:09:20 GMT
I just uploaded a patch file to
https://issues.apache.org/jira/browse/GERONIMO-5813, to make the changes
looks more clear, only important part of my local changes are included. The
most changes are :

a. Update the schema to allow configure properties in the environment
segments.
b. A PropertyContext chain will created for target application, it is
something like child-first classloadering, and the default property context
is System.getProperties(), with this, we could have global/application
scope configurations.
c. PropertyContext GBean will be added for each module, so that all other
GBeans would use that to determine the behavior.
d. A PropertyDefinition GBean will be created for each property, with that,
I am thinking that we could have a portlet to list all the available
property configurations for the server, and also, we could allow users to
input some application-level configurations while deploying the
applications.

I would appreciate someone could help to review those changes and drop some
comments  :-)



2012/3/2 David Jencks <david_jencks@yahoo.com>

> I'm not sure I understand the value of the global properties.  Wouldn't
> you get the same effect by turning off the appropriate module builder or
> module builder extension? or in some cases a gbean?
>
> For applications, if I understand correctly, even if we had single-pass
> annotation scanning, this could be useful to indicate that an
> implementation bundled in the application should be used rather than the
> one supplied by geronimo?  I think that is a sufficiently valuable use case
> so I'm in favor of this idea.  I guess if we're going to have application
> level properties like this then having global ones as well makes sense even
> if they are redundant.
>
> thanks
> david jencks
>
>
> On Mar 1, 2012, at 6:57 PM, Ivan wrote:
>
> A JIRA  https://issues.apache.org/jira/browse/GERONIMO-5813  has been
> opened in the past, will work on the things with it. If no objection, I
> would like to add those property first with global scope
> (system.getproperty) in the first step, then will made changes to make it
> application-scope.
> The property names I propose to add are :
> name                                                          default value
> org.apache.geronimo.jsf.support                        true
> org.apache.geronimo.jaxrs.support                    true
> org.apache.geronimo.jaxrpc.support                  true
> org.apache.geronimo.jaxws.support                   true
> org.apache.geronimo.jaxws.server.support         true
> org.apache.geronimo.jaxws.client.support          true
> org.apache.geronimo.ejb.support                      true
> org.apache.geronimo.ejb.server.support            true
> org.apache.geronimo.ejb.client.support             true
>
> comment ?
>
> 2012/2/28 Forrest Xia <forrestxm@gmail.com>
>
>>
>>
>> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rglaue@cait.org>wrote:
>>
>>> I think it would be really terrific if the properties that are typically
>>> provided on the command line at startup could be instead, optionally,
>>> defined in a configuration file. Better yet if these can be configured via
>>> the portlet.
>>>
>> IUCC, those properties are only for deployment time use, it's not for
>> server runtime use. So no need to add them to the command line scripts, or
>> consolidate them into a configuration file.
>>
>> Once they are implemented, some documents are sure to be added.
>>
>>
>>>
>>> If Geronimo is to be used in a web server farm of dozens of nodes, there
>>> needs to be a way to remotely administer all properties. And if all
>>> properties can be setup in a config file and no longer need to be passed on
>>> the command line, this would enhance the ability for remote administration.
>>> The goal being the administrator never has to login to the server to deploy
>>> new Geronimo instances and administer them.
>>>
>>> -RG
>>>
>>>
>>>
>>> On 02/28/2012 08:17 AM, Ivan wrote:
>>>
>>>> Hi, I am thinking to try to implement this feature in the coming
>>>> 3.0-beta-2,
>>>>  the rough idea is that
>>>> a. update our schema file to include things like :
>>>> <environment>
>>>>         ...
>>>> <properties>
>>>> <property>
>>>> <name>org.apache.geronimo.jsf.**support</name>
>>>> <value>false</value>
>>>> </properties>
>>>> </envrionment>
>>>> b. Have a PropertyDefintion GBean in geronimo-system module to describe
>>>> the
>>>> property, the class may something like :
>>>>   @GBean
>>>> public class PropertyDefintion<T> {
>>>>
>>>>     private String name;
>>>>
>>>>     private Type type;
>>>>
>>>>     private String description;
>>>>
>>>>     private String[] parentPropertyNames;
>>>>
>>>>     private String[] allowedValues;
>>>>
>>>>     public PropertyDefintion(String name, String type, String
>>>> description,
>>>> String[] parentPropertyNames, String[] allowedValues) {
>>>> this.name <http://this.name> = name;
>>>>
>>>>         this.type = Type.valueOf(type);
>>>>         this.description = description;
>>>>         this.parentPropertyNames = parentPropertyNames;
>>>>         this.allowedValues = allowedValues;
>>>>     }
>>>>   .......
>>>>
>>>> 3. May also have a PropertyContext GBean for each application, which is
>>>> used to
>>>> hold those configurations.
>>>> 4. I have some property names in mind, including
>>>>     org.apache.geronimo.**webservice.support : The deployed
>>>> application will not
>>>> use any webservice related stuff.
>>>>     org.apache.geronimo.**webservice.client.support  : Need to inject
>>>> some
>>>> service ref for this
>>>>     org.apache.geronimo.**webservice.server.support  : Have SEI in the
>>>> deployed
>>>> application.
>>>>     org.apache.geronimo.**webservice.jaxws.support
>>>>     org.apache.geronimo.**webservice.jaxrpc.support
>>>>     org.apache.geronimo.ejb.**support : No ejb component there, with
>>>> this
>>>> configured with false, there is no need to annotation scanning in some
>>>> scenarios, e,g, while deploying a web application.
>>>>     org.apache.geronimo.jsf.**support  ......
>>>>     org.apache.geronimo.jaxrs.**support ......
>>>>     .....
>>>>
>>>> The most reason for this is that :
>>>> a. Geronimo is suffering from bad experience from long long long
>>>> deployment
>>>> time, especially for those big application with many jar files. One of
>>>> the major
>>>> reason is that, there are too many annotation scanning there, and so
>>>> far we did
>>>> not have a uniform annotation scanning framework. With those options
>>>> above, it
>>>> is possible to ignore some process steps. e.g. if
>>>> org.apache.geronimo.jsf.**support is configured false, then
>>>> MyFacesModuleBuilder
>>>> will not do anything.
>>>> b. From the user list, I saw some guys try to use other java ee
>>>> providers, like
>>>> using cxf for webservice, use ri jsf implementation. Now, we may need
>>>> to stop
>>>> the related deployer to avoid some problems.
>>>> c. There are some existing configurations here and there in Geronimo
>>>> codes, all
>>>> of them are server scope.
>>>>
>>>> For the OSGi integration side, so far, I did not have much idea for
>>>> this. Maybe,
>>>> we could make those configurations visible in the Configuration
>>>> instance of the
>>>> config admin server ???
>>>>
>>>> Any comment for this ?
>>>>
>>>> 2011/2/14 Ivan <xhhsld@gmail.com <mailto:xhhsld@gmail.com>>
>>>>
>>>>
>>>>    JSF issue is just an example, as I find a user fire a JIRA for it.
>>>> The root
>>>>    reason is that we use system property everywhere in the geronimo
>>>> codes,
>>>>    which is of global scope. Once we want to change the behavior, all
>>>> the
>>>>    components are affected. And it would be better to have other scope
>>>>    configurations, like deployment scope, which means the configuration
>>>> is only
>>>>    for current application deployment process. We might also have
>>>> application
>>>>    scope configurations, which might be effect for the specified
>>>> application.
>>>>    Also, I think that we need this function even when we move to a
>>>> gbean-free
>>>>    geronimo, and yes, I agree that the solution now might not
>>>> applicable in the
>>>>    future.  But, do we have a plan for the gbean-free kernel ?
>>>>
>>>>
>>>>
>>>>    2011/2/14 David Jencks <david_jencks@yahoo.com <mailto:
>>>> david_jencks@yahoo.com**>>
>>>>
>>>>
>>>>        Hi Ivan,
>>>>
>>>>        If I understand your proposal this is what you can currently do
>>>> in a
>>>>        maven geronimp plugin project in the car-maven-plugin
>>>> configuration
>>>>        where you specify which deployers to start.
>>>>
>>>>        I think this makes sense but I'd rather wait to implement it
>>>> until we
>>>>        know more what a gbean-free geronimo would look like.  I suspect
>>>> that
>>>>        anything we do now would be obsolete later.
>>>>
>>>>        Would there be any confusion if you had a web app you wanted to
>>>> deploy
>>>>        on either jetty or tomcat but that included its own jsf?
>>>>  Currently you
>>>>        could use the same plan for your jetty or tomcat server but I
>>>> think
>>>>        you'd need separate plans for your proposal.  I think this is a
>>>> minor
>>>>        problem that should not block this idea.
>>>>
>>>>        thanks!
>>>>        david jencks
>>>>
>>>>        On Feb 13, 2011, at 5:59 AM, Ivan wrote:
>>>>
>>>>         > Hi, there are many configurations in the Geronimo codes, and
>>>> all of
>>>>        them are system scope, using System.getProperty. And seems that
>>>> the only
>>>>        way to change it is to set -D while starting Geronimo. Yes, some
>>>> of them
>>>>        are of global scope, but some of them are only of deployment
>>>> scope ( or
>>>>        should be deployment scope ). for example, in the past, while
>>>> users want
>>>>        to use their own JSF API and implementations, we always ask them
>>>> to stop
>>>>        the MyFaces deployer, but if we could have a configuration only
>>>> takes
>>>>        affect in the deployment process, that would be easier.
>>>>         > My proposal is that to add a configuration in the environment
>>>>        elements, those values could be kept in the DeploymentContext.
>>>>         > <deployment-configurations>
>>>>         > <deployment-configuration>
>>>>         > <name>****</name>
>>>>         > <value>****</value>
>>>>         > <deployment-configuration>
>>>>         > </deployment-configuraitons>
>>>>         >
>>>>         > Aslo, we might be able to allow the users to configure them
>>>> in the
>>>>        deployment portlet, also, might be consider how to take
>>>> advantage of the
>>>>        config-admin service.
>>>>         > Thoughts ? If no objection, I would open a JIRA and work on
>>>> it later.
>>>>         > --
>>>>         > Ivan
>>>>
>>>>
>>>>
>>>>
>>>>    --
>>>>    Ivan
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ivan
>>>>
>>>
>>
>>
>> --
>> Thanks!
>>
>> Regards, Forrest
>>
>>
>
>
> --
> Ivan
>
>
>


-- 
Ivan

Mime
View raw message