Hi list Angel Vera wrote:
> 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? > As I read the post, the requested functionality is that of "Project kind" -> Package format -> Server Adapter e.g. BPEL -> WAR -> Tomcat Today, we have a 1:1 mapping of the kind of project we support (i.e. Dynamic Web) and the kind of package to deploy (e.g. WAR). > 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. > As I understand it, it woud be more like an extension point which would map a ABC.com "virtual" module type into a module type which WTP understands and the servers can deploy. -Jesper > 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: [email protected] > Tel: 905-413-5919 > ----- > Those who think that something is impossible, > should not interfere with those who are willing to do it. - Angel Vera > > <graycol.gif>Rob Stryker ---10/07/2010 01:57:17 AM---Hey guys: I was trying > to drum up a little discussion on the list, but apparently > > <ecblank.gif> > From: <ecblank.gif> > Rob Stryker <[email protected]> > <ecblank.gif> > To: <ecblank.gif> > "ccc >> Carl Anderson" <[email protected]>, [email protected], Angel > Vera/Toronto/i...@ibmca, Tim deBoer/Toronto/i...@ibmca, Max Rydahl Andersen > <[email protected]> > <ecblank.gif> > Date: <ecblank.gif> > 10/07/2010 01:57 AM > <ecblank.gif> > Subject: <ecblank.gif> > Fwd: Re: [wtp-dev] Server adapters and supporting BPEL module type > > > > 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 -------- > Subject: > Re: [wtp-dev] Server adapters and supporting BPEL module type > Date: > Fri, 1 Oct 2010 14:33:45 +0200 > From: > Max Rydahl Andersen <[email protected]> > Reply-To: > General discussion of project-wide or architectural issues. > <[email protected]> > To: > General discussion of project-wide or architectural issues. > <[email protected]> > > > 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 > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/wtp-dev > > _______________________________________________ > wtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev > > > > _______________________________________________ > wtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
