| [wtp-dev] Fw: Server adapters and supporting BPEL module type |
|
Re-sending to a much bigger audience.
Hi Rob, Sorry for the delay. When I first read your email I was a little confused about what you were requesting. Perhaps it was due to my speed reading, but I wanted to sit down and read it in more details, before I ask any questions. With your second note things are more clear in my head now, thanks. We can certainly discuss this on the call today, the basis of what you are describing was not how the framework was intended. The idea for the framework is that server adapters need to define what modules support for their server, I can only assume that it was written like this because it didn't make much sense to allow a server adapter to try to deploy a module for which he doesn't know anything about, thus how would this module be published? do I need some extra configuration? If I am not mistaken Tomcat doesn't support BPEL out of the box, in such cases the the question becomes what should the eclipse server adapter support? Perhaps there is room for improvement here. Where a new extension point should be added to allow an adopter (not the tomcat adopter but ABC.com) to add behaviour to the default tomcat server adapter to allow tomcat to deploy other types of modules that ABC.com provides. I can see there might be a bit of challenges in here so that the extension can work correctly and intercept in the publishing and all other process correctly. There is a extension point out that there that was a moved towards this scenario. I don't have the information with me right now, but I can get it to you later. Best Regards, -- -- Mr. Angel Vera Server Tools Developer E-Mail: arvera@xxxxxxxxxx Tel: 905-413-5919 ----- Those who think that something is impossible, should not interfere with those who are willing to do it. - Angel Vera
Hey guys: I was trying to drum up a little discussion on the list, but apparently no one bit. To summarize, the BPEL project has been revitalized. They're using the flat component model and participants to expose it's members and such, and we want input as to whether this should be easy or hard for server adapters to consume. I believe it's easy, as jee tools already uses that method and it seems to work fine. The second issue is getting current server adapters to support this. If the server adapters are written correctly, all they should need to do is zip up this archive according to the servertools API and shove it into a deploy location, same as they do for web / ear / ejb / etc. Assuming the bpel code is functioning properly, all that should be needed from servertools is the one or two lines in each adapter's plugin.xml that says they support "bpel.module" as a module type. The third issue is a potential API deficiency in servertools and I was hoping we could chat it out. If I make a new project type / module type nobody knows about, and I make *SURE* it follows servertools API for module resources / child modules / etc, I still cannot get it to deploy to any generic servers because those generic servers must outline their module support explicitly in plugin.xml. This means any time I make a new project type, I have to come hound every server adapter to explicitly set support for it in their plugin.xml, not just to get support or wider recognition, but for the tool to even ALLOW you to deploy at ALL. So if I make an ESB project / module type, and I know I can squeeze it into a tomcat installation, it won't work. If I make a bpel module type, and I know it's easily packaged and zipped same as ear / war, I can't. If I make wtpisAwesome.module, none of the server adapters can deploy it, unless they add to plugin.xml that they support it as a module type. If your world view is limited to jee with 4 or 5 module types, this doesn't seem like a problem. But the whole point of a servertools API is to standardize deployment and allow arbitrary module factories to expose their resources in a way that any server adapter can consume them. Shouldn't there then also be an option for these server adapters to say they can deploy things they might not know about so long as they're exposed properly via the servertools IModuleResource API? I had wanted to have a chat today about it on the con-call, but apparently there isn't one scheduled. http://wiki.eclipse.org/JEE_Status_Meetings - Rob -------- Original Message --------
Would like to stress that none of this is BPEL specific - it is a common problem we bump into on how to support custom packaging for archives/deployments that aren't necessarily a jar, war or ear. /max On Sep 30, 2010, at 10:21, Rob Stryker wrote: > > Hi All: > > The BPEL project here at eclipse has been relatively dormant for a long period and has experienced some recent rework. The BPEL project has converted itself into a modulecore project, with a module factory very similar to the one in jeetools, minus a few of the participants that jeetools uses for replacing manifest files and such. > > We believe strongly that there is enough API to properly publish these modules in a generic server without significant modification, by simply zipping up the module core project according to its module assembly configuration and attaching a proper suffix at the end. We believe this could easily be added by the Generic Server team (as well as other server adapters), and we're wondering if anyone sees any roadblocks, any problems with this, or can offer any roadmap or guidance to this process. > > Basically we just want to make sure that people don't see a problem supporting another module type which doesn't do anything weird or strange and just follows the servertools API pretty strictly. We'd be much obliged if someone would give it a whirl. Problem is, they'd need to modify one of the generic servers to support the module type and version. > > - Rob Stryker > > You can check out the bpel plugins over at: dev.eclipse.org /cvsroot/technology org.eclipse.bpel > > PS - I still find this somewhat unusual. Generic Server often casts into jee-tools specific interfaces and uses jee-tools specific API. If generic server wanted to support bpel and bpel-tools also had custom interfaces, generic server publishers would also depend on bpel classes. Extend this to ESB projects, other SOA-type projects, and custom interfaces for all, and you end up with a server adapter that must depend on the entire world in order to be able to publish a new project type. > > This obviously hinders adoption of new project types, if all server adapters feel it might add compile dependencies on all such new projects with custom interfaces, and this becomes very problematic. > > Either way, the bpel project as of now has no such custom interfaces that would be needed and so should be a relatively minor fix for server adapters to support. > _______________________________________________ > wtp-dev mailing list > wtp-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev |
