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 <xhh...@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 <xhh...@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_jen...@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
