[JBoss JIRA] Created: (SWITCHYARD-435) Provide a stand-alone "installer" to add SwitchYard to an existing AS7 install
by Keith Babo (JIRA)
Provide a stand-alone "installer" to add SwitchYard to an existing AS7 install
------------------------------------------------------------------------------
Key: SWITCHYARD-435
URL: https://issues.jboss.org/browse/SWITCHYARD-435
Project: SwitchYard
Issue Type: Feature Request
Components: distribution
Reporter: Keith Babo
Fix For: 0.3
It would be nice to have a way to add the SwitchYard modules and other resources to an existing AS7 installation. This does not have to be a full-blown installer. It could just be another distro with an ant script or maybe a maven pom that takes the bits and slaps them into AS7. This shouldn't be much more than copying in modules, updating the standalone configuration (maybe give the user a choice of the config - e.g. standalone, standalone-preview), deploying our admin console, etc., etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SWITCHYARD-432) Resolve XML validation errors in HornetQ test files
by Rob Cernich (JIRA)
Resolve XML validation errors in HornetQ test files
---------------------------------------------------
Key: SWITCHYARD-432
URL: https://issues.jboss.org/browse/SWITCHYARD-432
Project: SwitchYard
Issue Type: Bug
Reporter: Rob Cernich
Priority: Minor
Fix remaining XML validation errors in HornetQ component test files. The files in question are:
/switchyard-component-hornetq/src/test/resources/org/switchyard/component/hornetq/config/model/v1/hornetq-all-binding.xml
/switchyard-component-hornetq/src/test/resources/org/switchyard/component/hornetq/config/model/v1/hornetq-valid-implementation.xml
The first file barfs on "browseOnly" which is not defined in the schema. I'm not sure if this element should be removed from the test file or added to the schema (and incorporated into the binding activator).
The second file defines a HornetQ implementation for a service component. A HornetQ implementation element is not defined in the HornetQ schema. I'm assuming the HornetQ schema should be modified to include an implementation definition, but I'm not sure.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SWITCHYARD-431) Resolve XML validation errors in Camel test files
by Rob Cernich (JIRA)
Resolve XML validation errors in Camel test files
-------------------------------------------------
Key: SWITCHYARD-431
URL: https://issues.jboss.org/browse/SWITCHYARD-431
Project: SwitchYard
Issue Type: Bug
Components: component-camel
Reporter: Rob Cernich
Priority: Minor
Fix remaining XML validation errors in Camel component's test files. The files in question are:
/switchyard-component-camel/src/test/resources/org/switchyard/component/camel/config/model/v1/switchyard-atom-binding.xml
/switchyard-component-camel/src/test/resources/org/switchyard/component/camel/config/model/v1/switchyard-direct-binding-beans.xml
The first file should probably include a model validation check in its unit test.
The second file can probably be deleted. (The file used by the direct tests has the same name, but in a different directory.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SWITCHYARD-430) Model merge does not merge schemaLocation attributes
by Rob Cernich (JIRA)
Model merge does not merge schemaLocation attributes
----------------------------------------------------
Key: SWITCHYARD-430
URL: https://issues.jboss.org/browse/SWITCHYARD-430
Project: SwitchYard
Issue Type: Bug
Components: configuration
Reporter: Rob Cernich
Priority: Optional
Unit tests in switchyard-config use local test schema that are resolved using a relative URI. When the test schema are merged, the schemaLocation attribute on the resulting document does not contain all the locations specified. Because of this, the document used to validate the merge contains errors. The files in question are:
/switchyard-config/src/test/resources/org/switchyard/config/model/composite/CompositeModelTests-Complete.xml
/switchyard-config/src/test/resources/org/switchyard/config/model/switchyard/SwitchYardModelTests-Complete.xml
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SWITCHYARD-428) Defining resources as classes in @Process and @Rules is clunky
by David Ward (JIRA)
Defining resources as classes in @Process and @Rules is clunky
--------------------------------------------------------------
Key: SWITCHYARD-428
URL: https://issues.jboss.org/browse/SWITCHYARD-428
Project: SwitchYard
Issue Type: Bug
Components: common, component-bpm, component-rules
Affects Versions: 0.2
Reporter: David Ward
Assignee: David Ward
Fix For: 0.3
Using the switchyard maven plugin and the BPMSwitchYardScanner, the following BPM component configuration:
<component name="MyService">
<implementation.bpm processDefinition="META-INF/MyService.bpmn" processDefinitionType="BPMN2" processId="MyService">
<taskHandler class="org.switchyard.component.bpm.task.SwitchYardServiceTaskHandler" name="SwitchYard Service"/>
<resource location="/META-INF/MyServiceRules.drl" type="DRL"/>
</implementation.bpm>
<service name="MyService">
<interface.java interface="org.switchyard.userguide.MyService"/>
</service>
</component>
can be auto-generated from this:
@Process(value=MyService.class, resources={MyServiceRules.class})
public interface MyServiceProcess extends MyService {
public static final class MyServiceRules extends SimpleResource {
public MyServiceRules() {
super("/META-INF/MyServiceRules.drl", "DRL");
}
}
}
Similarly, using the switchyard maven plugin and the RulesSwitchYardScanner, the following Rules component configuration:
<component name="MyService">
<implementation.rules stateful="false">
<rulesAction name="process" type="EXECUTE_RULES"/>
<resource location="/org/switchyard/userguide/MyService.drl" type="DRL"/>
</implementation.rules>
<service name="MyService">
<interface.java interface="org.switchyard.userguide.MyService"/>
</service>
</component>
can be auto-generated from this:
@Rules(value=MyService.class, resources={MyServiceDrl.class})
public interface MyServiceRules extends MyService {
@ExecuteRules
public void process(MyData data);
public static final class MyServiceDrl extends SimpleResource {
public MyServiceDrl() {
super("/org/switchyard/userguide/MyService.drl", "DRL");
}
}
}
The problem is that using a CLASSES array (of static classes) to define resources is VERY clunky, and causes the user to write a lot more code than he/she needs to. Instead, the resources array of the Rules annotation should instead just be an array of STRINGS pointing to the location of the resources.
The original reasoning behind using classes was that there were two different pieces of data to describe a resource: a location and a type. However, as part of this work, if we add a way for the ResourceType class (which already exists and is extensible to user-added types) to deduce the type via the file extension, then just the location would be required.
With this change, the above BPM code would be reduced to this:
@Process(value=MyService.class, resources={"/org/switchyard/userguide/MyService.drl"})
public interface MyServiceProcess extends MyService {}
, and the above Rules code would be reduced to this:
@Rules(value=MyService.class, resources={"/org/switchyard/userguide/MyService.drl"})
public interface MyServiceRules extends MyService {
@ExecuteRules
public void process(MyData data);
}
A lot cleaner!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SWITCHYARD-427) SwitchYardFacet should validate config xml
by David Ward (JIRA)
SwitchYardFacet should validate config xml
------------------------------------------
Key: SWITCHYARD-427
URL: https://issues.jboss.org/browse/SWITCHYARD-427
Project: SwitchYard
Issue Type: Bug
Components: configuration, tooling
Affects Versions: 0.2
Reporter: David Ward
Assignee: David Ward
Fix For: 0.3
Similar to how the ConfigureMojo of the Maven SwitchYard plugin validates the outputted model configuration xml by default, but has an option to disable it, the SwitchYardFacet should also validate it's outputted xml, most likely triggered by writeSwitchYardConfig(). It is important that this can be disabled, though, in case the user plans on post-processing the xml to make it valid. Here is how the ConfigureMojo does it: http://goo.gl/Kgebe
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months