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