Skip to main content

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

Thanks -- I'll just leave the ContextFactoryHandler as is for now.  As you said, the need for it will probably go away.

...Greg


Michael McIntosh wrote:
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
    
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
  


Back to the top