Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] configuration issues

higgins-dev-bounces@xxxxxxxxxxx wrote on 06/11/2007 11:06:59 AM:

> 
> I've created a test project for the configuration.xml code.  (Not 
> yet checked in.)  I found a couple of issues:
> 
> 
> (1) A couple of the handlers (e.g., KeyStoreHandler) invoke the 
> MapHandler to read in their subsettings.  They do this by looking up
> the handler for "htf:map" in the SettingHandlers list.  It doesn't 
> seem safe to me to use the "htf:map" string, since the idea behind 
> the SettingHandlers list (I think) is to allow the config file 
> writer to use his own type designators.  (And it assumes that the 
> writer knows that a map handler must be listed, even if none of the 
> settings in his file use that type.)  I can think of a couple of 
> ways to at least mitigate this, but I wondered if anyone else thinks
> it's a problem.

Yeah - suspect just deriving the KeyStpre handler from the MapHandler is 
the right thing - then call super-> to deal with the nested settings 
beofre doing the keystore stuff - same for a few others.

> 
> 
> (2) The ContextFactoryHandler has nothing to do with ContextFactory 
> objects.  It just creates an object, which can be of any class.  (In
> the STS config file, it happens to be used to instantiate 
> ContextFactory objects.)   I recommend that we name it something 
different.

I assumed the ContextFactory would become a configurable component and 
this could go away. An alternative would be to make it a 
NonConfigurableComponentSetting or something like that.

> 
> 
> 
> (3) In order to run a test that parses a test.xml file, I have to 
> either user JRE 1.6.0_01 or include a jar called "jsr173_1.0_ri.jar"
> (downloaded from BEA), because java.xml.stream.Factory finder could 
> not find provider com.bea.xml.stream.MXParserFactory.  Is there 
> another way around this, or should I require JRE 1.6.0 for this 
> project?  (Someone else using StAX must have encountered this, right?)

The correct way to deal with this is to include wstx-asl-3.0.0.jar (from 
the Axiom distribution) on the classpath.

> 
> 
> ...Greg
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top