I believe my solution is non-breaking, and
the change is pretty contained.
The two delegate models requires no change
to any adapter that extends the original delegate. Other changes are internal
to the server.core, and they are not method that user or adopter will call.
If people feel the proposal is reasonable,
I can develop the patch. And, we can discuss and iterate on that.
Thomas
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Arthur Ryman
Sent: Tuesday, March 21, 2006 1:40
PM
To: General
discussion of project-wide or architectural issues.
Cc: Ted
Bashor; Gorkem Ercan; General
discussion of project-wide or architectural issues.;
wtp-dev-bounces@xxxxxxxxxxx; Konstantin Komissarchik; Timothy Deboer
Subject: Re: [wtp-dev] Server API
change proposal
Thomas,
Recall
that any change MUST be non-breaking. You can add API and change the old API in
safe ways. Do you have a concrete design?
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
"Thomas Yip"
<tyip@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
03/20/2006 10:01 PM
Please
respond to
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General
discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
cc
|
Konstantin Komissarchik
<kosta@xxxxxxx>, Timothy Deboer/Toronto/IBM@IBMCA, Ted Bashor <tbashor@xxxxxxx>, Gorkem Ercan
<gorkem.ercan@xxxxxxxxx>
|
Subject
|
[wtp-dev] 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 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.
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
a.
code related to published module list,
and the kind. PublishOperation, and
b.
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.
a.
Either, makes publish operation
optional. Push down PublsihOperation related code to the original
ServerBehaviour Delegate.
b.
Or, factors out PublishOperation into
utility class or method.
c.
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 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.
|