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

["Thomas Yip" <tyip@xxxxxxx>]

I certainly agree publishing at app level is more natural. But, I think
the need of very simple publish delegate is also valid. WTP potentially
support other Server type...


Thomas

> -----Original Message-----
> From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Sachin Patel
> Sent: Tuesday, March 21, 2006 6:04 AM
> To: General discussion of project-wide or architectural issues.
> Subject: [wtp-dev] Re: Server API change proposal
> 
> I personally think publishing at the app level is a more natural/
> logical approach and the need of a second delegate class should be
> only temporary until other server adapters can conform to this
> proposal.  I also have some concerns on how the delta is managed and
> flushed, but need some time to gather my thoughts so that can be
> discussed later.
> 
> - sachin
> 
> 
> 
> On Mar 20, 2006, at 7:01 PM, Thomas Yip wrote:
> 
> > 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 13th, 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.
> >
> > an adopter should able to implement a simply delegate and do the
> > publish work.
> > publish tasks was intent to be simple task.
> > 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).
> >
> >
> >
> > We generates *.java file based on annotation of Java file in
> > publish time. We trigger project rebuild during process.
> > We insert information into application descriptors (web.xml,
> > application.xml) based on files on the project.
> > Generated artifacts can cause changes to the EAR or other modules
> > in the same application.
> > Publish application by application.
> > 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,
> >
> > if a fix or an enhancement is made to PublishOperation, our server
> > adapter lag behind, and enhancement will not be supported.
> > 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.
> >
> > SolutionRequired changes
> > We can eliminate the problem by the following changes:
> >
> >
> >
> > 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
> > code related to published module list, and the kind.
> > PublishOperation, and
> > 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.
> >
> >
> >
> >
> > Either, makes publish operation optional. Push down
> > PublsihOperation related code to the original ServerBehaviour
> > Delegate.
> > Or, factors out PublishOperation into utility class or method.
> > Or, made PublishOperation not depends on the flatten module path
> > (IModule[] representing the sub module and its parents).
> > 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.
> >
> >
> >
> > Publishing application-by-application is common to many servers. We
> > might want to introduce another BehaviourDelegate.
> > Generic server is already use application-by-application approach.
> > We should look into merging the requirements.
> > 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    YIM: thomasleaf    Phone: (206) 926-2906
> > Blog: http://theBigGrid.com/
> >
> >
> >
> > "The complexity you remove can never fail." Burt Rutan.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
______________________________________________________________________
> > _ 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.
> 
> _______________________________________________
> 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.