[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Global/Property problems
On Fri, 2003-08-29 at 11:16, Marcel Ruff wrote:
>
> > Yea, that was a nice clean. Looks much better now. I still see a couple
> > of problems though.
> >
> > 1. Redundancy in property handling:
> >
> > When creating a global with argument, these will be loaded twice:
> >
> > First in Global.initProps (through Property.loadProps) and then in
> > Global.init (through Property.addArgs2Props ).
>
> I'm out of house now,
> are you willing to fix it yourself?
I am not sure which is the best way to do it, since it is used
internally to do something, and externally to do some additional things.
It's not a stopper, just unnecessary
>
> >
> > 2. Redundancy in property file loading:
> > When Global is created to load a propertyfile, but also with args that
> > contains a propertyFile argument, both property files will be loaded if
> > found, and the later will only agument, but not remove, any settings in
> > the default xmlBlaster.properties file.
>
> Yes, in fact i depended on this behavior in some projects already
> (cascading of two property files) - first have a project global
> setting and a minimal added onto it for different cluster instances.
>
Makes it truly hard to *remove* features in the "minimal" properties
files, such as drivers, plugins...
> >
> > Here's a longer explanation (with some more classloader stuff ;-))
> >
> > Properties p = new Properties();
> > p.setProperty("propertyFile","minimal.properties");
> > Global g = new Global(p);
> >
> > Lets see what happens!
> >
> > this(Property.propsToArgs(props));
> > this(args, true, true); i.e public Global(String[] args,
> > boolean loadPropFile, boolean checkInstance) is called.
> >
> > First it will run initProps. There the xmlBlaster.properties will first
> > be loaded, then System.properties and lastly the given p:s will be set.
>
> System.properties is the first to load (and weakest).
>
No.
// 1. Read user supplied properties file
if (info != null) {
InputStream inputStream = info.getInputStream();
//...
// 2. Read system environment, e.g. java -Dname=joe
if (scanSystemProperties == true) {
//..
// 3. read user supplied String[], e.g. command line parameters
if (argsProps != null) {
addArgs2Props(jutilsProperties, argsProps);
}
But generally system properties is troublesome. In standalone mode it's
easy to override properties set in the propertyfile on the command line,
but in a managed environment, the only way to do that is by -D to the
JVM. On the other hand it is much harder to control what all the other
components in the server is doing with system properties. The reasonable
way is therefore to let the embedded version load its properties after
System.properties.
> >
> > Then it will run init(args). This will Call
> > property.addArgs2Props(args);
> >
> > And what will happen there? Eventually private void
> > addArgs2Props(Properties props, Properties argsProps) will be called.
> > Here it will look for a propertyFile property and load the file if
> > found. But hey: the default xmlBlaster.properties file has already been
> > loaded! Anything that it contained, that the minimal.properties does not
> > define, will therefore still be available. This means, if I have
> > understood this correctly, that the only way of really getting only your
> > own properties is to also place an empty xmlBlaster.properties in home
> > or somewhere else in the search path.
>
> Yes - or just have none, the first xmlBlaster.properties should
> be identical to the default behavior.
>
> >
> > Ad to this that if the given property file is to be loaded by the
> > classloader, it MUST be available to the same classloader (or parent)
> > that happened to load the Property class. This is really often not the
> > case for application servers.
> >
> > Say we place xmlBlaster.jar och jutils.jar in the server global
> > classpath. We then have a component that uses XmlBlaster. This component
> > is run in its own classloader (trully a typical scenario). The component
> > contains the minimal.properties. The initialization will run with the
> > context classloader of the component. When Property tries to lookup the
> > file it will fail, since it uses the classloader that loaded itself to
> > lookup the resource: ClassLoader loader =
> > Property.class.getClassLoader();
> >
> > Property will therefore only be able to look up property files in its
> > own classloader and its parent, because the component context
> > classloader will not be visible to the loader that loaded Property.
> >
> >
> > This is actually a general problem i XmlBlaster. See next mail. Also see
> > below.
>
> If i get you right: The System classloader loads xmlBlaster.jar (containing
> the property files) but the classoader loading the Property class is not the same?
> I was assuming that the component classloader loads xmlBlaster.jar.
The other way around. In my case with JBoss, the component classloader
loads xmlBlaster.jar. Since Jacorb uses the system classloader to find
jacorb.properties it will not find it since it is in a child
classloader.
>
>
> >>If you remove jacorb.properties form xmlBlaster.jar you can put a jacorb.properties file into your
> >>home directory which you can use configure JacORB behavior. Note that if there is a file in
> >>xmlBlaster.jar this has precedence.
> >
> >
> > This is only true if XmlBlaster.jar is vissable to the system
> > classloader. That is often not the case in an embedded environment. I
> > also generally do not think that a property file in home is the way to
> > go for these types of setups where you might very well have several
> > instances running on the same machine with different settings. It also
> > makes installation/configurations more problematic since you always have
> > to remember these files.
>
> The assumption that
> HOME 1 <=> 1 cluster node
> is not applying in such a case so the xmlBlaster.properties
> should in some case not be thrown into $HOME
>
> > I will also try to put together a mail describing the problems I see
> > with the way classloading is handled in XmlBlaster.
>
> You are welcome to code/change your classloader solutions as well :=)
> You'll be the third coder digging into it, here are some tiny REQs:
>
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/util.classloader.ClassLoaderFactory.html
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/util.classloader.PluginClassLoader.html
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/util.classloader.XmlBlasterClassLoader.html
>
> Heinrich has coded a lookup path for plugin specific jars as
> subdirectories of xmlBlaster/lib with the package name of the plugin,
> i think he has not documented his approach so you need to check the code.
>
Yea. I have looked at it several times, but finds it quite hard to
follow. I have no upfront solution right now, although I find that the
ClassLoaderFactory is somewhat not a factory since its signature really
contains implementation classes.
Classloading is a messy business.
//Peter
>
> regads,
>
> Marcel
>
> --
> http://www.xmlBlaster.org
--
------------------------------------------------------------
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------