Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Definitely interested. It's been a while since I've checked in on the ServiceMix project and the directions wrt OSGi look extremely promising. On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? Cheers, Guillaume Nodet On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Btw, if there is sufficient interest, we could organize irc meetings to discuss these topics and post the log to the dev list for archiving and later discussion. Cheers, Guillaume Nodet On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/ incubator/servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a component that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel component would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service name, interface name, wsdl location, etc..). These metadatas could be used to retrieve targets using the Registry. We could plug in different mechanisms to query the metadata (simple lookup per id, policy based, etc...). And the result itself could be not only a single Endpoint, but could include some
Re: [jira] Commented: (SM-514) ValidateComponent does not create StreamSource with a SystemId which breaks schema includes and imports
Archana, Can you provide be the exact error and some more information about your schemas? Hierarchical layout? Relative imports etc... Grant On 7/11/07, archana (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39642] archana commented on SM-514: i dont think issue is resolved.. coz i tried all possible ways as suggested but i am still facing same problem and getting same error.. ValidateComponent does not create StreamSource with a SystemId which breaks schema includes and imports --- Key: SM-514 URL: https://issues.apache.org/activemq/browse/SM-514 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0.1 Environment: Windows XP SP2, Ubuntu Linux 5.10, ServiceMix HEAD Reporter: Grant McDonald Assignee: Grant McDonald Fix For: 3.0 Attachments: servicemix-components.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When creating a new schema object with a Source object the only way for Xalan/Xerces to resolve schema imports is via a SystemId which is an attribute on Source objects. Instantiating a StreamSource with an InputStream does not set this attribute and without this attribute being set schema imports and includes are not resolved correctly and an obscure message is returned: org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'USAddress' to a(n) 'type definition' component. This is actually because the import/include failed. It is unfortunate that the error message is not more informative. A patch has been provided to fix this error and the ValidationTest test case updated to use a simple hierarchical directory layout. NOTE: the attached zip file has two patches and a new directory and xsd. The layout is as from the servicemix-components directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Fwd: What do people think about graduation ?]
I would agree that due to its size and complexity that a TLP makes sense :) On 3/17/07, Alex Boisvert [EMAIL PROTECTED] wrote: I agree on both counts. I think ServiceMix is ready for graduation and I think a TLP would be most appropriate. alex On 3/16/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Yeah, give the current size of the project, it would not make any sense to me to be a subproject. And users / dev community are big enough to warrant a TLP imho. On 3/16/07, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Mar 14, 2007, at 11:51 AM, Guillaume Nodet wrote: It may be time to consider it. The community is growing and diverse ... I don't see any issues left. Seems like a good idea to me. Do you guys think we should be a TLP? Regards, Alan -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Websphere 6.1 and MBean registration issue
Hi, I've been out of touch for a while with swapping to a new job and all and I was wondering whether David Potter had forwarded a solution to the MBean registration issue in Websphere? If not I'd like to open the floor to discussions on a possible fix. I think the possible use of querynames could be fraught with issues especially in clustered environments. Would it be possible to change the base MBean itself so that upon registration it updated the objectName? That way changes would be propagated correctly? I noticed in the code there is references to property change listeners and was wondering whether this meant it was already implemented? Cheers, Grant M
Fwd: Websphere 6.1 and MBean registration issue
Hey David, I was wondering if you already had a workable solution for the MBean registration issue? I was thinking instead of putting the code in the AsyncBaseLifecycle it should instead go in the base MBean code. I'll raise a JIRA issue and we can continue discussion of it. Grant -- Forwarded message -- From: Guillaume Nodet [EMAIL PROTECTED] Date: Mar 17, 2007 9:40 AM Subject: Re: Websphere 6.1 and MBean registration issue To: servicemix-dev@geronimo.apache.org On 3/16/07, Grant M [EMAIL PROTECTED] wrote: Hi, I've been out of touch for a while with swapping to a new job and all and I was wondering whether David Potter had forwarded a solution to the MBean registration issue in Websphere? If not I'd like to open the floor to discussions on a possible fix. I don't think so, but you should ping him and cc this list to see if he has worked on it already. I think the possible use of querynames could be fraught with issues especially in clustered environments. Would it be possible to change the base MBean itself so that upon registration it updated the objectName? That way changes would be propagated correctly? I noticed in the code there is references to property change listeners and was wondering whether this meant it was already implemented? Yeah, it should be possible to retrieve the new value of the Objectname and use it instead of the one ServiceMix generates. I think this is the only change to make, but i may miss something: where do you want to propagate the change ? Anyway, property change listeners should generate jmx notifications, provided that the setter call the needed method of course. Cheers, Grant M -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: XPath and Drools routing with SXC?
Were you thinking of integrating it with EIP routing? That could possibly be done. On 3/17/07, Dan Diephouse [EMAIL PROTECTED] wrote: Hi All, I think I wrote something which may be of use to ServiceMix, but unfortunately I don't have time to integrate it myself - so I'm going to throw it out there for everyone :-) I started a project called SXC - simple xml compiler - which creates optimized xml parsers for various things. There is one for JAXB. But, the one of probably the most interest to this crew is the XPath frontend. SXC can build a streaming xpath parser for you (at runtime). This means you can listen for XPath events as you scan over the document. This allows for very efficient XPath based routing. In my initial performance test it was about 100x faster than Jaxen for locating nodes (although thats a very rough benchmark, real numbers may vary!) We also integrated it with Drools so you can write XPath expressions right in your rules. Check out these links for more information: http://sxc.codehaus.org http://sxc.codehaus.org/XPath http://sxc.codehaus.org/Drools The one caveat is that we support only a limited subset of XPath expressions at the moment. But if you wanted to hack SXC, its easy enough to add more. I'm happy to help where I can or give guidance to anyone who wants to participate as well. Anyone up for hacking it into servicemix? :-) - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
(SM-751) Flow tracing with correlation id, BPE and ODE
On 12/8/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 12/7/06, Roger Menday [EMAIL PROTECTED] wrote: I get the impression that the servicemix-bpe component is not using the latest ode code - however, as it is today, this component *doesn't* seem to be sticking the correlationID, into exchanges it is making. This would be useful here too. I guess this will also be a problem with any non-servicemix components too :) ? servicemix-bpe also doesn't add the senderEndpoint as a property into the exchanges it makes. servicemix-bpe is based on a donation to the ODE project which is not maintained. You should try the ODE Service Engine provided by the ODE project itself. Unfortunately BPEL is fundamentally driven at the message level and although the new ODE code is integrated with all the joys of MessageExchanges (both JBI and Persistable ODE ones) there is still a basic disconnect between the input to a BPEL process and any invokes that may occur during that BPEL process. At the point where an invoke is called a new MessageExchange is created without deriving any properties from the initiating exchange. That is not to say initiating message exchange's properties couldn't be copied but that it may lead to other side-effects. There is some code in ODE that allows for the use of InvocationInterceptors which may be a lead towards providing a configurable correlation mechanism (as distinct from BPEL correlation sets) - the ODE guys should be able to shed some light on this. The reason why your solution didn't work for the current BPE component was because it has two main external interfaces: BPEEndpoint which is a consumer and JbiInvokeAction which is a provider. I'm not sure how you'd go about using thread local storage across two classes and I'm not sure if there is even a guarantee that the JbiInvokeAction will be called in the same thread. I faced a similar situation with needing to correlate messages coming in to BPE and invokes leaving BPE from the same initiating exchange and the only easily implementable solution was to wrap an aspect around both classes to generate a correlation id to be added to the incoming message xml in a configurable manner.
Re: [jira] Commented: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
Guillaume, The more I look at this the more I come up with questions :) The AbstractXBeanDeployer and AbstractWsdl1Deployer are both part of the inheritance hierarchy of AbstractDeloyer. Should there actually be a validate method on the AbstractDeployer instead which would allow for the validation across the entire deployer hierarchy? I am assuming here that the idea was to introduce a way to have both a generic and specific validation hierarchy. And further, would the other endpoint deployers require calls to validate after their endpoints are created? The endpoint deployers involved here are (Other than AbstractWsdl1Deployer and AbstractXBeanDeployer): BPEDeployer ScaDeployer WSNDeployer Currently there would be no additional validations but the introduction of a validate method would be more consistent if it was applied across all the endpoint deployers instead of in just a couple. Grant M. On 11/10/06, Grant McDonald (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-536?page=comments#action_37404] Grant McDonald commented on SM-536: --- I thought as much. I'll update it to throw DeploymentException and add in a validate method to the AbstractWsd1Deployer The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Attachments: SM-536.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Faults and Exceptions
-- Forwarded message -- From: Guillaume Nodet [EMAIL PROTECTED] Date: Oct 27, 2006 6:53 PM Subject: Re: Declarative Exception Handling in ServiceMix To: Grant M [EMAIL PROTECTED] On 10/27/06, Grant M [EMAIL PROTECTED] wrote: Guillaume, I just wanted to clarify the following statement: On 8/25/06, Guillaume Nodet [EMAIL PROTECTED] wrote: First, we need to make a distinction between faults and errors. Imho, faults are unrecoverable problems, due to the message itself. Errors are runtime problems, which may be able to be solved at a later time. In your example, depending on the reason why the data could not be stored in the database, the component should return a fault (if the data is corrupted) or an error (the database is down). My understanding is that faults only occur due to the content of the message and errors are for exceptional conditions outside this. For instance I have a component which calls some stored procedures which can return validation and processing messages that can be errors. In this case these messages form a fault to be returned. However during the course of preparing the call to the stored procedures and retrieving the results many exceptional conditions can arise. It is these conditions which should form an error is it not? Where this gets fuzzy is at boundary cases like binding components. The only sensible way I've found to treat external systems is they return faults for everything even when there are exceptional conditions and errors are thrown when there are exceptional conditions at the boundary interface like connection errors. It's not so easy to make the difference between both. I think that you're right in this case. I think all connection errors or temporary problems (such as a database down) should be handled as errors, whereas problems due to error in the message (bad sql request in the message, etc...) should be handled by faults. However a soap stack will only return faults. I guess we must be prepared to handle both and act accordingly. One problem is when you put transactions into this: should we rollback the transaction when an error occur ? Regards, Grant M. -- Cheers, Guillaume Nodet
Re: Why do examples need maven to run
Jeppe, So long as you have built with maven once whilst you are connected, you can always later build using the -o option for an offline build, especially in reference to the examples it is useful (and speeds up the build considerably :) Grant M. On 8/25/06, Jeppe [EMAIL PROTECTED] wrote: It seems to me that Maven is not all glory, though it has some nice features, I'm sure. However it seems to make for more brittle builds since the builds are depending on external resources being available and downlaoded. Besides the fact that you might not always be connected. There might be ways around this I guess, to disconnect maven from attempting to download new jars. Anyways I think it would be a very good thing if the release is not dependent on maven for building the examples. It would probably be best if they were included pre-built. Terry Cox wrote: Encouraging new developers to work within maven is probably a good thing as dependency management is a big part of the JBI world. Maven enforces good practices with respect to that and hopefully the examples will provide a cleaner path into a workable build environment. We initially experienced a steep learning curve in trying to get beyond the simple Ant-based examples to a build environment capable of dealing with many ServiceMix components. Terry It seems a bit contrived to have to use maven to build the examples. Maven might be used to build the release, but it seems strange that the distribution should be dependent on Maven. With Maven there is alot of magic going on in the background which doesn't add to the clarity of the examples and facilitates a low threashold of entry into servicemix. This was not the case in M2, but has changed sometimes after. Or maybe it's just this way when building the SNAPSHOT package? I believe that the examples are usually the entry point for beginner (like mysellf) in getting to grips with a new platform. What is the reason for this? Any possibilities to revert this course? -- View this message in context: http://www.nabble.com/Why-do-examples-need-maven-to-run-tf2157824.html#a5972297 Sent from the ServiceMix - Dev forum at Nabble.com.
