RE: [wtp-dev] RE: Server API change proposal

["Ted Bashor" <tbashor@xxxxxxx>]

The idea is that server providers and extenders can mix and match
delegates that perform specific bits of the publish and export process
as they wish.

For example, assuming a complete Tomcat publish/export solution
continues to ship as part of WTP, there might be two delegates for
publish, one that copies WAR content to a directory based on the default
WTP/JDT project metadata, and one that deploys that directory to Tomcat.
For export there would also be two delegates, the same one that
assembles a WAR in a directory, one that zips it up into a .war.

The assembly and/or deploy delegate could then be replaced in a custom
solution, or its capabilities extended (if this type of virtual war is
standard), to avoid copying.

-Ted

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Igor Fedorenko
Sent: Wednesday, March 22, 2006 6:59 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] RE: Server API change proposal

Will this work for servers that are able to deploy EAR/WAR by reference 
to workspace, i.e. actual EAR/WAR structure is not assembled during
publish?

Ted Bashor wrote:
> One thing I would add is that the Publish process and the Archive
Export 
> process should be very, very similar from an extension/api point of
view.
> 
>  
> 
> For both processes, I'd suggest that the WTP framework should be based

> on running an ordered list of delegates registered to module/facet id
+ 
> server/runtime id.  WTP would include some default/reference delegate 
> implementations - e.g. ones that assemble an EAR, WAR, or EJB in a 
> directory, ones that deploy to Tomcat, etc.
> 
>  
> 
> -Ted
> 
>  
> 
>
------------------------------------------------------------------------
> 
> *From:* Thomas Yip
> *Sent:* Monday, March 20, 2006 7:01 PM
> *To:* General discussion of project-wide or architectural issues.
> *Cc:* Ted Bashor; Konstantin Komissarchik; Gorkem Ercan; Sachin Patel;

> Timothy Deboer
> *Subject:* Server API change proposal
> 
>  
> 
> 
>     */Introduction/*
> 
> This proposal briefs the limitation we see with current server publish

> API, and it suggests a solution. We had a short discussion during a 
> conference call on Mar 13^th , 2006. (mainly around the 
> ServerBehaviourDelegate). The problem is also related to 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=123676
> 
>  
> 
> 
>     */Current API/*
> 
> We learned the original design was driven by a need of a very simply 
> publish mechanism.
> 
>    1. an adopter should able to implement a simply delegate and do the
>       publish work.
>    2. publish tasks was intent to be simple task.
>    3. most methods can be overridden.
> 
>  
> 
> 
>     */BEA use-cases/*
> 
> We found the current API is not ideal for BEA needs.
> 
>  
> 
> We delay much of publish process until user do an explicit publish 
> action (menu item publish, or Run on Server).
> 
>  
> 
>    1. We generates *.java file based on annotation of Java file in
>       publish time. We trigger project rebuild during process.
>    2. We insert information into application descriptors (web.xml,
>       application.xml) based on files on the project.
>    3. Generated artifacts can cause changes to the EAR or other
modules
>       in the same application.
>    4. Publish application by application.
>    5. Publish failure should be isolated between modules.
> 
>  
> 
> For us, the publish process is better described as a 3 steps process: 
> Assembly (artifact generation), Packaging (we package virtually), and 
> Distribution (calls JSR-88 to distribute the application to the
server).
> 
> 
>     */Limitation/*
> 
> The current SPI was driven by the need of simple publishing. The
publish 
> process iterates module by a flattend module list (not application by 
> application.)
> 
>  
> 
> Because that most methods can be overridden, we can achieve our goal 
> reasonably well. However, it incurs maintenance risk, because are not 
> really implementing the delegate's SPI. For example,
> 
>    1. if a fix or an enhancement is made to PublishOperation, our
server
>       adapter lag behind, and enhancement will not be supported.
>    2. We short circuit a few methods, such as publishModules() (which
is
>       a violate the interface). If any of the methods is called by new
>       code that we haven't overridden, it causes unexpected behaviour.
> 
>  
> 
> Because of the different design goal, we don't implement the full spec

> of ServerBehaviourDelegate. While such changes might not be likely, an

> adopter should not be required to implement their delegate in a way to

> violate the SPI contract.
> 
> 
>     */Solution/*
> 
> 
>       *Required changes*
> 
> We can eliminate the problem by the following changes:
> 
>  
> 
>    1. Introduce another delegate. Let's call it
>       BaseServerBehaviourDelegate for now. The current
>       ServerBehaviourDelegate should make extended of
>       BaseServerBehaviourDelegate. Most generic methods can be push
up.
>       (such as state settings, module controls, resource delta
>       maintaince. But, it leaves out
>          1. code related to published module list, and the kind.
>             PublishOperation, and
>          2. all the publish methods. Introduce an adapter interface to
>             indicate PublishOperation is supported.
> 
>  
> 
> The changes will maintain compatibility for all current adopter, and
the 
> original design goal. It enables adopter with different needs to have 
> full control of the publish process.
> 
>  
> 
>    2.  
>          1. Either, makes publish operation optional. Push down
>             PublsihOperation related code to the original
>             ServerBehaviour Delegate.
>          2. Or, factors out PublishOperation into utility class or
method.
>          3. Or, made PublishOperation not depends on the flatten
module
>             path (IModule[] representing the sub module and its
parents).
>    3. Introducing another extension point for UI to replace the
>       hard-coded publishTask page fragment. Move UI for
publishOperation
>       as an extension.
> 
>  
> 
> A brief study of the code indicated that we should able to implement
it 
> in a way that it doesn't affect existing adopter.
> 
>  
> 
> 
>       */Optional changes/*
> 
> A few optional changes can be introduced to ease the work of an
adopter.
> 
>  
> 
>    1. Publishing application-by-application is common to many servers.
>       We might want to introduce another BehaviourDelegate.
>    2. Generic server is already use application-by-application
approach.
>       We should look into merging the requirements.
>    3. Going further, we can also introduce the 3 steps publish process
>       for adopter with complicated publish use-case.
> 
>  
> 
>  
> 
>  
> 
> --------------------
> 
> Thomas Yip
> 
> Senior Software Engineer
> 
> BEA Systems
> 
> Email: tyip@xxxxxxx <mailto:tyip@xxxxxxx>    YIM: thomasleaf    Phone:

> (206) 926-2906   Blog: http://theBigGrid.com/


_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.