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
