Re: [ebxmlms-develop] Web admin and other contributions?

[Ronald v. K. <rv...@ab...>]

Patrick Yee wrote:

> Ronald van Kuijk wrote:
>
>> Yes, sounds obvious,  I'm looking into one new 'hook' now. My 
>> JMSMonitor should not be included in the core since it  makes it j2ee 
>> dependend. What I'm doing now is make a 'Monitors' object that reads 
>> something like this from the general config:
>>
>> <Monitors>
>>   <MonitorItem>
>>      <Class>tld.mycompany.monitor.MyMonitorImpl</Class>
>>      <ConfigFile>/my/configFile.xml</ConfigFile>
>>   </MonitorItem>
>>   <MonitorItem>
>>      .....
>>    </MonitorItem>
>> </Monitors>
>>
>> Even the MailMonitor that you provide by default could be included 
>> this way, and instead of the ConfigFile reference the properties 
>> could in the default configfile e.g. with a <Properties> tag instead 
>> of  <ConfigFile> This currently works great for me and keeps the 
>> default distribution clean of j2ee dependend things.
>>
> Is the proposed JMS Monitor for dispatching received message (like 
> what Philipp proposed)? Or it's for getting incoming message from the 
> internet (like what MailMonitor is doing)? I am a bit confused. I like 
> the concept of keeping the distribution clean and making the 
> configuration independent.

Mine was for dispatching, but I was also looking at the receiving part 
(like what Philipp did). We (Philipp and I) already discussed this and I 
proposed to him to not make hermes directly dependent on JMS classes and 
do something like I described above.

>
>> This is exactely what I've been banging my brains on as well. 
>> Especially in relation to clustering. I have some Ideas on how to 
>> make it pluggable as well so a 'simple' servlet based version uses 
>> the implementation like it is now, and for clustered versions there 
>> is maybe a dependency on j2ee things.
>>
> Please share more on this. Thanks. :-)
>
Ok.... I'll draw up some ideas this evening and post them to the list. 
It would make the scalable hermes dependend on some j2ee things, since I 
do not like to use e.g. jgroups on a level where j2ee functionality is 
available)

>> Is there any reason not to call the current HEAD in cvs version 1.0?
>>
> We have to wait for the completion of internal testing here. Another 
> team in our center will use Hermes to do consultancy projects. 
> Therefore, we are doing some quality assurance testing now.
>
Great, I saw there have been some security integration tests going on in 
the far east and that you guys were part of it. Any chance on sharing 
results?

Ronald