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 <[email protected]> > 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 <[email protected]> > >> >> >> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <[email protected]>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 <[email protected] <mailto:[email protected]>> >>>> >>>> >>>> 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 <[email protected] <mailto: >>>> [email protected]**>> >>>> >>>> >>>> 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
