Well the jbossesb-properties.xml is designed to configure an ESB deployment and I can imagine scenarios where individual services may want to override or extend properties. We support that in TS at the moment and do it via two different property files (one for the core system and one for crash recovery). Could be something we can look at later: service specific config files. However, I agree that any TB specific properties should be handled by the TB.

Mark.



On 22 Mar 2007, at 17:59, Kurt T Stam wrote:

Well the TB adds some custom extentions. What if we add those extensions to a "trailblazer.properties" file? And then read just those?
That be much cleaner. The jbossesb.properties.xml is really server wide.

Tom Fennelly wrote:
Hmmmm, that's not a great solution really, is it??  It then means that all ESB deployments that use the PropertyManager for properties share the same config file.

I'll work on the basis that this is a fact of life - the TB will overwrite the .sar version (dodgy).

T.


Kurt T Stam wrote: 
You don't add the jbossesb-properties.xml to an .esb package. There is
only 1 and it goes in the jbossesb.sar.

Tom Fennelly wrote:
  
Hi guys.

I was having an issue which had all the hallmarks of the
PropertyManager not being able to find the jbossesb-properties.xml. 
As it turned out, it was finding "one", but not the "one" in the .esb
archive (the TB uses the PropertyManager for properties).  Instead,
it's picking up the jbossesb-properties.xml from the jbossesb.sar.
Any suggestions for a fix for this?  I can hack it by getting the TB
deplyment to overwrite the jbossesb.sar version for the file, but
that's poo :-)  I also tried scoping the .esb, but it didn't work (is
this disabled now Bill?).

T.
_______________________________________________
esb-dev mailing list
esb-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev
_______________________________________________
esb-dev mailing list
esb-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev