ebxmlms-develop — Development discussions

[ebxmlms-develop] Finally figured SSL incompatibility out (includes fix)

[Mattias J <mj...@ex...>]

Hi again.
As I have also mentioned on the general list I was unable to send messages 
using the HTTPS protocol with JDK 1.4 without making a non-JDK 
1.3.1-compatible change to the hk.hku.cecid.phoenix.message.transport.Http 
class. I have now spent most of this day reading source code, forum posts 
and articles and testing, and believe I now have understood the problem and 
am able to provide a suggestion on how to solve this issue. I bet most of 
you understand these things much better than I do, but since the current 
code is erroneous I will try to explain some fundamentals as I understand them.

Background
What instance of java.net.URLConnection is used when opening a connection 
to any given java.net.URL will be decided by a java.net.URLStreamHandler. 
The URLStreamHandler used depends on the package names set up in the 
java.protocol.handler.pkgs system property. (Please see 
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html#URL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String) 
for more information about this).

For Java 1.3.1 (with the JSSE add-on) the URLStreamHandlers we want for 
HTTP and HTTPS is in the com.sun.net.ssl.internal.www.protocol package. The 
class used for HTTPS connections extends com.sun.net.ssl.HttpsURLConnection.
For Java 1.4 the default handlers reside under the sun.net.www.protocol 
package. The HTTPS connection class extends the new (non JDK 1.3.1 
compatible) javax.net.ssl.HttpsURLConnection. But there is also a backwards 
compatible handler under the com.sun.net.ssl.internal.www.protocol package 
(which in some manner wraps classes from javax.net.ssl, which I believe was 
what Ronald van Kuijk tried to explain to me).

