[jira] Resolved: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds resolved SM-674. - Resolution: Fixed Applied change to 3.0 branch and trunk to change parameters to read-write. > jbi:installComponent (and others) fails authentication against default SM > container > --- > > Key: SM-674 > URL: https://issues.apache.org/activemq/browse/SM-674 > Project: ServiceMix > Issue Type: Bug > Components: tooling >Affects Versions: 3.0 > Environment: Java 1.5, Windows XP SP2 >Reporter: Jamie McCrindle > Fix For: 3.0.1, 3.1 > > > When running the jbi:installComponent maven task to install a component into > a running SM 3.0 container, it fails with an Authentication failed "User not > found" message. Debug from maven as follows: > [DEBUG] Configuring mojo > 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc > ubating:installComponent' --> > [DEBUG] -- end configuration -- > [INFO] [jbi:installComponent] > installComponent: > [echo] Installing > C:\dev\component-mvn\component-task-jbi\target/component- > task-jbi-1.0-beta2-SNAPSHOT-installer.zip to > service:jmx:rmi:///jndi/rmi://local > host:1099/jmxrmi > [installComponent] Error accessing ServiceMix administration: Authentication > fai > led > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to execute: Executing Ant script: /jbi.build.xml > [installComponent > ]: Failed to execute. > User does not exist > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: > Execu > ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone > Goal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.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(DelegatingMethodAcces > sorImpl.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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: > Ex > ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:37) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:534) > ... 16 more > Caused by: > org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept > ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to > execute. > at > org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant > ScriptInvoker.java:227) > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:33) > ... 18 more > Caused by: > C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: > 30: Error accessing ServiceMix administration > at > org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav > a:272) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) > at org.apache.tools.ant.Task.perform(Task.java:364) > at org.apache.tools.ant.Target.execute(Target.java:341) > at org.a
[jira] Reopened: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds reopened SM-674: - Unable to set read-only parameters > jbi:installComponent (and others) fails authentication against default SM > container > --- > > Key: SM-674 > URL: https://issues.apache.org/activemq/browse/SM-674 > Project: ServiceMix > Issue Type: Bug > Components: tooling >Affects Versions: 3.0 > Environment: Java 1.5, Windows XP SP2 >Reporter: Jamie McCrindle > Fix For: 3.0.1, 3.1 > > > When running the jbi:installComponent maven task to install a component into > a running SM 3.0 container, it fails with an Authentication failed "User not > found" message. Debug from maven as follows: > [DEBUG] Configuring mojo > 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc > ubating:installComponent' --> > [DEBUG] -- end configuration -- > [INFO] [jbi:installComponent] > installComponent: > [echo] Installing > C:\dev\component-mvn\component-task-jbi\target/component- > task-jbi-1.0-beta2-SNAPSHOT-installer.zip to > service:jmx:rmi:///jndi/rmi://local > host:1099/jmxrmi > [installComponent] Error accessing ServiceMix administration: Authentication > fai > led > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to execute: Executing Ant script: /jbi.build.xml > [installComponent > ]: Failed to execute. > User does not exist > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: > Execu > ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone > Goal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.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(DelegatingMethodAcces > sorImpl.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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: > Ex > ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:37) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:534) > ... 16 more > Caused by: > org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept > ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to > execute. > at > org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant > ScriptInvoker.java:227) > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:33) > ... 18 more > Caused by: > C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: > 30: Error accessing ServiceMix administration > at > org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav > a:272) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) > at org.apache.tools.ant.Task.perform(Task.java:364) > at org.apache.tools.ant.Target.execute(Target.java:341) > at org.apache.tools.ant.Target.performTasks(Target.java:3
[jira] Resolved: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds resolved SM-674. - Resolution: Fixed The problem was the lack of defaulting in the ANT tasks , this has been switched so that default username, passwords are smx/smx. Note that for 3.0 you can simply add username,password as configuration parameters in the jbi-maven-plugin to get the logins to work. > jbi:installComponent (and others) fails authentication against default SM > container > --- > > Key: SM-674 > URL: https://issues.apache.org/activemq/browse/SM-674 > Project: ServiceMix > Issue Type: Bug > Components: tooling >Affects Versions: 3.0 > Environment: Java 1.5, Windows XP SP2 >Reporter: Jamie McCrindle > Fix For: 3.0.1, 3.1 > > > When running the jbi:installComponent maven task to install a component into > a running SM 3.0 container, it fails with an Authentication failed "User not > found" message. Debug from maven as follows: > [DEBUG] Configuring mojo > 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc > ubating:installComponent' --> > [DEBUG] -- end configuration -- > [INFO] [jbi:installComponent] > installComponent: > [echo] Installing > C:\dev\component-mvn\component-task-jbi\target/component- > task-jbi-1.0-beta2-SNAPSHOT-installer.zip to > service:jmx:rmi:///jndi/rmi://local > host:1099/jmxrmi > [installComponent] Error accessing ServiceMix administration: Authentication > fai > led > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to execute: Executing Ant script: /jbi.build.xml > [installComponent > ]: Failed to execute. > User does not exist > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: > Execu > ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone > Goal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.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(DelegatingMethodAcces > sorImpl.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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: > Ex > ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:37) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:534) > ... 16 more > Caused by: > org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept > ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to > execute. > at > org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant > ScriptInvoker.java:227) > at > org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav > a:33) > ... 18 more > Caused by: > C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: > 30: Error accessing ServiceMix administration > at > org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav > a:272) > at > org.apache.tools.ant.Un
[jira] Closed: (SM-619) Allow the Maven JBI plugin to inject a default bootstrap if one isnt' specified
[ https://issues.apache.org/activemq/browse/SM-619?page=all ] Philip Dodds closed SM-619. --- Resolution: Fixed Implemented > Allow the Maven JBI plugin to inject a default bootstrap if one isnt' > specified > --- > > Key: SM-619 > URL: https://issues.apache.org/activemq/browse/SM-619 > Project: ServiceMix > Issue Type: New Feature > Components: tooling >Affects Versions: 3.0 >Reporter: Philip Dodds >Priority: Minor > Fix For: 3.0.1, 3.1 > > > If a jbi-component doesn't specify the bootstrap parameter to name its > bootstrap class the Maven JBI plugin should take the DefaultBootStrap from > the servicemix-commons project and copy it into the target/classes directory > and update the jbi.xml. -- 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
[jira] Created: (SM-619) Allow the Maven JBI plugin to inject a default bootstrap if one isnt' specified
Allow the Maven JBI plugin to inject a default bootstrap if one isnt' specified --- Key: SM-619 URL: https://issues.apache.org/activemq/browse/SM-619 Project: ServiceMix Issue Type: New Feature Components: tooling Affects Versions: 3.0 Reporter: Philip Dodds Priority: Minor Fix For: 3.0.1, 3.1 If a jbi-component doesn't specify the bootstrap parameter to name its bootstrap class the Maven JBI plugin should take the DefaultBootStrap from the servicemix-commons project and copy it into the target/classes directory and update the jbi.xml. -- 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
[jira] Closed: (SM-616) Archetypes for the servicemix-saxon service engine
[ https://issues.apache.org/activemq/browse/SM-616?page=all ] Philip Dodds closed SM-616. --- Resolution: Fixed Added servicemix-saxon-xslt-service-unit and servicemix-saxon-xquery-service-unit > Archetypes for the servicemix-saxon service engine > -- > > Key: SM-616 > URL: https://issues.apache.org/activemq/browse/SM-616 > Project: ServiceMix > Issue Type: New Feature >Affects Versions: 3.0.1 >Reporter: Philip Dodds > Fix For: 3.0.1 > > > Add archetype projects to the tooling directory for the new servicemix-saxon > project -- 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
[jira] Closed: (SM-591) Extend the servicemix-commons to provide better classloading semantics
[ https://issues.apache.org/activemq/browse/SM-591?page=all ]
Philip Dodds closed SM-591.
---
Resolution: Fixed
Refactored to add the support for the handling of Classloaders from within the
ServiceUnit, if a ServiceUnit implementation is going to provide Java classes
then it should return a classloader for that SU.
> Extend the servicemix-commons to provide better classloading semantics
> --
>
> Key: SM-591
> URL: https://issues.apache.org/activemq/browse/SM-591
> Project: ServiceMix
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Philip Dodds
> Fix For: 3.1
>
>
> Add a getConfigurationClassLoader to the ServiceUnit class in
> org.apache.servicemix.common. This can be used to ensure that is a
> ServiceUnit is going to contain Java Code then it needs to ensure that it
> provides a classloader.
> This method can then be used in the AsyncBaseLifeCycle in the method
> processExchange:
> Refactor the processExchange to be doProcessExchange and then create a new
> processExchange akin to this:
> ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
> try {
> if (getServiceUnit().getConfigurationClassLoader()!=null) {
> ClassLoader classLoader =
> endpoint.getServiceUnit().getConfigurationClassLoader();
> Thread.currentThread().setContextClassLoader(classLoader);
> }
> doProcessExchange(exchange);
> } finally {
> Thread.currentThread().setContextClassLoader(oldCl);
> }
--
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
[jira] Created: (SM-591) Extend the servicemix-commons to provide better classloading semantics
Extend the servicemix-commons to provide better classloading semantics
--
Key: SM-591
URL: https://issues.apache.org/activemq/browse/SM-591
Project: ServiceMix
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Philip Dodds
Fix For: 3.1
Add a getConfigurationClassLoader to the ServiceUnit class in
org.apache.servicemix.common. This can be used to ensure that is a ServiceUnit
is going to contain Java Code then it needs to ensure that it provides a
classloader.
This method can then be used in the AsyncBaseLifeCycle in the method
processExchange:
Refactor the processExchange to be doProcessExchange and then create a new
processExchange akin to this:
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try {
if (getServiceUnit().getConfigurationClassLoader()!=null) {
ClassLoader classLoader =
endpoint.getServiceUnit().getConfigurationClassLoader();
Thread.currentThread().setContextClassLoader(classLoader);
}
doProcessExchange(exchange);
} finally {
Thread.currentThread().setContextClassLoader(oldCl);
}
--
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
[jira] Resolved: (SM-563) service unite declaration orderi in jbi.xml does not correspond to the service assembly pom
[ https://issues.apache.org/activemq/browse/SM-563?page=all ] Philip Dodds resolved SM-563. - Fix Version/s: 3.0-M3 Resolution: Fixed Fix for SM-563 - its not pretty but it does work - basically the maven-project is not maintaining the order of the dependencies on the model - therefore we re-parse the model to get it back to its original state and thus back in the correct order. This issue with Maven has been fixed and should be available in 2.0.5 (commented the code to note this). > service unite declaration orderi in jbi.xml does not correspond to the > service assembly pom > --- > > Key: SM-563 > URL: https://issues.apache.org/activemq/browse/SM-563 > Project: ServiceMix > Issue Type: Bug > Components: tooling >Affects Versions: incubation >Reporter: Raffaele Spazzoli > Fix For: 3.0-M3 > > Attachments: sample-sa.zip > > > I declare the following ordering in service assembly pom: > 1,2,3,4 > and the generated jbi.xml has the following order > 1,4,3,2 > This is a problem when there are dependencies between service unit. > I think the jbi maven plugin can be fixed to preserve the order, nevertheless > I suggest to use maven dependency mechanism to deduct the right order. > So if su2 depends on su1 in its pom there should be dependency to su1 just > there is a dependcy to its component. > I attach the example that gives the error to me. Note that: > 1. you'll find a referred component that I'm developing so the project is non > deployable. Should not be necessary to debug. > 2. I don't use the dependecy form su to component, but the property > declaration. The dependency give me problems that I still don't understand. -- 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
[jira] Created: (SM-531) Improving Service Unit services generation
Improving Service Unit services generation -- Key: SM-531 URL: https://issues.apache.org/activemq/browse/SM-531 Project: ServiceMix Issue Type: Improvement Components: tooling Affects Versions: 3.0-M2 Reporter: Philip Dodds Priority: Minor Part of the tooling for service units is the use of the serviceUnitAnalyzer which is in place to try and generate the services elements of the service units which can be used by tooling to show the available consumes and provides. This process is currently looking in on the endpoints however it might be nice to have a ServiceProvider interface which endpoints can implement that would allow them to expose the consumes and provides. This would allow for good component design to provide information for the tooling to directly generate the services element of the jbi.xml for a Service Unit. -- 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
[jira] Resolved: (SM-517) Re-structure the common/soap shared libraries
[ https://issues.apache.org/activemq/browse/SM-517?page=all ] Philip Dodds resolved SM-517. - Resolution: Fixed Implemented new servicemix-shared library > Re-structure the common/soap shared libraries > - > > Key: SM-517 > URL: https://issues.apache.org/activemq/browse/SM-517 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-common, servicemix-soap >Affects Versions: 3.0-M2 >Reporter: Philip Dodds > Fix For: 3.0-M3 > > > Re-organize the common and soap libraries so they are normal jar packaging > and then create a new shared library called servicemix-shared that will have > both libraries embedded. > This removes the dependency that soap has on common being an issue when soap > is an SL. -- 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
[jira] Created: (SM-517) Re-structure the common/soap shared libraries
Re-structure the common/soap shared libraries - Key: SM-517 URL: https://issues.apache.org/activemq/browse/SM-517 Project: ServiceMix Issue Type: Improvement Components: servicemix-common, servicemix-soap Affects Versions: 3.0-M2 Reporter: Philip Dodds Fix For: 3.0-M3 Re-organize the common and soap libraries so they are normal jar packaging and then create a new shared library called servicemix-shared that will have both libraries embedded. This removes the dependency that soap has on common being an issue when soap is an SL. -- 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
[jira] Resolved: (SM-474) Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements
[ https://issues.apache.org/activemq/browse/SM-474?page=all ] Philip Dodds resolved SM-474. - Fix Version/s: 3.0-M3 Resolution: Fixed Added validation to the DesriptorFactory > Add validation code in for jbi descriptor to enforce the inclusion of > bootstrap classname and classpath elements > > > Key: SM-474 > URL: https://issues.apache.org/activemq/browse/SM-474 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-core >Affects Versions: incubation > Environment: Ubuntu Linux 5.10, Windows XP SP2 >Reporter: Grant McDonald > Assigned To: Grant McDonald > Fix For: 3.0-M3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Installers whose jbi.xml doesn't contain a bootstrap classpath and class name > are invalid as described by the jbi spec and also cause an NPE to be thrown > when the component is installed. Add in a validation on the jbi.xml to this > effect (hint: JbiElementProcessor or for an easier implementation - > DescriptorFactory) -- 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
[jira] Resolved: (SM-486) MessagePropertySetter
[ https://issues.apache.org/activemq/browse/SM-486?page=all ] Philip Dodds resolved SM-486. - Fix Version/s: 3.0-M3 Resolution: Fixed Applied and thankyou for the contribution > MessagePropertySetter > - > > Key: SM-486 > URL: https://issues.apache.org/activemq/browse/SM-486 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-components >Affects Versions: 3.0 >Reporter: Ramon Buckland >Priority: Minor > Fix For: 3.0-M3 > > Attachments: servicemix-components-mps.zip > > > A new component which sets properties on messages as it goes through > based on config. > A while back now I created this TransformComponentSupport based Component > which > assists in loading properties from XML config, and setting them on > JBI properties as the message goes through. > It's a little hard to explain, so here goes. > Essentially, sending a message past/through > the messagPropertySetter, will as name suggests > set some properties on the message. > The properties it sets is derived from a list > in the XML config file it is configured with. > The property-set name to use > can be supplied by > (a) a static spring configured name (thus making this component) > always apply the "same" set > (b) a value of a JBI property, which is used to determine the set > of properties to load > (c) an XPath expression which is evaluated against the incoming > message, and the resulting "string" is the name of the set > of properties to apply to the out message. > -- the VALUE of the properties from the chosen set is derived > by a list of "precdence" value Resolvers. > the Value for any one property is either > (a) a static string > (b) the value of an existing property > (c) the value of the xpath expresssion applied to the message. > These can be applied in any order, and the first that returns > a value, will be the value that is used. > - from the class comments > Sets properties on the message, loaded from an XML MPS file > where the properties to set are located in a > inside the XML config file. > > There can be more than one propertySet to "load". > >The property values are derived from 3 types of config. >The first config that can return a value as a String to >set onto the message, will be the "value" that is set >as that property. > > > As it's name suggests, the "value" of this element >will be the value of the JBI property. > >This is helpful as a default value, or as a static value. > > and > This will obtain the value of an existing property (itself) > or another property on the same message. > > This can be helpful when you want the to "ONLY" change the > the value of the property if there is some "xpath" expression > that could not be derived. > > name=".." form will copy the string value of the other JBI property > onto this one, (duping it). This may be handy when you have a > component which expects a new property, but you have it as a > different name at the moment. > > >As it's name suggests, will locate a value in the inMessage source >and set the resulting XPath String as the value of the JBI property. > >So given the three types, they can be arranged in any order. and the >first >PropertyValue Type that returns a value, will become the "value" of >the JBI property. > Regards > Ramon > A sample config looks like > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >... > > > > ... > > > > -- 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
[jira] Commented: (SM-481) servicemix-http provider truncates a large xml response
[ https://issues.apache.org/activemq/browse/SM-481?page=comments#action_36524 ] Philip Dodds commented on SM-481: - Added new test to org.apache.servicemix.http.HttpProviderTest.java which has a 640k message on an InOut with a provider. The test passed. Can you confirm you are running against the subversion HEAD? > servicemix-http provider truncates a large xml response > --- > > Key: SM-481 > URL: https://issues.apache.org/activemq/browse/SM-481 > Project: ServiceMix > Type: Bug > Components: servicemix-http > Environment: windows xp professional. Java 1.5 > Reporter: Pete > Priority: Critical > Fix For: incubation > Attachments: soap_response.txt > > > When using servicemix-http as a provider, our provider web service returns a > very large xml response, this gets truncated somewhere in servicemix (I did > notice when debugging it went down the stax xml route) > > We had the same problem when using SaajBinding, we fixed this locally by > extending the SaajBinding and overridng the > onMessageExchange > in particular just after the call() we added response.saveChanges(); e.g. > SOAPMessage response = connection.call(inMessage, soapEndpoint); > response.saveChanges(); > > This I believe was a known issue using this particular SAAJ implementation, > which is why saveChanges() was added to the api. > see > http://www.nabble.com/servicemix-http-provider-truncates-a-large-xml-response-tf1857975.html > for forum post > Our response xml is 673148 bytes. I have attached an example of the failing > soap response. Note: you'll need to remove header stuff and save as xml. The > response has a single xml element, where embedded (as a string) is another > xml document - nasty I know. > XML Config is > > service="my:httpBinding" endpoint="httpReceiver" > destinationService="my:router"> > > xmlns="http://xbean.org/schemas/spring/1.0"; > class="org.apache.servicemix.components.http.HttpConnector"> > value="localhost" /> > > > /> > > > > > Then there is an eip router that routes to > > > > endpoint="search" >role="provider" >soap="true" > > soapAction="http://www.blah.com/blah"; > > locationURI="http://www.blah.com:80/blah.asmx"/> > > > -- 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
