On Tue, Feb 28, 2012 at 10:29 AM, Russell E Glaue <[email protected]> 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 <[email protected] <mailto:[email protected]>>
>>
>>
>> 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 <[email protected] <mailto:
>> [email protected]**>>
>>
>>
>> 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
