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:34:49 GMT
A nice feature to help improve the deployment time performance, please help
link to my reported jira https://issues.apache.org/jira/browse/GERONIMO-6222

On Tue, Feb 28, 2012 at 9:17 AM, Ivan <xhhsld@gmail.com> 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 = 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>
>
>> 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>
>>
>>> 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