Re: [xmlblaster-devel] Global/Property problems

[Peter Antman <pra at mint.se>]

On Fri, 2003-08-29 at 02:23, Marcel Ruff wrote:
> Peter Antman wrote:
> > (Sorry if this is posted two times, the first was sent from the wrong
> > mailing adress)
> > 
> > Hi,
> 
> Hi as well,
> 
> > I am having problems updating the JBoss support in XmlBlaster. One of
> > the problems has to do with the way Global works. Therefore this rather
> > long mail.
[snip]
> But i think after cleaning up the code (see below) it should
> not be necessary.
> 

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

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. 

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.

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.

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.
> > 
> > * System properties may not override xmlBlaster.properties since the xml
> > parser will be broken then.
> 
> System properties are weakest in xmlBlaster.
> They can be switched off in jutils:
> 
>    public Property(String fileName, boolean scanSystemProperties,
>                    String[] args, boolean replaceVariables)
> 
> we could forward this possibility to Global if necessary.
> 
> > 
> > * Jacorb will not be able to load its propertyfile the normal way since
> > it uses the system classloader to find it, which almost never works in
> > embedded environments (XmlBlaster has these types of problems to).
> 
> JacORB is configured with the jacorb.properties file.
> The xmlBlaster/lib/xmlBlaster.jar file contains a copy of this template file which is loaded by 
> JacORB via the CLASSPATH and configures JacORB accordingly.
> 
> 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.

When for example deploying XmlBlaster as a component i JBoss, Jacorb
will not be able to look up the jacorb.properties file in the classpath,
since XmlBlaster is loaded as a component, and not in the system
classpath. To work around this, the jacorb.properties (or eqvivalent)
must be loaded manually.

The way you have changed OrbInstanceFactory should solve this though.
[snip]

> 
> > Well, what happens when EmbeddedXmlBlaster is started? Depending on
> > which classloader strategy is use either new Main(glob) or
> > Main.init(glob)will be called. What happened there?
> > 
> > In the first case a engine.Global is created: new engine.Global(glob).
> > In the second case a engine.Global is created, but like this: new
> > engine.Global(glob, true).
> > 
> > In both cases this results i  a call to util.Global (which is the
> > superclass):
> >      
> > super(Property.propsToArgs(utilGlob.getProperty().getProperties()),
> > true, false); // the boolean propertyOnly is not used at all in the
> > latter case
> > 
> > WOAW, what happened here?
> > 1. The property file is loaded once again!
> > 2. All properties in utilGlob is also set as args in the new Glob
> > 3. Any args from utilGlob is forgotten (but are there anyway as part of
> > all the properties).
> 
> This looks buggy indeed, it should be fixed now (see cvs).

Yeah!

[...]
> > Yes, this was a rather long mail and the example problem described here
> > is possible to solve by manipulating the jacorb.properties file. The
> > reason I wrote this long mail anyhow is that I think that the handling
> > of the Environment/Properties in XmlBlaster is confusing. I have done
> > three integrations round with XmlBlaster, and during all three I have
> > been forced to relearn how the properties are handled and have had large
> > problems handling all side effects that are built into this.
> 
> We try to improve, thanks for such a detailed report!

;-)

I will also try to put together a mail describing the problems I see
with the way classloading is handled in XmlBlaster.

//Peter
> 
> > 
> > I have no good solution; perhaps this mail could be the start of such a
> > discussion. But at least one thing out to be done emediately: when
> > cloning or creating a new Global with global as argument no property
> > file loading should be done and the objects should look the same
> > regarding args and properties.
> 
> This should be fixed now, see the current cvs.
> 
> best regards,
> 
> Michele and 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
------------------------------------------------------------