geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Forrest Xia <forres...@gmail.com>
Subject Re: Add name-value configuration entry for the deployment scope ?
Date Tue, 28 Feb 2012 15:43:26 GMT
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

Mime
View raw message