Quoting Hannes Erven <[EMAIL PROTECTED]>:

Hannes,

Sorry for the delay in repling to mails.

I couldn't extract the 3rd file. Please send it to me again.

In file 1, the BACoordinator.java seems to be in the wrong place. According to 
the package definition it should be in kandula.coordinator.ba.coordinator but 
in your .zip its in kandula/ba/coordinator. However, in wsbi/ there is a 
package 'org.apache.kandula.wsbai'? So I'm wondering where you want these files 
to go? Can we put all ba stuff under org.apache.kandula.coordinator.ba.*?

The 2nd file has its classes under the expected package structure but still it 
defines two packages under the same name: 'coordinator'. I'd like to find a 
different name for the inner package or try to move the classes one level up. 
Can we put the classes in org.apache.kandula.coordinaotr.ba.* in 
org.apache.kandula.coordinaotr.*? In future you might even be able to merge 
some classes that carry state information for instance.

We should probably define a org.apache.kandula.participant.* as well but at the 
moment for AT, that stuff is also under coordinator.* We could do that if you 
like. However, this is not a major concern for the moment.

If the spam filter troubles you again, just send them to me and I will forward 
your mails after stripping off the attachements. Alternatively, you could host 
the patches somewhere and send the link to the mailing-list. Generally, I've 
heard that sending attachments (especially if they are large) is discouraged.

thanks a lot,
--dasarath






> Hi Dasarath,
> 
> 
> while trying to send the next patch to the mailinglist I got this back:
> 
> #
> # This message was created automatically by mail delivery software.
> #
> # A message that you sent could not be delivered to one or more of its
> # recipients. This is a permanent error. The following address(es)
> # failed:
> #
> #  [email protected]
> #    SMTP error from remote mailer after end of data:
> #    host herse.apache.org [140.211.11.133]: 552 Message rejected as it
> #    is spam (body)
> #
> 
> Grrr. I have no idea what in the body is even spam-like... do you? I'll 
> try to resend the patch to the mailing list tomorrow. In the mean time, 
> I try it directly to you.
> 
> 
> Good night,
> 
>       -hannes
> 
> 
> 
> -------- Original Message --------
> Subject: Re: Kandula_1 ba patch (WSBAI Web Service Interfaces)
> Date: Wed, 06 Jun 2007 23:32:48 +0200
> From: Hannes Erven <[EMAIL PROTECTED]>
> To: [email protected] <[email protected]>
> CC: Georg Hicker <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]> 
> <[EMAIL PROTECTED]>
> 
> Hi again,
> 
> 
> attached is the more or less final chunk for the WS-BA and WS-BAI
> implementations.
> 
> 
> This stage consists of three parts:
> 
> 1. The WS-BAI implemenation classes and a BACoordinator stub
> 2. The WS-BA implementation classes
> 3. A patch to existing classes to connect the WS-BA world to the
> existing parts of Kandula (activation, registration)
> 
> 
> The ZIP files contain all new classes. It seems the TortoiseSVN patch
> file structure does not allow the addition of files in new folders, so
> the attempt last week produced a corrupt patch :-/ so this time they
> come zipped.
> 
> 
> The patch modifies CoordinationService, CoordinatorImpl and
> ATCoordinatorImpl:
> 
> The CoordinationService already had WS-AT specific methods to fetch
> Endpoint References for protocol services and gets similar methods for
> WS-BA added.
> 
> The CoordinatorImpl gets the ID field removed because it is redundant
> with the CoordinationContext ID field. The getID() method now fetches
> the ID from there.
> The register() method gets a third parameter added, an identification
> tag from the initiator. (This is required to ensure the initiator may
> map business partners to transaction participants.)
> 
> The ATCoordinatorImpl changes include the third parameter in the
> register() method.
> 
> The patch also includes some cosmetic changes (mostly "this.field") that
> may be exluded if that is necessary.
> 
> 
> The new classes will be automatically picked up by the maven build as
> they are in a default
> 
> The next step will be the addition of the test cases and the sample
> application, and then we're done!
> 
> 
> Best regards and good night,
> 
>       -hannes
> 
> 


attachments.
> #
> # A message that you sent could not be delivered to one or more of its
> # recipients. This is a permanent error. The following address(es)
> # failed:
> #
> #  [email protected]
> #    SMTP error from remote mailer after end of data:
> #    host herse.apache.org [140.211.11.133]: 552 Message rejected as it
> #    is spam (body)
> #
> 
> Grrr. I have no idea what in the body is even spam-like... do you? I'll 
> try to resend the patch to the mailing list tomorrow. In the mean time, 
> I try it directly to you.
> 
> 
> Good night,
> 
>       -hannes
> 
> 
> 
> -------- Original Message --------
> Subject: Re: Kandula_1 ba patch (WSBAI Web Service Interfaces)
> Date: Wed, 06 Jun 2007 23:32:48 +0200
> From: Hannes Erven <[EMAIL PROTECTED]>
> To: [email protected] <[email protected]>
> CC: Georg Hicker <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]> 
> <[EMAIL PROTECTED]>
> 
> Hi again,
> 
> 
> attached is the more or less final chunk for the WS-BA and WS-BAI
> implementations.
> 
> 
> This stage consists of three parts:
> 
> 1. The WS-BAI implementation classes and a BACoordinator stub
> 2. The WS-BA implementation classes
> 3. A patch to existing classes to connect the WS-BA world to the
> existing parts of Kandula (activation, registration)
> 
> 
> The ZIP files contain all new classes. It seems the TortoiseSVN patch
> file structure does not allow the addition of files in new folders, so
> the attempt last week produced a corrupt patch :-/ so this time they
> come zipped.
> 
> 
> The patch modifies CoordinationService, CoordinatorImpl and
> ATCoordinatorImpl:
> 
> The CoordinationService already had WS-AT specific methods to fetch
> Endpoint References for protocol services and gets similar methods for
> WS-BA added.
> 
> The CoordinatorImpl gets the ID field removed because it is redundant
> with the CoordinationContext ID field. The getID() method now fetches
> the ID from there.
> The register() method gets a third parameter added, an identification
> tag from the initiator. (This is required to ensure the initiator may
> map business partners to transaction participants.)
> 
> The ATCoordinatorImpl changes include the third parameter in the
> register() method.
> 
> The patch also includes some cosmetic changes (mostly "this.field") that
> may be exluded if that is necessary.
> 
> 
> The new classes will be automatically picked up by the maven build as
> they are in a default
> 
> The next step will be the addition of the test cases and the sample
> application, and then we're done!
> 
> 
> Best regards and good night,
> 
>       -hannes
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to