Do a "reverse" partnership lookup when receiving a message?

[jochenberger]

Do a "reverse" partnership lookup when receiving a message?

[phax]

I don't really understand what you exactly want. You want to thave getPartnershipByID being publically available? Or you want something like getReversePartnership(Partnersip) comprable to getPartnership(Partnership)?

[jochenberger]

Okay, let me try again. ;-)
I think that an outgoing message from L to R should use the same Partnership as the MDN response. Currently, you'd need to add two partnerships, a? Sender L, Recipient R and b) Sender R, Recipient L.
Maybe the differentiation between "sender" and "recipient" is not the best choice here. If a partnership consisted of a "local" and "remote" part, the same partnership could be used for the message and the response.
But if you want to keep the terms, all places that handle incoming messages could to the lookup for the partnership the other way around and that's basically what I did in my implementation of getPartnershipByID.

[phax]

Okay- I think I'm getting a little closer to understanding. Your assumption is, that all partnerships are reversibly exchangable. This is not true concerning what I have seen so far.

If this is something that is special to your use case, I suggest to stick to your implementation :) I see no realistic way that the automatic reverse handling will work for everbody.

[jochenberger]

Yes, that's what I assumed. Sorry, I'm quite new to AS2, and I'm not familiar with all the possible setups. Could you please give an example where that would not work? I wonder what the difference could be. I can imagine different setups for sending and receiving messages but not for sending a message and receiving a DN.

[phax]

One possible example is that your are sending unsigned but expect a signed MDN back. In general, if the signing setup differs between message and MDN. Additionally there are attributes like 'subject' or 'as2_mdn_to' that might be differing.

[jochenberger]

Hm, that still feels like a single partnership with outbound_signing_options and inbound_signing_options to me, but I guess that's a matter of taste. Thanks for the explanation.

[phax]

Exactly. You could group things for signing, encryption, transfer, resend etc. as it is done for the partners. But as this is a fork of OpenAS2 I want to provide some basic compatibility with it and stick to it :)
Concerning the release - I'm still investigating the problem, but I think we're coming closer and as soon as this is settled, the 2.2.0 release will go out!

[phax]

Do you have concrete plans on providing the MongoDB based partnership factory? Shall I wait for it, or will you come back to me when you're ready? Thanks

[jochenberger]

I've created a Gist for the current version: https://gist.github.com/jochenberger/e147a739a9e6e8ed58b1
But it doesn't adhere to the conventions of the library and doesn't have tests. That's going to take a while though I'm afraid.

[phax]

Do you mind if I make this a subproject in as2-lib and give you collaboration rights to push on that subproject?

[jochenberger]

You can do that, but I doubt that I'll find the time to work on this in the next few weeks. Can I use Gradle and Spock or do I have to use Maven?

[phax]

I would take care about the Maven stuff. Concerning the tests, if you can enable Spock only for that sub-project I have no strong feelings.
Is the FreeBSD license (as with the rest of as2-lib) okay for you?

[jochenberger]

I prefer Apache 2, but FreeBSD should be okay too.
I'll try to create a Spock test, we'll see if I can get it to work with Maven.

[phax]

OK. I made the subproject Apache 2 licensed - no problem.
https://github.com/phax/as2-lib/tree/master/as2-partnership-mongodb contains the sub-project including the Maven setup and a basic JUnit test with embedded MongoDB (but just testing Mongo and not the Partnership factory)

[jochenberger]

I added a basic test, seems to work. I'm having issues with Maven/Eclipse/Groovy however (Plugin execution not covered by lifecycle configuration: org.codehaus.gmavenplus:gmavenplus-plugin:1.4:compile (execution: default, phase: compile)), maybe you can get it to work.
I guess we should git-ignore Eclipse-generated files, like .settings/, .classpath, and .project and probably remove them from version control altogether. What do you think?

[phax]

thanks a lot for adding a test. If just added some minor cleansings when using this from within Eclipse. On the commandline it works just fine!
As I'm using Eclipse and there are no real contributors I prefer to leave the Eclipse settings in there. If there are other contributors adding a bit more I may theoretically remove the files/dirs you mentioned.