[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] Global/Property problems

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?

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.

Here's a longer explanation (with some more classloader stuff ;-))

Properties p = new Properties();
Global g = new Global(p);

Lets see what happens!

      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).

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 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.

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:


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.