[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[xmlblaster-devel] Global/Property problems
(Sorry if this is posted two times, the first was sent from the wrong
mailing adress)
Hi,
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.
I think the property handling is broken in XmlBlaster: it is to complex,
and it is very hard to really get a consistent and forseeable result by
using the Property/util.Global/engine.Global API. There are to many
automatic ways the environment gets rewritten, reloaded or changed.
Unfortunately it is so complex that it is even hard to describe what's
broken.
Therefore an example.
Say we want to run XmlBlaster as an embedded service in JBoss
(XmlBlasterService) with a CorbaDriver. Here are some more
prerequisites:
* Full control over which properties are loaded ( no automagic loading
of properties file).
* System properties may not override xmlBlaster.properties since the xml
parser will be broken then.
* 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 can not handle ORBInitRef.type of properties wich has first
been loader from a property file and then converter to an args array,
i.e -ORBInitRef.NameService args is not valid as a an args to the
ORB.init method.
What we really want to do the is this:
1. Create an empty Global wich reads in System properties.
2. Manually load the property file.
3. Manually load jacorb.properties and populate Global.
4. Fill in any component specific configs.
This will however NOT work. Lets follow the logic.
First we look at all the possible ways of creating/getting a Global and
populate it.First of all though:
Global contains two different properties:
1. A Property object, which contains all properties, also the ones from
the "Environment", such as System.properties
2. An args array wich logically only should contains the "commandline"
arguments.
So heres how to create/get one.
Global.new() -> args will be null, and property be populated from
xmlBlaster.properties (looked up through Property.findPath),
System.properties (,no user props).
Global.new(Properties props) and Global.new(String[] args) -> property
is populated from xmlBlaster.properties (looked up through
Property.findPath), System.properties, user props from properties or
args. Global.args will also be set with props or args and Property will
be populated one more time with these.
Global.new(String[] args, boolean loadPropFile, boolean checkInstanc) ->
same as above, except that its possible to tell Property not to load the
propertyfile.
Global.new(Global glob) -> references to glob
Global.instance() -> either the first global created or Global.new(), no
way to tell when calling.
Global.getClone(String[] args) -> will take all properties in old Global
and create a new Global with these as argument. This effectively means
that the new Global will have the old Globals properties both in its
args and property object. With one exception: if its called with a non
null, non empty args, the new Globals args will be set with theses,
overwriting all the properties that was set. These will also be added to
the properties of the new Global.
Global.clone() -> same as above, except that no new args or properties
are set. .i.e all properties that the old Global contained will not be
both in Global.args and its Property.
This effectively means that:
1. Its impossible to create a Global with only "properties" and no args.
2. The only way to have other properties than args is to populate it
after it was created.
3. There is NO way of creating a new Global from a old Global that
really makes it look the same, i.e the args is the same in both and
properties is the same, since all properties in the old will be args in
the new.
4. There is no way to let System.properties override properties loaded
after
Global was created.
So, lets look at how to do the example.
// Create a global without automatic propertyfile expansion.
Global glob = new Global( null, false, false);
Properties p = loadPropFile();
g.getProperty().addArgs2Props( p );
Properties j = loadJacorbProps();
g.getProperty().addArgs2Props( j );
We now have a global, where properties was loaded from another, system
controllable properties file, and we have properties loaded for jacorb.
No Global.args is set at al.
This is the best we can do. Its not perfect, since it makes it
impossible to override properties in the loaded property file through
System.properties, but since we do not have full control over that
environment its probably the best thing to do.
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).
I must say I think this is a very confusing behaviour. My feeling is
that there are far to many roads on how the properties are set (and they
are set several times in some cases).
But, lets continue with the example. We have loaded the
jacorb.properties file, wich was in our util.Global instance. This file
must by definition contain entries like these to handle full
configuration of Jacorb:
ORBInitRef.ImplementationRepository=http://www.x.y.z/~user/ImR_Ref
The problem with the Jacorb used in the current XmlBlaster is that
jacorb
does not accept these types of properties as commandline arguments. The
args part of ORB.init may therefore NOT contain entries looking like
this:
-ORBInitRef.ImplementationRepository http://www.x.y.z/~user/ImR_Ref
Either they must look like this:
-ORBInitRef.ImplementationRepository=http://www.x.y.z/~user/ImR_Ref
or
-ORBInitRef ImplementationRepository=http://www.x.y.z/~user/ImR_Ref
Both types are impossible to represent in a Properties object (with one
exception: if only one ORBInitRef variable is used at all, in wich case
it could be written like this in the propertyfile:
ORBInitRef=NameService=corbaloc:iiop:localhost:7608/StandardNS/NameServer-POA/_root)
Since XmlBlaster effectively instantiates the orb like this:
org.omg.CORBA.ORB.init(glob.getArgs(),properties);
This means that the orb is given an argument that may previously have
lived in a properties object, which will result in the following error:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
stackTrace=java.lang.StringIndexOutOfBoundsException: String index out
of range: -1
at java.lang.String.substring(String.java:1480)
at org.jacorb.orb.ORB.set_parameters(ORB.java:1324)
at org.omg.CORBA.ORB.init(ORB.java:337)
at
org.xmlBlaster.protocol.corba.OrbInstanceFactory.createOrbInstance(OrbInstanceFactory.java:183)
at
org.xmlBlaster.protocol.corba.CorbaDriver.init(CorbaDriver.java:165)
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.
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.
//Peter
--
------------------------------------------------------------
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
------------------------------------------------------------