[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