Problem
Since the MSH is supposed to be Java 1.3.1 compatible, we cannot use the 
javax.net.ssl classes, since this would produce 
java.lang.NoClassDefFoundError (which according to my tests can be caught, 
but that is an ugly solution in comparison to what could be done, 
especially since it won't compile under 1.3.1 anyway). So, for key 
manager/trust manager (and proprietary hostnameVerifier) to be used, the 
connection must be an instance of com.sun.net.ssl.HttpsURLConnection (as of 
line 381 and forth in hk.hku.cecid.phoenix.message.transport.Http rev 
1.12). As stated above, for the backwards compatible handler to be used in 
Java 1.4, the com.sun.net.ssl.internal.www.protocol package must be 
mentioned in the java.protocol.handler.pkgs system property. This might be 
the motivation for the following lines in 
hk.hku.cecid.phoenix.message.transport.Http (line numbers from rev 1.12):

368 URL url = new URL(toUrl);
369 if (url.getProtocol().equalsIgnoreCase
370     (Constants.TRANSPORT_TYPE_HTTPS)) {
371     String pkgs = System.getProperty(PROTOCOL_HANDLER_PKGS); // 
PROTOCOL_HANDLER_PKGS = "java.protocol.handler.pkgs"
372     if (pkgs == null || pkgs.indexOf(SSL_WWW_PROTOCOL) < 0 ) { // 
SSL_WWW_PROTOCOL = "com.sun.net.ssl.internal.www.protocol"
373         pkgs = (pkgs == null ? SSL_WWW_PROTOCOL :
374                 SSL_WWW_PROTOCOL + "|" + pkgs);
375         System.setProperty(PROTOCOL_HANDLER_PKGS, pkgs);
376     }
377 }

The problem here is that the system property is set AFTER the URL is 
constructed. The URLStreamHandler used for the URL is decided inside the 
URL constructor, so when the code above changes the system property, the 
new implementation from the sun.net.www.protocol package will already have 
been chosen, and the com.sun.net.ssl.HttpsURLConnection dependent code will 
not be run.

Please note that it is NOT enough to move the setting of the system 
property before the URL creation on line 368. This is because the 
URLStreamHandler for a given protocol (in our case the HTTPS protocol) will 
be cached inside the java.net.URL class. So after the first HTTPS instance 
of java.net.URL has been created, they will all have the same connection 
implementation (or at least the same handler; this is unless the handler is 
explicitly provided to the constructor). For example, while trying to find 
a solution for this whole problem this I found myself getting the wrong 
implementation because there were MSHConfig records in the database having 
HTTPS toMshUrls being instantiated as soon as the MSH was started (on line 
2865 of hk.hku.cecid.phoenix.message.handler.MessageServer).

Solution
Currently I have put the code to fix the system property in a static block 
in hk.hku.cecid.phoenix.message.transport.Http
     // Configure SSL connections to use pre JDK 1.4 protocol handlers
     static {
         String pkgs = System.getProperty(PROTOCOL_HANDLER_PKGS);
         if (pkgs == null || pkgs.indexOf(SSL_WWW_PROTOCOL) < 0 ) {
             pkgs = (pkgs == null ? SSL_WWW_PROTOCOL :
                 SSL_WWW_PROTOCOL + "|" + pkgs);
             System.setProperty(PROTOCOL_HANDLER_PKGS, pkgs);
         }
     }

I believe though there will be a more proper place to put this (I'm not 
sure what effect dynamic class loading has on static blocks, for example), 
such as at configuration time or in the MessageServiceHandler.init(), but I 
leave that up to you guys.


   Mattias Jiderhamn
   Expert Systems

[ebxmlms-develop] Fix for TrustedAnchor

[Mattias J <mj...@ex...>]

Hi Hermes developers. I have been in a discussion on the user list, 
primarily with Ronald van Kuijk, about issues concerning trusted SSL 
certificates and Java 1.4. I asked that somebody should forward my 
conclusions to the development list but I can see in the archives that has 
not been done (is everyone else on vacation???). Now I have had time to 
perform some actual testing under Java 1.3.1 so I have joined the dev-list 
to discuss the changes that need to me made.

First off, the TrustedAnchor setting is not working, and I cannot see how 
it could have been working since revision 1.7 of 
hk.hku.cecid.phoenix.message.transport.Http and the introduction of the 
attibute TrustManager[] trustManagers, clashing with the local variable of 
the same name (existing since rev 1.6).

I discovered the problem trying to use a setting similar to the following 
under JDK 1.4 and have now verified it does not work under 1.3 either:
   <SSL>
        <!-- Trust keystore for SSL Server Authentication -->
        <TrustedAnchor>
          <KeyStore>
            <Path>/hermes</Path>
            <File>trusted.keystore</File>
            <Password>foobar</Password>
          </KeyStore>
        </TrustedAnchor>
    </SSL>

The problem is solved by removing the local TrustManager[] trustManagers 
variable on line 185 of hk.hku.cecid.phoenix.message.transport.Http so that 
the attribute is used instead. Line 186 could also be removed, since that 
variable is never used. Here is a diff applicable to revision 1.12:

185,186d184
<         TrustManager[] trustManagers = null;
<         KeyManager[] keyManagers = null;

Please incorporate this into the CVS.


   Mattias Jiderhamn
   Expert Systems 

Re: [ebxmlms-develop] Beyond hermes 1.0

[Philipp B. <pb...@we...>]

Hi Patrick,

Please let me tell you my point of view about hermes and jms.
I like the idea of Ronald to see the monitors of hermes as a plugin. I think it is not much work to create an interface for the monitors and extract it to a plugin that can be easily configured. With a class (MessageServiceHandler) that has more then 5000 lines of code it would be a good option.

But to make the other way more flexible is much more complicated. I see the problem in the fact that hermes is not designed to push the message to the client. I have problems to find the right way to modify hermes for my needs.

How I told in a post before, my modified hermes put all messages to a queue. But in my opinion this is a very dirty solution. My hermes modifications have dependencies to jms classes. The goal would be that only a plugin has these dependencies.

My whish is that it would be possible to configure in msh.properties.xml the plugin and the fitting ApplicationContext.

Hermes is a great product, please see this mail as feedback of an user. And if you know a way how I can reach my goal please let me know.

Regards Philipp

____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

Re: [ebxmlms-develop] ebxmlms and hsqldb

[Philipp B. <pb...@we...>]

Hi Patrick,

The hsql works on my pc now. But I ran into some problems. The function setTransactionIsolation in hsql only supports READ_UNCOMMITTED. But it is not easy to find the error when hermes only reports an unknown error.

It would be a help for a user if hermes would put the main exception in an innerexception.

Regards Philipp

ebx...@li... schrieb am 05.07.04 08:54:13:
> 
> I tried the in-process mode. It needs no special handling at all. You 
> only have to make sure that the file path in the JDBC URL exists.
> Regards, -Patrick
> 
> Ronald van Kuijk wrote:
> 
> > Hi,
> >
> > Did anyone ever configure hermes to run with hsqldb? I did not run 
> > into problems yet, since I did not even try it, but if someone has, I 
> > hope to do it right the first time.
> >
> > Ronald
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop


____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

[ebxmlms-develop] SOAP Faults - faultcode value requires qualified name?

[Johnson T. <joh...@ya...>]

I have just started looking at ebxmlms as a library
for embedding into an application I'm working on. 

I noticed when I was testing its error handling
functionality that the generated SOAP Fault messages
contain, for example, "Client" as the faultcode value.
As I understand it, the SOAP spec requires that the
value of the faultcode element be a qualified name and
therefore should be, for example, "soap-env:Client".

Is there something that I don't understand here?


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [ebxmlms-develop] Beyond hermes 1.0

[Patrick Y. <kc...@ce...>]

My view:
- A dispatcher is a piece of code (module) receiving requests to send 
(dispatch) a message on behalf of  internal applications
- A transport handler is a piece of code (module) sending messages to 
other MSH's (currently smtp and http)
- A monitor is a piece of code (module) receiving messages from the 
internet (currently imap and http)
- A delivery handler is a piece of code  (module) delivering messages to 
applications

Regards, -Patrick


Ronald van Kuijk wrote:

>
> Question about terminology:
> - A dispatcher is a piece of code (module) receiving requests to send 
> (dispatch) a message on behalf of  internal applications
> - A ..... is a piece of code  (module) sending messages to other MSH's 
> (currently smtp and http)
> - A monitor is a piece of code (module) receiving messages from the 
> internet (currently imap and http)
> - A ..... is a piece of code  (module) delivering messages to 
> applications
>
> What should be on the dotted lines?
>
>

Re: [ebxmlms-develop] ebxmlms and hsqldb

[Patrick Y. <kc...@ce...>]

I tried the in-process mode. It needs no special handling at all. You 
only have to make sure that the file path in the JDBC URL exists.
Regards, -Patrick

Ronald van Kuijk wrote:

> Hi,
>
> Did anyone ever configure hermes to run with hsqldb? I did not run 
> into problems yet, since I did not even try it, but if someone has, I 
> hope to do it right the first time.
>
> Ronald

[ebxmlms-develop] ebxmlms and hsqldb

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

Hi,

Did anyone ever configure hermes to run with hsqldb? I did not run into 
problems yet, since I did not even try it, but if someone has, I hope to 
do it right the first time.

Ronald

[ebxmlms-develop] Beyond hermes 1.0

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

Patrick Yee wrote:

> Ronald van Kuijk wrote:
>
>> One thing I like to do there is move the Command object internal into 
>> Hermes and not expose it to the outside world. Each monitor is then 
>> responsible for mapping a request into a Command object. e.g.
>> - an xml structure can have all command elements in tags
>> - a jms monitor gets the command elements from jms headers
>> - a servlet monitor gets it from request parameters
>>
>> This is exactely what I was proposing on the other thread by 
>> splitting the use of the one servlet into separate things. Each 
>> implementation of a monitor is then also responsible for their own 
>> authentication (which I hope will one day be based on the principal 
>> from the servlet/j2ee engine
>>
>> Ronald
>>
> I agree with this totally. Thanks for the idea, Ronald.
> Regards, -Patrick
>
I'd be more than happy to give this a first try. It would make a web-gui 
much easier to build etc...

Question about terminology:
- A dispatcher is a piece of code (module) receiving requests to send 
(dispatch) a message on behalf of  internal applications
- A ..... is a piece of code  (module) sending messages to other MSH's 
(currently smtp and http)
- A monitor is a piece of code (module) receiving messages from the 
internet (currently imap and http)
- A ..... is a piece of code  (module) delivering messages to applications

What should be on the dotted lines?


Short proposal
------------------------------

The following are fully 'internal' to hermes
- One default MSH servlet for receiving messages from the internet
- One configurable MailMonitor for receiving messages from the internet
- One servlet for receiving commands from the fat-client monitor 
application (excluding the sending of messages, just the 
start/stop/archive/.... commands

Configurable:
- One servlet for receiving 'dispatch message' requests, NOT using the 
command object (this will be a default for hermes, but in a configurable 
way)
- One JMS listener for receiving 'dispatch message' requests, NOT using 
the command object (this will *not* be default in hermes, but in a 
contrib dir and used in a configurable way.

<Dispatchers>
    <DefaultServletDispatcher>ON</DefaultServletDispatcher>
    <DispatcherImpl>
         <Class> ......... </Class>
         <ConfigFile>....... </ConfigFile>
     </DispatcherImpl>
    <DispatcherImpl>
         <Class> ......... </Class>
         <ConfigFile>....... </ConfigFile>
     </DispatcherImpl>
</Dispatchers>

Delivering messages to applications is currently done by dynamically 
registering a url.  Besides this form, I'd like to have a 
preconfigurable way. Kind of registering a context in the admin.
- File
- HTTP
- JMS (again the jms/url 'discussion")
- XMLRPC? / SOAP

Security (who has access to a certain dispatchers and how should that be 
configured?) is a thing that has to be worked out. I would propose to 
have the dynamic registration like there is now only in a development 
mode. For a production mode dynamic registration should be off. Security 
can than be worked out by using normal java security and detecting the 
role a user is in when he accesses a certain dispatcher.

Ronald

P.S. I cross-posted to the development mailinglist to take the 
discussion there and changed the subject

Re: [ebxmlms-develop] jms feature

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

Patrick Yee wrote:

> Ronald van Kuijk wrote:
>
>> bitte sende es zu mir, bin sehr neugirig.
>
>
> What is this? :-)
>
This is me, by accident replying to Philipp and the list in the native 
(german) language of Philipp. My native language is dutch which is to 
some extend quite similar to german. The dutch are blessed with speaking 
many languages. I e.g. speak Dutch, German, English, French (no good 
writing) and a little Spanish.

The content was: "Please send it to me, I'm very curious"

Ronald

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

Re: [ebxmlms-develop] jms feature

[Patrick Y. <kc...@ce...>]

Ronald van Kuijk wrote:

> bitte sende es zu mir, bin sehr neugirig.

What is this? :-)

Regards, -patrick

Re: [ebxmlms-develop] jms feature

[Patrick Y. <kc...@ce...>]

Hi Philipp,
Thanks for the input. Your proposal is very much similar to Ronald's. I=20
guess we can get an aligned design on this.
Regards, -Patrick

Philipp Bolle wrote:

>Hi community,
>
>There was a discussion about a jms implementation with the title =93Web =
admin and other contributions? I work on the jBpm, same project like Rona=
ld.
>
>I would like to use hermes as my door to the internet. For that I change=
d hermes that all received messages are sent to a jmsqueue. The configura=
tion for my example looks like:
><Property>
>  <MSH>
>=85
>	<Queue>
>		<name>queue/A</name>
>	</Queue>
>
>Actually it is only a quick hack. But I am very interested to extend the=
 example. Is there anybody to whom I can send my  patch  and who can give=
 me a feedback?
>
>Tank you in advanced Philipp
>
>_______________________________________________________
>WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
>Informationen unter: http://freemail.web.de/?mc=3D021199
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
>digital self defense, top technical experts, no vendor pitches,=20
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>
> =20
>

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

[Patrick Y. <kc...@ce...>]

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.

> 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. :-)

> 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.

Regards, -Patrick

Re: [ebxmlms-develop] jms feature

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

bitte sende es zu mir, bin sehr neugirig.

Philipp Bolle wrote:

>Hi community,
>
>There was a discussion about a jms implementation with the title “Web admin and other contributions? I work on the jBpm, same project like Ronald.
>
>I would like to use hermes as my door to the internet. For that I changed hermes that all received messages are sent to a jmsqueue. The configuration for my example looks like:
><Property>
>  <MSH>
>…
>	<Queue>
>		<name>queue/A</name>
>	</Queue>
>
>Actually it is only a quick hack. But I am very interested to extend the example. Is there anybody to whom I can send my  patch  and who can give me a feedback?
>
>Tank you in advanced Philipp
>
>_______________________________________________________
>WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
>Informationen unter: http://freemail.web.de/?mc=021199
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

[ebxmlms-develop] jms feature

[Philipp B. <pb...@we...>]

Hi community,

There was a discussion about a jms implementation with the title =93Web admi=
n and other contributions=3F I work on the jBpm, same project like Ronald.

I would like to use hermes as my door to the internet. For that I changed =
hermes that all received messages are sent to a jmsqueue. The configuratio=
n for my example looks like:
<Property>
  <MSH>
=85
	<Queue>
		<name>queue/A</name>
	</Queue>

Actually it is only a quick hack. But I am very interested to extend the e=
xample. Is there anybody to whom I can send my  patch  and who can give me=
 a feedback=3F

Tank you in advanced Philipp

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/=3Fmc=3D021199

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

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

Patrick Yee wrote:

> Ronald van Kuijk wrote:
>
>> No problem, I haven't been working on it anyway, since I've been 
>> focussing on an xforms implementation which we (me and some others) 
>> want to integrate into a BPM/WFM/B2B/EAI solution based on opensource 
>> projects (ebxmlms, chiba, jbpm all on sourceforge). Glad you 
>> responded now. btw, did you guys switch of the commit mailinglist? I 
>> thought there hadn't been any changes since january, but after doing 
>> a compare I saw there have been changes, and good ones imo.
>>
> The commit mailing list doesn't work anymore and I don't know why. I 
> have to check with sourceforge.
>
<cut/>

> We have to admit that we don't have much experience in maintaining an 
> open source project like this.

Same goes for me :-)

> So as you can see our moves, it's easier for us to commit the changes 
> provided that it's a "hook" to the current architecture. I mean, 
> whenever there is a request for more flexible way to handle things, we 
> prefer to make it as a hook and let the developers make their own 
> handling implementation.

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.

> Refactoring is a far more complicated thing. In fact, we are aware of 
> the limitation of the current architecture. Internally, we have a 
> thought to rewrite the whole core architecture (Hermes 2.0?), while 
> hoping we can reuse the ebXML messaging handling part (e.g. those 
> methods in MessageServiceHandler).

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.

Is there any reason not to call the current HEAD in cvs version 1.0 and 
start refactoring certain parts (e.g. the dependency on the 
HttpServletRequest object for sending messages? So the frontend is 
already split into 3 parts (receiving messages from the external world, 
receiving requests to send messages from internal systems and a 
'command/configure' part.

> Another important goal we want to achieve is to support more B2B 
> messaging protocols (e.g. WS-ReliableMessaging and AS2). Given that, 
> the idea of refactoring is important and the impact is much higher. :-)

Can't wait. Would be perfect for the integration project I'm doing

>
>
>> Yes and no, the contribution is currently not to flexible 
>> configuration wise, although it has been running here since februari 
>> in a demo server (not doing to much I have to admit ;-) ). The 
>> contribution was primarily  to give an idea what the problems. I 
>> think a consesus has to be reached on how to refactor certain parts, 
>> which mainly are in the MessageServiceHandler. So no do not include 
>> it in the 1.0 release.
>
>
> Agreed. That fits our thoughts on Hermes 2.0 as well.
>
>> Any time and thank you (all) for this product. I'm reviving a wiki I 
>> set up long ago do also discuss these things with the other people 
>> I'm working with. The main thing is that we should agree on a roadmap 
>> and then I/we have plenty of time available to work on this.  There 
>> are some other things we have in mind, but I think you'll see them 
>> appear on the wiki (I'll send the link once it is ready)
>
>
> Great. We look forward to that. Thank you.

Best,

Ronald

[ebxmlms-develop] Re: AS2 for Hermes

[Patrick Y. <kc...@ce...>]

Hi Sacha,
Thank for the pointer. Yes, we are aware of that project. And we are 
still thinking of the core architecture to support it. I am sure we will 
talk to them when we get the a concrete idea on the "plugin" concept.
Regards, -Patrick

Sacha Schlegel wrote:

>>Hi Patrik
>>
>>I am sure you are aware of:
>>
>>http://www.openas2.org/
>>
>>You might get some collaboration with those people.
>>
>>Would be nice to have as2 just as plugin to Hermes.
>>
>>Kind regards
>>
>>Sacha
>>    
>>

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

[Patrick Y. <kc...@ce...>]

Ronald van Kuijk wrote:

> No problem, I haven't been working on it anyway, since I've been 
> focussing on an xforms implementation which we (me and some others) 
> want to integrate into a BPM/WFM/B2B/EAI solution based on opensource 
> projects (ebxmlms, chiba, jbpm all on sourceforge). Glad you responded 
> now. btw, did you guys switch of the commit mailinglist? I thought 
> there hadn't been any changes since january, but after doing a compare 
> I saw there have been changes, and good ones imo.
>
The commit mailing list doesn't work anymore and I don't know why. I 
have to check with sourceforge.


> I agree, it should be incremental. It contains three parts as I 
> recall. (one of them is lost locally)
> - using a jdbc datasource/connectionpool in stead of  the 'proprietary 
> one'   : priority low-medium, impact: medium   (this one is lost locally)
> - refactoring the MessageServiceHandler so there is easier (but 
> secure!) access to the commands (e.g. for a web interface (dropping 
> the swing gui would make it easier))
> - refactoring the 'monitor' part of the MessageServiceHandler so other 
> ways of sending messages could be achieved (e.g. a jms monitor ) : 
> priority High impact medium
>
> Things that make the refactoring difficult (although I think I've 
> created a nice solution) is the deep dependency on the 
> HttpServletRequest and HttpServletResponse objects. For receiving 
> messages/commands from an application I've already made some changes. 
> Probably not in the best way, It was just to see if it could be done. 
> I had to change private/protected into public in some places, so 
> securitywise it is probably not the best solution. Again, it was just 
> to get an idea of the road ahead. One thing I have not looked into is 
> the delivery of messages to an application. Since there is already a 
> configurable way to define your own listeners I did not touch that.
>
>

We have to admit that we don't have much experience in maintaining an 
open source project like this. So as you can see our moves, it's easier 
for us to commit the changes provided that it's a "hook" to the current 
architecture. I mean, whenever there is a request for more flexible way 
to handle things, we prefer to make it as a hook and let the developers 
make their own handling implementation. Refactoring is a far more 
complicated thing. In fact, we are aware of the limitation of the 
current architecture. Internally, we have a thought to rewrite the whole 
core architecture (Hermes 2.0?), while hoping we can reuse the ebXML 
messaging handling part (e.g. those methods in MessageServiceHandler). 
Another important goal we want to achieve is to support more B2B 
messaging protocols (e.g. WS-ReliableMessaging and AS2). Given that, the 
idea of refactoring is important and the impact is much higher. :-)


> Yes and no, the contribution is currently not to flexible 
> configuration wise, although it has been running here since februari 
> in a demo server (not doing to much I have to admit ;-) ). The 
> contribution was primarily  to give an idea what the problems. I think 
> a consesus has to be reached on how to refactor certain parts, which 
> mainly are in the MessageServiceHandler. So no do not include it in 
> the 1.0 release.

