You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Karan Malhi <ka...@gmail.com> on 2007/06/02 18:54:18 UTC

Re: idea: conf/system.properties

I have noticed that during the bootstrap process of server startup , we put
system properties multiple times into SystemInstance. Maybe I overlooked
something, but there are multiple places where the SystemInstance gets
initialized with SystemInstance.init(System.getProperties()). This call is
already made in the MainImpl.main . For example, in the
org.apache.openejb.loader.Server.parseArguments() has the following:
   private static Properties parseArguments(String args[]) throws
DontStartServerException {
       Properties props = new Properties();
        props.putAll(System.getProperties());

        props.put("openejb.server.ip", "127.0.0.1");
        props.put("openejb.server.port", "4201");
        props.put("openejb.server.threads", "20");
.....
return props;
}

And we have the following in org.apache.openejb.loader.Server.main()
            Properties props = parseArguments(args);
            SystemInstance.init(props);

And we have the following in the org.apache.openejb.cli.MainImpl.main
        try {
            SystemInstance.init(System.getProperties());
            systemInstance = SystemInstance.get();
        } catch (Exception e) {


 Any reason why this code is being repeated at certain places? I know i have
seen more of these, but cannot remember the rest of the occurrences. I can
certainly find them using "search" in eclipse. I think no piece of code
should call SystemInstance.init(System.getProperties()) except for
org.apache.openejb.cli.MainImpl.main. I might be wrong here, but any
clarifications would be helpful

On 2/8/07, David Blevins <da...@visi.com> wrote:
>
>
> On Feb 7, 2007, at 10:32 PM, Vamsavardhana Reddy wrote:
>
> > I didn't realize that I am responding to openejb-dev list :o( .
> > Ignore my
> > post on adding geronimo to the filename.
>
> No sweat :)  No harm no foul.  Substitute openejb for geronimo and
> it's still a good suggestion worth talking about.
>
> Q: "Should we add openejb to the filename and call it openejb-
> system.properties?"
>
> I thought about that and two thoughts come to mind:
>
>    -  The first is that we'd be adding all the properties to the
> actual System.getProperties properties instance, so it's really not
> openejb specific at all.  People could use it to add any properties
> to their apps or other systems we use like OpenJPA or ActiveMQ.
> Seems just about every library we use has at least one system
> property of some kind that can be configured.
>
>    -  The second thought is that we *do* have an OpenEJB-specific
> properties instance that kind of conflicts with the vm's system
> property concept.  There is an object SystemInstance which as a set
> of properties and that thing is more or less classloader scoped (i.e.
> there can be several of them in a vm, one for each OpenEJB
> instance).  For example in our Tomcat integration you can have one
> OpenEJB container system embedded in each webapp and they'll be
> completely isolated from each other and not bump into each other at
> all (this is an alternate to the global style tomcat integration).
> In that scenario each webapp gets it's own openejb.conf file and
> could have it's own openejb.properties file too, but those properties
> couldn't be added to the System.getProperties() instance as then each
> webapp would be overwriting every other webapp's data in what is
> supposed to be an isolated environment.  All the properties would be
> OpenEJB specific is they won't be in the System.getProperties()
> instance and only in the openejb-specific SystemInstance.getProperties
> () instance, so you wouldn't be able to use it to configure anything
> third-party libs as they're unlikely to check there.
>
> Other thoughts welcome as always.  Better solutions are made from
> trading alternate ideas, so be brave and post your thinking if you
> sees other solutions (that's always on the table and strongly
> encouraged).
>
> And thanks, Vamsi, a very good question regardless!
>
> -David
>
> >
> > Thanks,
> > Vamsi
> >
> > On 2/8/07, David Blevins <da...@visi.com> wrote:
> >>
> >> On Feb 7, 2007, at 9:28 PM, Vamsavardhana Reddy wrote:
> >>
> >> > Should we add geronimo to the filename and call it
> >> > geronimo-system.properties?
> >>
> >> The system property override feature has been around since OpenEJB
> >> 1.x  (e.g. it's not a geronimo thing).
> >>
> >> Ted Kirby posted a proposal and patch recently for similar
> >> functionality in Geronimo.  Check out:  http://
> >> marc.theaimsgroup.com/?
> >> t=116916235600001&r=1&w=2
> >>
> >> -David
> >>
> >> >
> >> > Vamsi
> >> >
> >> > On 2/8/07, David Blevins <da...@visi.com> wrote:
> >> >>
> >> >> Ok, throwing out another idea.  We've got a number of things
> >> that can
> >> >> be configured via system properties.  What do people think about
> >> >> having a file called system.properties we put in the conf/
> >> directory
> >> >> where people can put any properties they want and we will read
> >> them
> >> >> in and add them to System.getProperties().
> >> >>
> >> >> This would be in addition to the ability people already have to
> >> >> properties added to the system properties via -D args.  E.g.
> >> >>
> >> >>    ./bin/openejb start -Dfoo=bar
> >> >>
> >> >> We'd probably want the -D args to be applied after we read in the
> >> >> system.properties file so anything on the command line would win.
> >> >>
> >> >> We have a ton of things we can do with system properties
> >> already.  I
> >> >> started to write them into this email but moved it into a new
> >> >> confluence page as it was too big :)
> >> >>
> >> >>    http://cwiki.apache.org/OPENEJB/system-properties.html
> >> >>
> >> >> See this related jira (OPENEJB-451)
> >> >>
> >> >> Not to mention people may want to add their own properties for
> >> their
> >> >> apps.  See a related idea (OPENEJB-457)
> >> >>
> >> >> So what do people think?  Thumbs up?  Thumbs down?  <Insert your
> >> >> thoughts here>
> >> >>
> >> >> -David
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
>
>


-- 
Karan Malhi