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 Fri, 02 Mar 2012 02:57:44 GMT
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

Mime
View raw message