Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 47DCD9CEC for ; Tue, 28 Feb 2012 15:43:54 +0000 (UTC) Received: (qmail 27589 invoked by uid 500); 28 Feb 2012 15:43:54 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 27431 invoked by uid 500); 28 Feb 2012 15:43:53 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 27424 invoked by uid 99); 28 Feb 2012 15:43:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 15:43:53 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of forrestxm@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 15:43:46 +0000 Received: by wgbds12 with SMTP id ds12so2018682wgb.31 for ; Tue, 28 Feb 2012 07:43:26 -0800 (PST) Received-SPF: pass (google.com: domain of forrestxm@gmail.com designates 10.180.90.212 as permitted sender) client-ip=10.180.90.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of forrestxm@gmail.com designates 10.180.90.212 as permitted sender) smtp.mail=forrestxm@gmail.com; dkim=pass header.i=forrestxm@gmail.com Received: from mr.google.com ([10.180.90.212]) by 10.180.90.212 with SMTP id by20mr39994848wib.12.1330443806895 (num_hops = 1); Tue, 28 Feb 2012 07:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=C2wRj8ze0TqOPqRHH5UGfnCpXE5Ee7ej2Jp6IJoRegY=; b=rqeB7v6I6P4zCCcpF4sS6QjGrjcn5yxjP4gfNTEEDFS6obFcIpad2aAbcSABzLFVaa 0Se8XxUcqJ/jkwfO/ugCOAb1WOBufVKzP8+f32F4Tultu44mqdeB2xg4y8ItJGx1mY5A nqxbeBzni9hS3rj7/6Uzv5w5lHUNh3VNMZLY0= MIME-Version: 1.0 Received: by 10.180.90.212 with SMTP id by20mr31704588wib.12.1330443806781; Tue, 28 Feb 2012 07:43:26 -0800 (PST) Received: by 10.216.3.144 with HTTP; Tue, 28 Feb 2012 07:43:26 -0800 (PST) In-Reply-To: <4F4CF2D6.8080005@cait.org> References: <8F05CDCE-EEB3-431A-960C-1BDF5A2BDA40@yahoo.com> <4F4CF2D6.8080005@cait.org> Date: Tue, 28 Feb 2012 10:43:26 -0500 Message-ID: Subject: Re: Add name-value configuration entry for the deployment scope ? From: Forrest Xia To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=f46d043be2567f300004ba0816fb X-Virus-Checked: Checked by ClamAV on apache.org --f46d043be2567f300004ba0816fb Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue 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 : >> >> ... >> >> >> org.apache.geronimo.jsf.**support >> false >> >> >> b. Have a PropertyDefintion GBean in geronimo-system module to describe >> the >> property, the class may something like : >> @GBean >> public class PropertyDefintion { >> >> 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 > >> >> >> 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. >> > >> > >> > **** >> > **** >> > >> > >> > >> > 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 --f46d043be2567f300004ba0816fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2012 at 10:29 AM, Russel= l E Glaue <rglaue@c= ait.org> wrote:
I think it would be really terrific if the properties that are typically pr= ovided on the command line at startup could be instead, optionally, defined= in a configuration file. Better yet if these can be configured via the por= tlet.
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 th= ey are implemented, some documents are sure to be added.
=A0

If Geronimo is to be used in a web server farm of dozens of nodes, there ne= eds to be a way to remotely administer all properties. And if all propertie= s can be setup in a config file and no longer need to be passed on the comm= and line, this would enhance the ability for remote administration. The goa= l being the administrator never has to login to the server to deploy new Ge= ronimo 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= ,
=A0the rough idea is that
a. update our schema file to include things like :
<environment>
=A0 =A0 =A0 =A0 ...
<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 :
=A0 @GBean
public class PropertyDefintion<T> {

=A0 =A0 private String name;

=A0 =A0 private Type type;

=A0 =A0 private String description;

=A0 =A0 private String[] parentPropertyNames;

=A0 =A0 private String[] allowedValues;

=A0 =A0 public PropertyDefintion(String name, String type, String descript= ion,
String[] parentPropertyNames, String[] allowedValues) {
this.name <http://this.name> =3D nam= e;

=A0 =A0 =A0 =A0 this.type =3D Type.valueOf(type);
=A0 =A0 =A0 =A0 this.description =3D description;
=A0 =A0 =A0 =A0 this.parentPropertyNames =3D parentPropertyNames;
=A0 =A0 =A0 =A0 this.allowedValues =3D allowedValues;
=A0 =A0 }
=A0 .......

3. May also have a PropertyContext GBean for each application, which is use= d to
hold those configurations.
4. I have some property names in mind, including
=A0 =A0 org.apache.geronimo.webservice.support : The deployed appli= cation will not
use any webservice related stuff.
=A0 =A0 org.apache.geronimo.webservice.client.support =A0: Need to = inject some
service ref for this
=A0 =A0 org.apache.geronimo.webservice.server.support =A0: Have SEI= in the deployed
application.
=A0 =A0 org.apache.geronimo.webservice.jaxws.support
=A0 =A0 org.apache.geronimo.webservice.jaxrpc.support
=A0 =A0 org.apache.geronimo.ejb.support : No ejb component there, w= ith this
configured with false, there is no need to annotation scanning in some
scenarios, e,g, while deploying a web application.
=A0 =A0 org.apache.geronimo.jsf.support =A0......
=A0 =A0 org.apache.geronimo.jaxrs.support ......
=A0 =A0 .....

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 MyFacesMod= uleBuilder
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 st= op
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. M= aybe,
we could make those configurations visible in the Configuration instance of= the
config admin server ???

Any comment for this ?

2011/2/14 Ivan <xh= hsld@gmail.com <mailto:xhhsld@gmail.com>>


=A0 =A0JSF issue is just an example, as I find a user fire a JIRA for it. = The root
=A0 =A0reason is that we use system property everywhere in the geronimo co= des,
=A0 =A0which is of global scope. Once we want to change the behavior, all = the
=A0 =A0components are affected. And it would be better to have other scope=
=A0 =A0configurations, like deployment scope, which means the configuratio= n is only
=A0 =A0for current application deployment process. We might also have appl= ication
=A0 =A0scope configurations, which might be effect for the specified appli= cation.
=A0 =A0Also, I think that we need this function even when we move to a gbe= an-free
=A0 =A0geronimo, and yes, I agree that the solution now might not applicab= le in the
=A0 =A0future. =A0But, do we have a plan for the gbean-free kernel ?



=A0 =A02011/2/14 David Jencks <david_jencks@yahoo.com <mailto:david_jencks@yahoo.com>>


=A0 =A0 =A0 =A0Hi Ivan,

=A0 =A0 =A0 =A0If I understand your proposal this is what you can currentl= y do in a
=A0 =A0 =A0 =A0maven geronimp plugin project in the car-maven-plugin confi= guration
=A0 =A0 =A0 =A0where you specify which deployers to start.

=A0 =A0 =A0 =A0I think this makes sense but I'd rather wait to impleme= nt it until we
=A0 =A0 =A0 =A0know more what a gbean-free geronimo would look like. =A0I = suspect that
=A0 =A0 =A0 =A0anything we do now would be obsolete later.

=A0 =A0 =A0 =A0Would there be any confusion if you had a web app you wante= d to deploy
=A0 =A0 =A0 =A0on either jetty or tomcat but that included its own jsf? = =A0Currently you
=A0 =A0 =A0 =A0could use the same plan for your jetty or tomcat server but= I think
=A0 =A0 =A0 =A0you'd need separate plans for your proposal. =A0I think= this is a minor
=A0 =A0 =A0 =A0problem that should not block this idea.

=A0 =A0 =A0 =A0thanks!
=A0 =A0 =A0 =A0david jencks

=A0 =A0 =A0 =A0On Feb 13, 2011, at 5:59 AM, Ivan wrote:

=A0 =A0 =A0 =A0 > Hi, there are many configurations in the Geronimo cod= es, and all of
=A0 =A0 =A0 =A0them are system scope, using System.getProperty. And seems = that the only
=A0 =A0 =A0 =A0way to change it is to set -D while starting Geronimo. Yes,= some of them
=A0 =A0 =A0 =A0are of global scope, but some of them are only of deploymen= t scope ( or
=A0 =A0 =A0 =A0should be deployment scope ). for example, in the past, whi= le users want
=A0 =A0 =A0 =A0to use their own JSF API and implementations, we always ask= them to stop
=A0 =A0 =A0 =A0the MyFaces deployer, but if we could have a configuration = only takes
=A0 =A0 =A0 =A0affect in the deployment process, that would be easier.
=A0 =A0 =A0 =A0 > My proposal is that to add a configuration in the env= ironment
=A0 =A0 =A0 =A0elements, those values could be kept in the DeploymentConte= xt.
=A0 =A0 =A0 =A0 > <deployment-configurations>
=A0 =A0 =A0 =A0 > <deployment-configuration>
=A0 =A0 =A0 =A0 > <name>****</name>
=A0 =A0 =A0 =A0 > <value>****</value>
=A0 =A0 =A0 =A0 > <deployment-configuration>
=A0 =A0 =A0 =A0 > </deployment-configuraitons>
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > Aslo, we might be able to allow the users to configur= e them in the
=A0 =A0 =A0 =A0deployment portlet, also, might be consider how to take adv= antage of the
=A0 =A0 =A0 =A0config-admin service.
=A0 =A0 =A0 =A0 > Thoughts ? If no objection, I would open a JIRA and w= ork on it later.
=A0 =A0 =A0 =A0 > --
=A0 =A0 =A0 =A0 > Ivan




=A0 =A0--
=A0 =A0Ivan




--
Ivan



--
Thanks!

Regards,= Forrest

--f46d043be2567f300004ba0816fb--