Re: IRC session
(+1) sure thing, i'll join from the beach. -brian On 8/31/07, Eric Dofonsou [EMAIL PROTECTED] wrote: +4 .. - Original Message From: rs d [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Tuesday, August 28, 2007 6:53:59 PM Subject: Re: IRC session +3 ok. On 8/28/07, Kit Plummer [EMAIL PROTECTED] wrote: On 8/28/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ +2 ; } -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
works for me. -brian On 8/25/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Ok, sounds like we have enough people. So we just need to find a data and an hour. What about Friday 3 pm GMT, 11 am EST, 8 am PST Adrian, I'm not sure how to find a time that would suits you... Other propositions are welcome... Cheers, Guillaume Nodet On Aug 24, 2007, at 11:04 AM, Nodet Guillaume 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.
Re: Spring extensions to OSGi (was Re: ServiceMix 4.0)
Guillaume, Just getting grounded... Would SM 4.0 leverage Felix to get OSGi capabilities? I took a grep through the code, it doesn't look like it uses it at all right now: [EMAIL PROTECTED]:~/dev/apache.org/servicemix- grep -r elix * and osgi appears only in the eclipse plugins. Just verifying, OSGi is a brand new dependency for SM, right? Which leads me to my second question, do you think the dependency would be a hard dependency (on the actual felix impl), or would it be implementation agnostic? (e.g. able to run on Equinox as well) I am going to pull felix now and start playing around with it. -brian On 8/24/07, Guillaume Nodet [EMAIL PROTECTED] wrote: One topic not covered in this excellent post is a standard mechanism to provide access to other endpoint metadata (e.g. the WSDL file) - having that as a standard OSGi metadata would be cool (e.g. a WSDL URI) Yeah, I have had a closer look at how OSGi provides URL handlers. This is not as simple as I thought it would be. OSGI defines a bundle: protocol that can be used to access resources in the bundle. Unfortunately, the url has to contain the bundle id, which means that the URLs have to be built dynamically. I'm sure we can create a spring bean factory to create those dynamically though... Or a post factory processor that would process the URIs to rewrite them and include the bundle id. This way, the service could contain a WSDL_URL property associated with it (when registered in the OSGi registry) that would be a bundle url pointing to the wsdl inside the bundle. This would solve one of JBI limitation which is the ability to have complex WSDLs definitions including other WSDL or XSD. I've been thinking about that a bit more. It seems to me that using a kind of PropertyPlaceHolder (i.e. a BeanFactoryPostProcessor) sounds like a good idea. It could check all properties and perform replacement of an url like: bundle-ext://org/test/dummy.wsdl to bundle://7.0/org/test/dummy.wsdl where 7.0 is the bundle id. Another extension could be a spring bean factory that expose a blob of xml to an url for other bundles to consume. Inside your spring definition file, one would have: smx-osgi:export-xml url=org/test/dummy.wsdl wsdl:description ... ... /wsdl:description /smx:osgi Thus a single configuration file (the spring one) could contain blob of xml (well, not only xml i guess) that could be exposed as an url. I think the first idea will prove really useful to expose a WSDL to other bundles. I'm not so sure about the second one... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Re: ServiceMix 4.0
Fanastic. Once we get consensus on the direction (your first few points), I wonder if we shouldn't break this email out to discuss the specifics. On 8/22/07, Nodet Guillaume [EMAIL PROTECTED] 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 Excellent! Spot on. 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. RE: uml tool Bruce, I've struggled with the same. I actually run Parallels/VMWare+Visio, just to keep compatibility with others I have to interact with. FLOSS community desperately needs a architecture tool. 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 :-) +1 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. I haven't looked at Camel converters, but would you consider adding a contentType and contentEncoding mimicing the headers of HTTP SIP. The endpoint can then use the type and encoding to determine how to handle the content. 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. sweet. 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 policies like: load balance between all the endpoint implementing the given
Re: checkstyle on the se-archectype
Unfortunately those are different errors, because I'm getting them in the code generated by the maven archetype. After fixing the checkstyle errors, I had to fix a couple PMD errors. Now, I'm on to making the test pass, which is generating: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbi' defined in class path resource [spring.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.springframework.jmx.support.ConnectorServerFactoryBean.setObjectName(Ljava/lang/String;)V I'm guessing this is a spring version problem. Trying to track it down now. -brian On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: While trying to build from the source from the trunk.. Meven 2 JBI Plugin failed fo me ith check style errors.. GraphArtifactCollector.java:58:37: More than 7 parameters JbiComponentDescriptorWriter.java:37:15: More than 7 parameters Do you have the same errors? Regards, Rabi Mishra http://rabisblog.blogspot.com/ From: [EMAIL PROTECTED] on behalf of Brian O'Neill Sent: Tue 7/10/2007 11:52 PM To: servicemix-dev@geronimo.apache.org Subject: checkstyle on the se-archectype Following the se tutorial: http://incubator.apache.org/servicemix/hello-world-se.html The code produced from the mvn archetype failed the checkstyle check (with errors). Has anyone else experienced this? (I also had to go in and update the version in the pom.xml, so it would pull a current release of sm) -brian -- Brian ONeill Source Equity (http://www.sourceequity.com http://www.sourceequity.com/ ) jBIZint (http://www.jbizint.org http://www.jbizint.org/ ) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com http://www.gestalt-llc.com/ ) mobile:215.588.6024 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
servcemix-sca: pmd violations fix
All, I'm trying to resurrect servicemix-sca (out of the sandbox). It had two pmd violations that needed fixing before it would compile. I submitted the patch here: https://issues.apache.org/activemq/browse/SM-973 best regards, -brian -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Progress w/ Servicemix-SCA
All,
See below. We are working to get servicemix-sca up and running again.
Presently, I'm adding the repo to the servicemix-sca so it can find
its timestamped dependencies.
best,
-brian
On 6/22/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
I think the repo has been removed from the root pom.
Just add it in the servicemix-sca pom.
On 6/22/07, Brian O'Neill [EMAIL PROTECTED] wrote:
Guillaume,
Looks like that artifact is there. Let me check the poms and repo
list to make sure that repo is in there.
-brian
On 6/22/07, Brian O'Neill [EMAIL PROTECTED] wrote:
I'll see if I can find it in that repo, but here is the report:
1) org.apache.tuscany:tuscany-common:jar:20060317
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.tuscany
-DartifactId=tuscany-common \
-Dversion=20060317 -Dpackaging=jar -Dfile=/path/to/file
That is just one of the missing dependencies. It can't find any of
the timestamped versions.
-brian
On 6/22/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
Which artifacts are missing ?
The sca should use some timestamped artifacts for Tuscany and they
should be
available on a servicemix repo at http://servicemix.org/m2-repo/
On 6/22/07, Kit Plummer
[EMAIL PROTECTED]
wrote:
That's cool. I just turned off PMD. ; }
There's a ton of missing artifacts for me...the same is true for
Tuscany
so I'm just guessing I'm not aligned with a repo somewhere...
Kit
Kit Plummer
Advanced Programs
Raytheon Mission Systems
520.360.4729 (cell)
520.545.9246 (desk)
kitplummer (im)
Brian O'Neill wrote:
Guillaume,
Thanks for the help around the checkstyle errors. After I got past
that, I had to fix two PMD violations. The diff is attached.
Could
you commit the changes?
best regards,
-brian
Index:
src/main/java/org/apache/servicemix/sca/ScaEndpoint.java
===
---
src/main/java/org/apache/servicemix/sca/ScaEndpoint.java
(revision 549589)
+++
src/main/java/org/apache/servicemix/sca/ScaEndpoint.java
(working copy)
@@ -90,7 +90,7 @@
classes.add(mth.getReturnType ());
classes.add(params[0]);
}
-jaxbContext = JAXBContext.newInstance(classes.toArray(new
Class[0]));
+jaxbContext = JAXBContext.newInstance(classes.toArray(new
Class[classes.size()]));
}
public void deactivate() throws Exception {
Index:
src/main/java/org/apache/servicemix/sca/handler/ExternalJbiServiceClient.java
===
---
src/main/java/org/apache/servicemix/sca/handler/ExternalJbiServiceClient.java
(revision 549589)
+++
src/main/java/org/apache/servicemix/sca/handler/ExternalJbiServiceClient.java
(working copy)
@@ -78,7 +78,7 @@
NormalizedMessage in =
inout.createMessage();
inout.setInMessage (in);
in.setContent(new StringSource(baos.toString()));
-boolean sent = channel.sendSync(inout);
+ //boolean sent = channel.sendSync(inout);
// TODO: check for error ?
NormalizedMessage out =
inout.getOutMessage();
Object response =
context.createUnmarshaller().unmarshal(out.getContent());
--
Cheers,
Guillaume Nodet
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
--
Brian ONeill
Source Equity ( http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org )
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
--
Cheers,
Guillaume Nodet
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