Agreed. That fits our thoughts on Hermes 2.0 as well.

> Any time and thank you (all) for this product. I'm reviving a wiki I 
> set up long ago do also discuss these things with the other people I'm 
> working with. The main thing is that we should agree on a roadmap and 
> then I/we have plenty of time available to work on this.  There are 
> some other things we have in mind, but I think you'll see them appear 
> on the wiki (I'll send the link once it is ready)

Great. We look forward to that. Thank you.

Regards, -Patrick

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

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

Patrick Yee wrote:

> Ronald,
>
> My apologies. Your previous mails in January have been staying in my 
> TODO mailbox for months. I wanted to review it but never have the time 
> to do so. :-(
>
No problem, I haven't been working on it anyway, since I've been 
focussing on an xforms implementation which we (me and some others) want 
to integrate into a BPM/WFM/B2B/EAI solution based on opensource 
projects (ebxmlms, chiba, jbpm all on sourceforge). Glad you responded 
now. btw, did you guys switch of the commit mailinglist? I thought there 
hadn't been any changes since january, but after doing a compare I saw 
there have been changes, and good ones imo.

> Hermes is an open source project. Clearly we should leverage on the 
> community effort to develop it. Therefore, we welcome your 
> contribution, the only obstacle out there is resource. Given this, it 
> would be helpful to us to keep the contribution incremental, so that 
> we can review and process the changes in a shorter time. If my 
> proposal is agreeable, we can work out a priority list for us to 
> process in the coming schedule.

I agree, it should be incremental. It contains three parts as I recall. 
(one of them is lost locally)
- using a jdbc datasource/connectionpool in stead of  the 'proprietary 
one'   : priority low-medium, impact: medium   (this one is lost locally)
- refactoring the MessageServiceHandler so there is easier (but secure!) 
access to the commands (e.g. for a web interface (dropping the swing gui 
would make it easier))
- refactoring the 'monitor' part of the MessageServiceHandler so other 
ways of sending messages could be achieved (e.g. a jms monitor ) : 
priority High impact medium

Things that make the refactoring difficult (although I think I've 
created a nice solution) is the deep dependency on the 
HttpServletRequest and HttpServletResponse objects. For receiving 
messages/commands from an application I've already made some changes. 
Probably not in the best way, It was just to see if it could be done. I 
had to change private/protected into public in some places, so 
securitywise it is probably not the best solution. Again, it was just to 
get an idea of the road ahead. One thing I have not looked into is the 
delivery of messages to an application. Since there is already a 
configurable way to define your own listeners I did not touch that.

>
>
> We are going to package and name the whole thing as 1.0. Before that, 
> we still have a couple of changes planned. Do you think your 
> contribution is mature enough to get into the 1.0 package?

Yes and no, the contribution is currently not to flexible configuration 
wise, although it has been running here since februari in a demo server 
(not doing to much I have to admit ;-) ). The contribution was 
primarily  to give an idea what the problems. I think a consesus has to 
be reached on how to refactor certain parts, which mainly are in the 
MessageServiceHandler. So no do not include it in the 1.0 release.

>
> Thank you for your effort!
>
Any time and thank you (all) for this product. I'm reviving a wiki I set 
up long ago do also discuss these things with the other people I'm 
working with. The main thing is that we should agree on a roadmap and 
then I/we have plenty of time available to work on this.  There are some 
other things we have in mind, but I think you'll see them appear on the 
wiki (I'll send the link once it is ready)

> Regards, -Patrick
>

Best,

Ronald

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

[Patrick Y. <kc...@ce...>]

Ronald,

My apologies. Your previous mails in January have been staying in my 
TODO mailbox for months. I wanted to review it but never have the time 
to do so. :-(

Hermes is an open source project. Clearly we should leverage on the 
community effort to develop it. Therefore, we welcome your contribution, 
the only obstacle out there is resource. Given this, it would be helpful 
to us to keep the contribution incremental, so that we can review and 
process the changes in a shorter time. If my proposal is agreeable, we 
can work out a priority list for us to process in the coming schedule.

We are going to package and name the whole thing as 1.0. Before that, we 
still have a couple of changes planned. Do you think your contribution 
is mature enough to get into the 1.0 package?

Thank you for your effort!

Regards, -Patrick


Ronald van Kuijk wrote:

> Hi all,
>
> It has been discussed before on this list, but I'd like to discuss it 
> a little again. There are some things, especially sending messages to 
> Hermes, that are really integrated with the servlet front-end. A 
> request object is used alot in places where imho a more abstract 
> approach could be used. The reason I ask this is we are now working on 
> realy integrating Hermes in an open source  BPM/WFM/B2B/EAI solution. 
> Sending messages from within the same appserver via a http connection 
> seems to me not the right way to go. The same is true for configuring 
> Hermes, it can currently only be done via the standalone client via http.
>
> A long time ago I changed some things in my local version of hermes, 
> so sending messages could also take place in a more direct manner, 
> either by calling a certain class or using a jms queue. I even made it 
> configurable, so it is not required to have JMS installed for 
> using/compiling it in just a servlet engine.  for configuring the 
> server I made a small web interface that allows you to configure 
> currently 40% of the things.
>
> Are the project owners interested in these changes and willing to 
> accept a temporary decrease in stability in exchange for flexibility 
> of the application? We could first discuss the changes, since I'm 
> willing to adapt it to everybodies liking.
>
> Kind regards,
>
> Ronald

[ebxmlms-develop] Web admin and other contributions?

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

Hi all,

It has been discussed before on this list, but I'd like to discuss it a 
little again. There are some things, especially sending messages to 
Hermes, that are really integrated with the servlet front-end. A request 
object is used alot in places where imho a more abstract approach could 
be used. The reason I ask this is we are now working on realy 
integrating Hermes in an open source  BPM/WFM/B2B/EAI solution. Sending 
messages from within the same appserver via a http connection seems to 
me not the right way to go. The same is true for configuring Hermes, it 
can currently only be done via the standalone client via http.

A long time ago I changed some things in my local version of hermes, so 
sending messages could also take place in a more direct manner, either 
by calling a certain class or using a jms queue. I even made it 
configurable, so it is not required to have JMS installed for 
using/compiling it in just a servlet engine.  for configuring the server 
I made a small web interface that allows you to configure currently 40% 
of the things.

Are the project owners interested in these changes and willing to accept 
a temporary decrease in stability in exchange for flexibility of the 
application? We could first discuss the changes, since I'm willing to 
adapt it to everybodies liking.

Kind regards,

Ronald

Re: [ebxmlms-develop] EbxmlMessage(File file) throws an 'Absent Content-Type Exception'

[Bob K. <py...@ce...>]

Dear Mo=EFses,

Thanks for your report on this bug, but I found that I have fixed and=20
committed to the CVS. (Checking the CVS log, the bug fix is committed on=20
1st April 2004, Revision 1.45 of EbxmlMessage.java)
You can checkout the source again and we whether it works now.

Regards,
Bob Koon

Olivier Mo=EFses wrote:

> Sorry for the cross posting, but I don't know where exactly put this=20
> mesage.
> I use MSH v.pre-1.0.0.0, build from cvs (date : approx 11/03/2004).
> I use only mail messaging.
>
> When I try to build a new EbxmlMessage using EbxmlMessage(File file),=20
> I get a javax.xml.soap.SOAPException: Cannot parse SOAP message
> The message is a Ack generated by MSH in the server repository.
> This ack doesn't have any content-type header.
> After investigations, I get :
> javax.xml.soap.SOAPException: Absent Content-Type at=20
> com.sun.xml.messaging.saaj.soap.MessageImpl.<init>(MessageImpl.java:86)
> at=20
> com.sun.xml.messaging.saaj.soap.MessageFactoryImpl.createMessage(Messag=
eFactoryImpl.java:32)=20
> at=20
> hk.hku.cecid.phoenix.message.packaging.EbxmlMessage.getMessageFromDataS=
ource(EbxmlMessage.java:1681)=20
>
> at=20
> hk.hku.cecid.phoenix.message.packaging.EbxmlMessage.<init>(EbxmlMessage=
.java:241)=20
>
>
> The documentation says about this constructor: construct an=20
> EbxmlMessage from File using the logic in MessageServer. The file must=20
> not contain any content header like Content-Type
>
> In EbxmlMessage.getMessageFromDataSource (about line: 1673), the=20
> following is commented :
> /*
> final MimeHeaders headers =3D new MimeHeaders();
> headers.addHeader(Constants.CONTENT_TYPE, Constants.TEXT_XML_TYPE);
> */
>
> this explains why the code fails.
> The problem is that an ack must be loaded when retrying to send it,=20
> and it causes error.
>
> Shall I uncomment the two lines ?
>
> thanks
>
> Regards
> Olivier Moises
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle=20
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

Re: [ebxmlms-develop] acknowledgment query

[Patrick Y. <kc...@ce...>]

Then you should call sendReliably(msg, false);
Regards, -Patrick

mlr...@cs... wrote:

>where can we find the sendReliably() API? to get more info abt
>that.
>
>and i dont want ack digitally signed , but i just want to send 
>a message to the source that message has been received at the
>destination.
>
>
>
>with regards
>
>
>
>On Thu, 6 May 2004, Patrick Yee wrote:
>
>  
>
>>Hi,
>>sendReliably() takes 2 parameters. The first one is the ebXML message to 
>>be sent. The second one is a boolean flag, indicating whether you 
>>request the Ack to be digitally signed.
>>Hope this helps.
>>Regards, -Patrick
>>
>>
>>mlr...@cs... wrote:
>>
>>    
>>
>>>Thanks,
>>>wht parameters should be passes through request.sendReliably().?
>>>
>>>
>>>Please provide more details on this.
>>>
>>>
>>>
>>>
>>>
>>>
>>>With Regards
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Wed, 5 May 2004, Patrick Yee wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>For Hermes, you can call request.sendReliably(). Then, Hermes will 
>>>>   
>>>>
>>>>        
>>>>
>>>attach the appropriate AckRequested element to the SOAP message. 
>>>And the destination system, if it's sensible, will generate an 
>>>Ack back to Hermes.
>>> 
>>>
>>>      
>>>
>>>>But, since the Acks are in the ebMS layer, the application will not get 
>>>>noticed when receiving the Acks. If you want to get noticed, you have to 
>>>>turn on the PositiveAcknowledgment option in msh.properties.xml of Hermes.
>>>>
>>>>Hope this helps.
>>>>
>>>>Regards, -Patrick
>>>>
>>>>
>>>>mlr...@cs... wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>thanks for the reply.
>>>>>
>>>>>For msh to work properly , i deleted the database tables and recreated the 
>>>>>database.and it worked.
>>>>>
>>>>>and abt acknowledgment
>>>>>
>>>>>I am sending a message from one machine to another machine.
>>>>>As soon as the message reaches the destination, the destination machine 
>>>>>should send an ack to the source.
>>>>>
>>>>>Please provide me a elaborate solution for this.
>>>>>
>>>>>If any one has already working system, provide me the sample code.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: Oracle 10g
>>>>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>>>>Take an Oracle 10g class now, and we'll give you the exam FREE. 
>>>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>>>_______________________________________________
>>>>ebxmlms-develop mailing list
>>>>ebx...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Sleepycat Software
>>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
>>deliver higher performing products faster, at low TCO.
>>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>>_______________________________________________
>>ebxmlms-develop mailing list
>>ebx...@li...
>>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>
>>    
>>
>
>  
>

[ebxmlms-develop] EbxmlMessage(File file) throws an 'Absent Content-Type Exception'

[<om...@no...>]

Sorry for the cross posting, but I don't know where exactly put this mesage.
I use MSH v.pre-1.0.0.0, build from cvs (date : approx 11/03/2004).
I use only mail messaging.

When I try to build a new EbxmlMessage using EbxmlMessage(File file), I 
get a javax.xml.soap.SOAPException: Cannot parse SOAP message
The message is a Ack generated by MSH in the server repository.
This ack doesn't have any content-type header.
After investigations, I get :
javax.xml.soap.SOAPException: Absent Content-Type at 
com.sun.xml.messaging.saaj.soap.MessageImpl.<init>(MessageImpl.java:86)
at 
com.sun.xml.messaging.saaj.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:32) 
at 
hk.hku.cecid.phoenix.message.packaging.EbxmlMessage.getMessageFromDataSource(EbxmlMessage.java:1681)
at 
hk.hku.cecid.phoenix.message.packaging.EbxmlMessage.<init>(EbxmlMessage.java:241)

The documentation says about this constructor: construct an EbxmlMessage 
from File using the logic in MessageServer. The file must not contain 
any content header like Content-Type

In EbxmlMessage.getMessageFromDataSource (about line: 1673), the 
following is commented :
/*
final MimeHeaders headers = new MimeHeaders();
headers.addHeader(Constants.CONTENT_TYPE, Constants.TEXT_XML_TYPE);
*/

this explains why the code fails.
The problem is that an ack must be loaded when retrying to send it, and 
it causes error.

Shall I uncomment the two lines ?

thanks

Regards
Olivier Moises