
|
If you were logged in you would be able to see more operations.
|
|
|
|
If a service's interfaces are delcared to have > 1 resource, the resulting parsed ClassBundles are wrong. For example:
(XML)
<ServiceBean Name='RaytraceService' Fork='yes'>
<Interfaces>
<Interface>net.gomez.raytraceservice.RaytraceService</Interface>
<Resources>
<JAR>lib/arl/arl-support.jar</JAR>
<JAR>lib/arl/arl-brlcadservice-dl.jar</JAR>
</Resources>
<Resources ref='client.jars'/>
</Interfaces>
...
</ServiceBean>
Will result in 2 ClassBundles being created instead of one.
The groovy parser does not handle this correctly. This is most likely due to the support that the interfaces element may have > 1 interface classes, each with it's own ClassBundle.
|
|
Description
|
If a service's interfaces are delcared to have > 1 resource, the resulting parsed ClassBundles are wrong. For example:
(XML)
<ServiceBean Name='RaytraceService' Fork='yes'>
<Interfaces>
<Interface>net.gomez.raytraceservice.RaytraceService</Interface>
<Resources>
<JAR>lib/arl/arl-support.jar</JAR>
<JAR>lib/arl/arl-brlcadservice-dl.jar</JAR>
</Resources>
<Resources ref='client.jars'/>
</Interfaces>
...
</ServiceBean>
Will result in 2 ClassBundles being created instead of one.
The groovy parser does not handle this correctly. This is most likely due to the support that the interfaces element may have > 1 interface classes, each with it's own ClassBundle. |
Show » |
|
We either need to support the current approach of one ClassBundle per class, or opt to change the approach in favor of 1 ClassBundle per Interfaces element that may contain more than 1 Interface class. This seems a more reasonable approach, since the same resources will be listed for each interface class.