EAR support on version 1.0

[edevera]

I've read and experienced what I would call a not fully supported EAR deployables until now. Is there any official statement regarding what to expect of version 1.0 on this matter? I particularly favor EARs rather than WARs because of different reasons among which probably the most significant is a finer grained class loader hierarchy and a cleaner separation of responsibilities of the modules inside the EAR.

So, will EARs be first class citizens in Switchyard on version 1.0? Is there any place where I could see what's ahead for such deployables from Switchyard's perspective?

Thanks.

[kcbabo]

Hey Eduardo,

EARs are definitely a supported deployment option.  I know you have experienced some issues with EAR deployment in the past, but I think they were either general SY issues unrelated to EARs (cross-application communication via binding.sca) or packaging/deployment issues when using SY with Arquillian.  Are there other issues that are unresolved at this time?

There are no additional issues related to EAR deployment scheduled for 1.0 at this time.  If you have a list of things you'd like to see, please share here or file a JIRA and we'll discuss.

cheers,

keith

[edevera]

Hello Keith,

I don't have a list of actual issues that we are experiencing with the EAR deployments but we hit an issue everynow and then. For example, we have an EAR that contains several Ejb Modules, each one containing its on Switchyard Application. These different Switchyard Applications have some elements in common (such as Transformers and Validators). When these common elements are put in the lib folder in order to be made available to all services inside the EAR, Switchyard produces an error. If the these elements are moved to their own Ejb Module (with an empty Switchyard xml) and class dependencies are resolved using the Manifest.MF file, then Switchyard doesnt complain. I do find this what I would call a workaround but not the desired way to deploy my applications. What do you think?

If you don't mind I suggest we post to this thread all issues experienced due to EAR based deployments.

[kcbabo]

If adding shared classes/resources in EAR/lib is not working, then that's definitely a problem.  Agree on using this as a forum to record EAR issues.  I can slap together a test app to use in our release integration build to verify that any issues are fixed (and stay fixed).  We do have an EAR deployment already, but it does not test some of these cases.

[edevera]

Is it a must that a SwitchYard application bundled in an EAR must always be a module (ejbModule, warModule or jarModule)?

Could it be acceptable to have it as a library?

[kcbabo]

I haven't tried it, but I don't think that will work.  The deployment processor needs to know which bits of the EAR to pick up and deploy.

BTW, an EAR quickstart has been added in 1.0 and is tested as part of our release build:

https://github.com/jboss-switchyard/quickstarts/tree/master/ear-deployment