| RE: [wtp-dev] server architecture discussion |
|
We will be holding a followup meeting next
Monday, same time, same dialin. Time: Monday, 3/13 11 AM PST / 2 PM EST Toll free: 866-214-3176 Passcode: 8870689 Required reading is Konstantin’s “Proposal
for Common Runtime Component” email. Discussing this, and how it
relates to eliminating the runtime bridge, is first on the (my) agenda. Other items we can discuss include general
server/publish API changes (see below) and Konstantin’s “Proposal
for Merging Server Runtime and Server Instance”. -Ted From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Ted Bashor Some talking points for the call.
Apologies if I didn’t capture some of the suggestions, I’m sure
this is way more than we’ll have time to cover today. 1) Bridge between
org.eclipse.wst.common.project.facet.core.runtime.IRuntime and
org.eclipse.wst.server.core.IRuntime * implementing a runtime requires using two different api /
extension points. * interacting with the runtime, one has to move across the
boundary between the server tools and the j2ee tools / facets. * Poor performance. Since the bridge does not know when the
runtimes change, it is forced to do a lot of unnecessary work to make sure it
doesn't get out of sync. * Very difficult to take advantage of some of the extensibility
offered by the faceted project runtimes. For instance, in order to have
runtimes with more than two runtime components, one has to implement a custom
runtime bridge. * Unable to add "New" button (to create a new runtime)
to the facet selection panel since the project facets framework has no idea how
runtimes are created and they maybe coming from multiple sources (multiple
bridges). 1a) https://bugs.eclipse.org/bugs/show_bug.cgi?id=111545
- relationship server instance configuration to the server.core and facet
runtime representations. 2) Server Adapter API (publish) * Have found the module array difficult to work with.
Publish Tasks and Module Publishers generally need to operate on, or
within the context of, each EAR, Standalone WAR, Standalone EJB module
heirarchy. (See Bug 123676.) * Need to be able to abort the publishing of an individual EAR,
Stndalone WAR, or Stndalone EJB, while allowing other deployable units to
continue to process/publish. * User interaction during publish process? 3) Typing and filtering of (component) resources used during publish * Mechanism for publish tasks/publish process delegate to facet
implementation classes? 4) File delta perf/scalability From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Ted Bashor Would like to invite interested parties to participate in a
WTP server tools architecture call on Monday. This is an opportunity to discuss any outstanding
architecture issues and to design solutions -- perhaps temporarily setting
aside annoying practicalities like schedule and api changes :-) I’ll try to send out an agenda doc Monday morning with
some topics. The primary one for us is the facet runtime bridge.
But please feel free to send me any other items you’d like to discuss. Time: Monday, 2/27 11 AM PST / 2 PM EST Toll free: 866-214-3176 Passcode: 8870689 Thanks, Ted tbashor@xxxxxxx _______________________________________________________________________ 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. _______________________________________________________________________ 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. _______________________________________________________________________ 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. |