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
