You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ivan <xh...@gmail.com> on 2012/02/28 15:17:45 UTC
Re: Add name-value configuration entry for the deployment scope ?
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 <xh...@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 <da...@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
Re: Add name-value configuration entry for the deployment scope ?
Posted by Forrest Xia <fo...@gmail.com>.
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 <xh...@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 <xh...@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 <da...@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
Re: Add name-value configuration entry for the deployment scope ?
Posted by Ivan <xh...@gmail.com>.
Also, I would hope that we will only use System.getProperty in those
bootstrap classes, for others, it is better to use the similar changes in
Deployer class, with this, we could have an isolated layer there, maybe in
the future, we could read the some configurations for other places, not
from the System properties.
private final boolean CLEAN_UP_ON_START =
PropertyContextManager.getInstance().getPropertyValue(CLEAN_UP_ON_START_KEY,
Boolean.class, Boolean.TRUE);
2012/4/9 Ivan <xh...@gmail.com>
> I just uploaded a patch file to
> https://issues.apache.org/jira/browse/GERONIMO-5813, to make the changes
> looks more clear, only important part of my local changes are included. The
> most changes are :
>
> a. Update the schema to allow configure properties in the environment
> segments.
> b. A PropertyContext chain will created for target application, it is
> something like child-first classloadering, and the default property context
> is System.getProperties(), with this, we could have global/application
> scope configurations.
> c. PropertyContext GBean will be added for each module, so that all other
> GBeans would use that to determine the behavior.
> d. A PropertyDefinition GBean will be created for each property, with
> that, I am thinking that we could have a portlet to list all the available
> property configurations for the server, and also, we could allow users to
> input some application-level configurations while deploying the
> applications.
>
> I would appreciate someone could help to review those changes and drop
> some comments :-)
>
>
>
> 2012/3/2 David Jencks <da...@yahoo.com>
>
>> I'm not sure I understand the value of the global properties. Wouldn't
>> you get the same effect by turning off the appropriate module builder or
>> module builder extension? or in some cases a gbean?
>>
>> For applications, if I understand correctly, even if we had single-pass
>> annotation scanning, this could be useful to indicate that an
>> implementation bundled in the application should be used rather than the
>> one supplied by geronimo? I think that is a sufficiently valuable use case
>> so I'm in favor of this idea. I guess if we're going to have application
>> level properties like this then having global ones as well makes sense even
>> if they are redundant.
>>
>> thanks
>> david jencks
>>
>>
>> On Mar 1, 2012, at 6:57 PM, Ivan wrote:
>>
>> 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 <fo...@gmail.com>
>>
>>>
>>>
>>> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rg...@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 <ma...@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
>>
>>
>>
>
>
> --
> Ivan
>
--
Ivan
Re: Add name-value configuration entry for the deployment scope ?
Posted by Ivan <xh...@gmail.com>.
I just uploaded a patch file to
https://issues.apache.org/jira/browse/GERONIMO-5813, to make the changes
looks more clear, only important part of my local changes are included. The
most changes are :
a. Update the schema to allow configure properties in the environment
segments.
b. A PropertyContext chain will created for target application, it is
something like child-first classloadering, and the default property context
is System.getProperties(), with this, we could have global/application
scope configurations.
c. PropertyContext GBean will be added for each module, so that all other
GBeans would use that to determine the behavior.
d. A PropertyDefinition GBean will be created for each property, with that,
I am thinking that we could have a portlet to list all the available
property configurations for the server, and also, we could allow users to
input some application-level configurations while deploying the
applications.
I would appreciate someone could help to review those changes and drop some
comments :-)
2012/3/2 David Jencks <da...@yahoo.com>
> I'm not sure I understand the value of the global properties. Wouldn't
> you get the same effect by turning off the appropriate module builder or
> module builder extension? or in some cases a gbean?
>
> For applications, if I understand correctly, even if we had single-pass
> annotation scanning, this could be useful to indicate that an
> implementation bundled in the application should be used rather than the
> one supplied by geronimo? I think that is a sufficiently valuable use case
> so I'm in favor of this idea. I guess if we're going to have application
> level properties like this then having global ones as well makes sense even
> if they are redundant.
>
> thanks
> david jencks
>
>
> On Mar 1, 2012, at 6:57 PM, Ivan wrote:
>
> 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 <fo...@gmail.com>
>
>>
>>
>> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rg...@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 <ma...@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
>
>
>
--
Ivan
Re: Add name-value configuration entry for the deployment scope ?
Posted by David Jencks <da...@yahoo.com>.
I'm not sure I understand the value of the global properties. Wouldn't you get the same effect by turning off the appropriate module builder or module builder extension? or in some cases a gbean?
For applications, if I understand correctly, even if we had single-pass annotation scanning, this could be useful to indicate that an implementation bundled in the application should be used rather than the one supplied by geronimo? I think that is a sufficiently valuable use case so I'm in favor of this idea. I guess if we're going to have application level properties like this then having global ones as well makes sense even if they are redundant.
thanks
david jencks
On Mar 1, 2012, at 6:57 PM, Ivan wrote:
> 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 <fo...@gmail.com>
>
>
> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rg...@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 <ma...@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 <ma...@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
Re: Add name-value configuration entry for the deployment scope ?
Posted by Ivan <xh...@gmail.com>.
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 <fo...@gmail.com>
>
>
> On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rg...@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 <ma...@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
Re: Add name-value configuration entry for the deployment scope ?
Posted by Forrest Xia <fo...@gmail.com>.
On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <rg...@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 <ma...@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
Re: Add name-value configuration entry for the deployment scope ?
Posted by Russell E Glaue <rg...@cait.org>.
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.
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 <ma...@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 <ma...@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