Re: ServiceMix 4.0
Feel free to let me know when this is scheduled and I will try and attend. Terry
Re: ServiceMix 4.0
Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
Re: [jira] Commented: (SM-1002) Service mix hangs when the # concurrent requests exceeds the maxConnectionsPerHost
So what if we put both limits to a very high number in the default configuration ? Is there any drawbacks? The risk there is that you are just increasing the size of the bang when it goes wrong. The system must degrade gracefully under heavy load in a production environment. If it has operating modes in which the container can hang then there is significant risk of message loss. -- Terry
Re: [jira] Commented: (SM-1002) Service mix hangs when the # concurrent requests exceeds the maxConnectionsPerHost
This solution is intended for the provider site not for the consumer site. So what I mean is to limit the outgoing connections from servicemix (for example to an external web service) over the provider endpoint with the thread limit. It doesn't depend on the consumer site. Do you know what I mean or did I get something wrong? You still have potentially the same problem as if you allow outgoing connections to propagate uncontrollably you will start to saturate the network layer leading to dropped packets, escalating retries and eventual bottleneck backing up to the sending threads. Since this can also disrupt other systems on the network it can turn into a self-inflicted DOS Attack. The system must play nicely with others in a production environment where scarce resources need to be shared (often in order of priority). -- Terry
Re: [DISCUSS] Split container and components release cycles ?
If we go that way, how could we deal with the examples ? I guess they would either require the use to download the components, or be available on a separate distros (and thus have their own release cycle too). Ideally needs a Maven-like dependency management system for components so that you can declare the versions that you need and they are downloaded from a repository and installed. -- Terry
Servicemix-Bean
I've been going over the servicemix-bean docs and as they are written at the moment, they seem to imply that most of the clever functionality can only be used in a static configuration. Is this actually the case or just an artifact of the way the documentation is structured? -- Terry
Re: Servicemix-Bean
I'm going to write some tests to see how well things interoperate within the types of deployment scenarios I would expect to deal with on a large project. I think there is scope for some streamlining in the way projects can be developed and deployed quickly. -- Terry Cox Meta-Concepts Ltd
Re: Document servicemix-common
JBI Component Framework (no plural) sounds fine to me. We need to document servicemix-common, which is our framework for building standard JBI components. But at the same time, servicemix-common does not sounds like a very good name. What about JBI Components Framework ? I'm not talking about changing the code, nor the jar, just to do a bit more advertising on the the web site about it ... -- Terry Cox Meta-Concepts Ltd
Re: Removing ServiceMix build on continuum
I think it's a good plan to have a continuous build system on the snapshot versions of each branch, but somebody on the team needs access to resolve issues like this and we should make sure that the notification system is configured to generate a smaller volume of warning messages. -- Terry Cox Meta-Concepts Ltd
Build broken
Hi, Can someone fix the continuum reporting config as well as the build, please? It seems to be spitting out multiple copies of the error mails and flooding the list. -- Terry Cox Meta-Concepts Ltd
Re: svn commit: r511833 - /incubator/servicemix/trunk/pom.xml
Author: gnodet Date: Mon Feb 26 06:53:33 2007 New Revision: 511833 URL: http://svn.apache.org/viewvc?view=revrev=511833 Log: Remove continuum notifier I guess you are probably on this already, but just in case, changing the pom hasn't fixed the problem because it's a svn issue: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within Continuum can't get a new copy of the source including that pom change, so it is still using the original copy. You may have to stop continuum and manually clean its build folder first to see if the problem is there or in svn. Cheers, -- Terry Cox Meta-Concepts Ltd 0788 1920512
Re: svn commit: r511833 - /incubator/servicemix/trunk/pom.xml
The problem seems due to a failure in the merge/switch. The error message is a bit obtuse, but seems to relate to switching to/from a folder which doesn't exist. It might be worth trying to back out those changes and apply them individually to see which breaks? -- Terry Cox Meta-Concepts Ltd
Re: Doc reorg
Any ideas on how to do that ? You need more than one way to get to information as people will use different strategies to find out about a new technology. I personally like to know at a glance the scope of a project, so I preferred the original approach (and the one taken on the ActiveMQ site) of having lots of left menu items for each topic, component or significant point. The documentation is probably weakest on practical examples, judging by the sort of support queries coming in. There should be explicit tutorials for binding to a foreign web service, exposing a web service, wrapping a POJO, creating JBI components, packaging and deploying using su/sa, applying security. We also need to do a better job of keeping these up to date and making it clear which documentation refers to which release. -- Terry
Re: Spring 2.0 and XBean
Well, I'm not sure how to solve the problem in the xbean build. Just a question, but does XBean need to evolve with backward compatability to multiple Spring versions in the trunk, or should it fork to a new release path that is maintained in parallel with the associated Spring release? -- Terry
Re: Spring 2.0 and XBean
Good idea, I think we should do a 3.0 of xbean and throwing away the spring 1.x support Let me know if you need a hand with anything. -- Terry
Re: Spring 2.0 and XBean
why is there a spring 1.2.4 version in the classpath ?
You need to remove it somehow.
It appears to be coming in via the maven-xbean-plugin, which seems to
import xbean-spring. I have tried over-riding the dependency on xbean
spring in the plugin reference and excluding Spring, but that doesnt work
plugin
groupIdorg.apache.xbean/groupId
artifactIdmaven-xbean-plugin/artifactId
version${xbean-version}/version
dependencies
dependency
groupIdorg.apache.xbean/groupId
artifactIdxbean-spring/artifactId
version${xbean-version}/version
exclusions
exclusion
groupIdorg.springframework/groupId
artifactIdspring/artifactId
/exclusion
/exclusions
/dependency
/dependencies
executions
execution
goals
goalmapping/goal
/goals
configuration
namespacehttp://com.metaconcepts.ball/1.0/namespace
/configuration
/execution
/executions
/plugin
Terry
Re: Spring 2.0 and XBean
Well evidently XBean 2.8 depends on Spring 1.2.4 which I don't understand. I seem to recall that XBean used Spring 2.x so I'm rather perplexed as to why a dep on Spring 1.2.4 is defined in the POM. I'm sure Guillaume can shed some light on it, so let's wait for his response. XBean contains a series of parallel projects that seem to build support for various specific versions of Spring, however because of this you can't just switch the root dependency to 2.0.x as the 1.x sub-projects won't build. Terry
Spring 2.0 and XBean
This little error is causing me some fun: org.springframework.core.ConstantException: Field 'ISOLATION_' not found in class [org.springframework.transaction.TransactionDefinition] To explain, I am trying to use a POJO in a lightweight container and that POJO requires some injected dependencies that are configured using Spring 2.0. My lw-component is deployed in a service unit using the sm:serviceunit id=jbi notation and the Spring 2.0 config for the dependencies is then imported within the same servicemix.xml using import. This imported file is using AOP to wrap my injected bean in a transactional context and Spring is obviously getting close enough to doing this to generate the above error message. The reason for the error is that the Spring 2.0.1 version of TransactionDefinition declares ISOLATION_ but Spring 1.2.4 does not. Within ServiceMix, it appears that XBean defaults to Spring 1.2.4 classes rather than 2.0.1 and I cannot see how to prevent this. I have spent a pleasant evening trawling through the innards of XBean and can see that it acts as a pre-processor to Spring. Unfortunately, at the point at which a service unit is loaded in ServiceMix, the classpath for XBean is already defined and I can't see a way to influence the flavour of Spring to be used to process an individual service unit. I see that XBean has packages for a variety of Spring flavours, so I guess the question is how do I make it use the one I want?. Thanks, Terry
Build broken
Just synchronised with HEAD and ran the build, but it is failing at ServiceMix :: Samples :: WSDL first :: SA [INFO] Determining component name for service unit wsdl-first-jsr181-su [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.servicemix.maven.plugin.jbi.JbiResolutionListener$Node.getChild ren()Ljava/util/List; [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.servicemix.maven.plugin.jbi.JbiResolutionListener$Node.getChild ren()Ljava/util/List; at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMo jo.getComponentName(GenerateServiceAssemblyDescriptorMojo.java:386) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMo jo.generateJbiDescriptor(GenerateServiceAssemblyDescriptorMojo.java:213) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMo jo.execute(GenerateServiceAssemblyDescriptorMojo.java:157) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMana ger.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLi fecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecyc le(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLif ecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFa ilures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(De faultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecyc leExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Terry
Re: renaming servicemix-jsr181?
if we call it servicemix-cxf or servicemix-xfire - that still isn't very descriptive of what it does :) I've read the documentation several times and I *still* don't know what it does. :) Terry
Re: Location to host JBI components
'd like to start a thread about where JBI components that are contributed by users should be hosted. I think that, like most other applications that have plugins, we should cover all three bases. Components maintained by the core team should be hosted locally. An open repository should exist for components donated by third parties who don't have the resources to host them themselves and this repository should have no licensing restrictions. At the same time, a list of external components should exist on the main site to integrate larger third party projects that provide JBI connectivity as part of their remit. I agree with the need to split the component's lifecycle from that of the container. From an enterprise point of view, most IT departments would want to work against a fixed release version of a container, but would consider the merits of each component as it became available, based upon their needs. This has a couple of implications. We would need strong integration tests for each component so that we could ensure compatibility with new container releases and we would need to keep a history of component versions to ensure ongoing backward compatibility against prior container releases. We should also clearly mark as deprecated those components that have been superceded by cleaner approaches and try to provide migration advice where possible. Terry
Enterprise features
To operate effectively at an enterprise level, ServiceMix needs robust, predictable resilience and redundancy facilities. ServiceMix relies upon ActiveMQ to deliver this, however it is becoming clear from the number of outstanding JIRA issues on ActiveMQ 4.0.2 that it is not able to deliver on that promise as yet. It seems that some work is being done to improve matters in the 4.1 stream and I was wondering when does the team think that we should move across to 4.1 and what should we do to ensure that these issues are all addressed within ActiveMQ? Terry
Re: (was: Re: User Feedback Request)
It seems most of the docs could be moved to the User's Guide, so maybe the User's Guide is not worth it. Opinions ? Perhaps the User's Guide should focus on walking through some end to end examples in detail with explanations? If it is done correctly, it should also form a QA document for example code in the releases, such that if you follow the User's Guide on a clean machine with a new binary release, the example code must run successfully. Doing that would flush out dependency issues in releases. Terry
Re: SUM: Re: Changing the name of the ServiceMix project at the Codehaus
Interesting. 'sm' words in English often have negative or derogative connotations: Smut Smack Smug Small Smarm Smash Smatter Smear Smeg Smell Smirch Smit Smite Smithereens Smog Smother Smudge I would advise against 'sm' words for that reason. Other thoughts: intermixable.org overmix.org mixible.org premixed.org Terry
Re: Changing the name of the ServiceMix project at the Codehaus
Oh i don't care about my suggestion really, just trying to get us to think outside the box. Well, here are a few that spring to mind to get the creative process rolling: InTheMix MixCentral MixDepot MixCore BeyondServiceMix MixBase Terry
Re: Changing the name of the ServiceMix project at the Codehaus
Take it from me, most big corporate clients spend much more effort worrying about whether they like the name of the project than on evaluating the quality of the technology it contains. If they can't pronounce it or spell it, they won't use it. :) Terry
Re: Changing the name of the ServiceMix project at the Codehaus
ServiceMixins Bit cheesy from a professional 'business technology' point of view. Terry
Re: Why do examples need maven to run
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?
Re: Why do examples need maven to run
However it seems to make for more brittle builds since the builds are depending on external resources being available and downlaoded. Using your own site repository helps in this respect, as does working against release versions of libraries rather than snapshots. Terry
jbi:embedded...
When starting a ServiceMix instance, it makes sense to me to put the ActiveMQ-related config in the top level servicemix.xml and then put JMS component-related stuff in Service Units that can be deployed in the container. Only trouble is, creating a connection pool depends on commons-pool which isn't installed in the lib directory by default, so the jbi:embeddedServicemix can't start... Terry
Re: jbi:servicemix
I have just built ServiceMix from HEAD I had just synchronised with HEAD. I've checked that I am up to date and have done another clean build of ServiceMix, but I still get the same error when I run jbi:servicemix. Terry
New examples work broken build?
Just synchronised and performed a step1, step2 build but it seems to be failing on the bridge samples stuff: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.servicemix.samples.bridge:bridge-jms-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-jms-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-jms-su:jar:1.0-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-http-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-http-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-http-su:jar:1.0-SNAPSHOT 3) org.apache.servicemix.samples.bridge:bridge-eip-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-eip-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-eip-su:jar:1.0-SNAPSHOT 4) org.apache.servicemix.samples.bridge:bridge-xslt-su:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.bridge -DartifactId=bridge-xslt-su \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT 2) org.apache.servicemix.samples.bridge:bridge-xslt-su:jar:1.0-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.servicemix.samples.bridge:bridge-sa:jbi-service-assembly:3.0-in cubating-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2/), servicemix-m2-repo (http://servicemix.org/m2-repo), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), codehaus (http://repository.codehaus.org), codehaus.m1 (http://dist.codehaus.org), activemq-tmp-repo (http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/maven2) Terry
Re: Refactor samples to use the maven jbi plugin
Do you have an example, I'm not sure to understand. Are you talking about a SU that depends on another SU ? Well, elements in a SU can have dependencies on both component libraries and normal java libraries. SAs may contain SUs that have dependencies upon different versions of these libraries. The classic example is during an ongoing business migration scenario. Step one is to roll out an integration solution for the existing legacy system using JBI. Then you build a new solution to replace the existing one and start to roll it out over a period of months to all the locations. Eventually you have upgraded all your sites and you can decommission the legacy system. In the intervening time, you have new and old systems running in parallel. If the cutover period is long enough, you may be rolling out v1.1 patches to new systems, whilst installing v1.0 code elsewhere and still maintaining legacy code. If ServiceMix is forming the integration layer then you will want to be able to deploy SUs for new solutions that can use later versions of dependent libraries without having any impact on previously implemented solutions on earlier dependencies. It's similar to the issues involved in maintaining XML Schema versions for interface specifications. Terry
Re: Packaging options and archetypes
+1 for going away from lw-container when possible. I think both archetypes and ready to run examples are necessary. Agreed. You need to understand the patterns before you can choose an archetype to apply. Terry
Re: Packaging options and archetypes
I would recommend more worked examples in the documentation and strictly, the worked examples should be used as QA tests for snapshots so that the examples are provably in sync with the releases. If you look at the forum, nobody could build consistently until a web page was put up documenting the sequence of build steps to apply. The same thing is required for the main common issues like JBoss integration, manual deployment of dependent classes for lw-container apps, real-world HTTP endpoint configuration etc. The examples are useful, but too simple and too focused upon lw-container approaches so you can't actually get a broad understanding of the JBI model from looking at the examples and the docs presuppose a strong background in Web Service concepts and jargon which is not always the case for Java-centric developers moving into integration. I am finding that the best way to illustrate some of these subjects to my developers is to build animated PowerPoint presentations that show how events move about within the environment. If we can find a web-centric way of doing animation easily, I'm happy to contribute similar docs for the site? Terry
Re: [jira] Updated: (SM-479) Add support for relative schema imports in WSDLFlattener
When parsing schemas for flattening a WSDL definition, the schemas are loaded with the baseUri set to null. This same problem occurs when using the Validation component to validate against a schema with imports. Hopefully this can be fixed in the same way? Terry
Re: Thoughts on restructuring
To add my bit to this idea. I am discovering that in order to develop components, you end up with lots of dependencies back into the ServiceMix project, most especially if you wish to be able to run unit tests that instantiate a container in order to test components. This in turn means that there are dependencies upon jars that are only in the local maven repository if the current ServiceMix snapshot has been built on the local machine. This obviously only occurs is you are developing against a snapshot, but it is still an issue. If the Servicemix build was refactored in such a way that the core jars could be published independently, it would be easier to maintain a development team working against a snapshot release without having to run full builds everywhere, or try to keep a site proxy updated with all the bits of ServiceMix. Terry
Problem with projectDeploy task
Refactored the projectDeploy goal so that is can determine whether
dependencies are already deployed and if so it will stop and undeploy
them before redeploying
This seems to have broken the jbi:projectDeploy task here. I now get:
[ERROR] BUILD ERROR
[INFO] ---
[INFO] Unable to deploy project, Error accessing ServiceMix administration
When I attempt to deploy a project to a local ServiceMix.
I have configured debugging of Maven tasks under Eclipse and the error
seems to occur in IsDeployedTask:33
if (JBI_SHARED_LIBRARY.equals(type)) {
String result = acs.listSharedLibraries(null, name);
setDeployed(isResultContaining(result, shared-library, name));
} else if (JBI_SERVICE_ASSEMBLY.equals(type)) {
** String result = acs.listServiceAssemblies(null, null, name);
setDeployed(isResultContaining(result, service-assembly,
name));
}
The AdminCommandsServiceMBean proxy appears to be connected correctly to
the ServiceMix instance, however executing listServiceAssemblies(null,
null, name) causes an immediate NullPointerException.
Terry
