On 1/23/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote:
Hi, Response between the lines... > > 1.) States of MEs > > ================== <<<< snipped >>>>>> Ok. The CAN_OWNER flags are maintained along with the states; in a given state (which has been changed by accepting or sending an ME), it is or is not enabled, hence allowing or disallowing a component to change the ME. Correct?
Yes, though read methods are not checked and only some write methods are. But as you said, the idea is that a component MUST not access the exchange (but the status) unless it is the owner.
> > 2.) Duplicity of MessageExchange instances > > =========================================== > > What I didn't get is that from "JBI Components: Part 1 (Theory)" I > concluded that all messages related to ONE interaction between a Consumer > and a Provider go through the same MessageExchange > instance/MessageInstanceImpl object. **) > > I don't think this is a requirement. The data should be the same of > course. > Even for a component, the exchange is not always the same: for example > when > the exchange is serialized in the jms / jca flow. Hence, when using > sendSync, a > hack is needed (in the delivery channel) to copy the data from the > received response > to the original object. I see, the one via "exchangesById.put(exchangeKey, me)".
Yes, this map is used with the "original.copyFrom(me);" (line 548) which copy the received exchange back to the original one.
> > However, in the code, it seems that the STATES_PROVIDER states are only > assigned to a _new_ instance - while copying the ExchangePacket and > assigning the ME from which it was copied as mirror. > > > > Correct? Why? > > See above. > > 3.) Documenting the above and SM JavaDoc > > ========================================= > > Where in the SM pages/documentation would be the best place to > contribute findings/investigations such as the above? Also, which one is > the official SM JavaDoc: http://incubator.apache.org/servicemix/maven/... > or http://servicemix.goopen.org/maven/... or http://XXX/...? > > Maybe somewhere near http://servicemix.org/site/how-stuff-works.html > If you have any idea to improve the organization of the docs, please stand > up > and speak ;-) Sure, can do. Alternatives: - A new "JBI in ServiceMix" page with the same structure as JBI, but describing how SM implements it (- Expanding the corresponding JavaDoc) Please let me know which place you consider the most appropriate, and I'll add our conversation there.
I find javadoc is a bit difficult to use when writing some general purpose informations. So i guess a new page is fine, but this is up to you. If you want to edit the wiki, please send a CLA to the ASF (fax or mail), sign in in confluence and i will grant you edit rights.
On a side note, I like the structure of the Cocoon documentation, where general documentation is divided into a User and Developer part depending on whether you want to only use the framework or want to code (http://cocoon.apache.org/2.1/). > The javadocs for 3.0 release are deployed at > http://incubator.apache.org/servicemix/dist/servicemix-3.0- > incubating/site/ > I think the other ones should be removed, but there may be links > pointing there ... Ok. Thanks! Ciao, Philipp This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
-- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
