Re: [xmlblaster-devel] Global/Property problems

[Marcel Ruff <mr at marcelruff.info>]

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

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


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


regads,

Marcel

--
http://www.xmlBlaster.org