Home » Eclipse Projects » Equinox » eclipse core in a web application context
| eclipse core in a web application context [message #28479] |
Tue, 15 July 2003 02:57  |
Eclipse User |
|
|
|
Originally posted by: john-mason.shackelford.org
As Eclipse has made great headway in moving java development toward a
component based approach, I have been thinking about how we might
leverage the core in building component based web applications. A number
of other posts have suggested others have been thinking along similar lines.
While web applications do not benefit from lazy loading plugins in the
same way that a GUI would (a web app would happily have a long startup
if each request were handled quickly), they sorely need the sort of
drop-in component & extension mechanism offered by Eclipse core.
As others have pointed out, the class loading mechanism of a web
container is similar to that of eclipse, yet a fear that direct
modifications to tomcat, jboss, etc. in order to facilitate bringing
these two systems together could jeopardize the usefulness of a
framework for building web applications as clients would no longer have
the option of using popular application servers. Perhaps one could write
a servlet that would be responsible for bootstrapping the core and
another which would serve as an extensible dispatcher through which all
requests would be routed. One could then build a core framework of
fundamental extension points, much as the platform does today.
While I recognize that this approach does, in some sense, circumvent the
container & standard WAR deployment, I'd argue that Eclipse has shown us
that for component based development to flourish, the platform must
offer a suitably granular extension mechanism. Though frameworks like
struts have attempted to ease the burden, existing technologies do not
allow web application developers to create drop-in functional components
more granular than fully functioning web applications, servlets, or
services.
I'd be interested to learn if others have had similar thoughts and
whether this approach seems feasible as it relates to the on-going work
of Equinox.
John-Mason P. Shackelford
|
|
|
| Re: eclipse core in a web application context [message #28932 is a reply to message #28479] |
Tue, 15 July 2003 13:54  |
| Eclipse User |
|
|
|
Originally posted by: birsan.nospam.ca.ibm.com
There have been some discussions on the eclipse.tools newsgroup (now
deprecated) on this topic, primarily related to the built-in eclipse app
server.
We have protoyped a number of solutions in the eclipse help system to
support dynamic help content, but ended up with a simple extension point.
Since web applications running inside the eclipse appserver (which is
actually a pluggable server, currently the default is tomcat) have access to
the containing plugin runtime, one can easily employ the plugin model to
extend web apps.
The dispatcher model you describe was used in the eclipse 2.0 help system
infocenter, where we used pluggable url stream handlers to accomplish this
in a pluggable way. A dispatcher servlet created URLConnections using custom
url stream handlers defined by plugins (org.eclipse.core.runtime.urlHandler
ext point). This approach required some special app server settings as well
as playing some class loader tricks to avoid conflicts between different xml
versions (java, app server, eclipse), and unique url stream handlers in a
vm.
Do you have any particular usage scenarios in mind ?
-Dorian
"John-Mason P. Shackelford" <john-mason@shackelford.org> wrote in message
news:3F136D7E.40006@shackelford.org...
>
> As Eclipse has made great headway in moving java development toward a
> component based approach, I have been thinking about how we might
> leverage the core in building component based web applications. A number
> of other posts have suggested others have been thinking along similar
lines.
>
> While web applications do not benefit from lazy loading plugins in the
> same way that a GUI would (a web app would happily have a long startup
> if each request were handled quickly), they sorely need the sort of
> drop-in component & extension mechanism offered by Eclipse core.
>
> As others have pointed out, the class loading mechanism of a web
> container is similar to that of eclipse, yet a fear that direct
> modifications to tomcat, jboss, etc. in order to facilitate bringing
> these two systems together could jeopardize the usefulness of a
> framework for building web applications as clients would no longer have
> the option of using popular application servers. Perhaps one could write
> a servlet that would be responsible for bootstrapping the core and
> another which would serve as an extensible dispatcher through which all
> requests would be routed. One could then build a core framework of
> fundamental extension points, much as the platform does today.
>
> While I recognize that this approach does, in some sense, circumvent the
> container & standard WAR deployment, I'd argue that Eclipse has shown us
> that for component based development to flourish, the platform must
> offer a suitably granular extension mechanism. Though frameworks like
> struts have attempted to ease the burden, existing technologies do not
> allow web application developers to create drop-in functional components
> more granular than fully functioning web applications, servlets, or
> services.
>
> I'd be interested to learn if others have had similar thoughts and
> whether this approach seems feasible as it relates to the on-going work
> of Equinox.
>
> John-Mason P. Shackelford
>
|
|
|
| Re: eclipse core in a web application context [message #28965 is a reply to message #28932] |
Tue, 15 July 2003 15:18 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Dorian,
Thanks for your response. I have been looking at the InfoCenter code and
it is helpful.
> Do you have any particular usage scenarios in mind?
I have a few requirements, but am only beginning to explore the
possibilities.
Note that this is at the outer limit of the original Eclipse mandate.
The solution I envision is a foundation for web applications, and does
not have any desktop GUI component; nevertheless, it uses Eclipse core
and should interoperate with Eclipse plugins that do not have a UI or
resource/workspace management.
My solution needs to be fairly independent of the app server
implementation. I'd like to be able to deploy an EAR with the Eclipse
bootstrapping servlet, and add plugins and features (either inside the
ear or in a specified external directory structure--not sure which makes
most sense) to build up my web application.
The extension points would want to have available for extension might
include (painting in very broad strokes):
* request (command) handlers -- route a request to an appropriate
component based on URL
* input processing -- handle form input, validation, etc. of request
parameters
* page layout -- plugable templating, perhaps like Struts tiles.
* html widgets -- an alternative to JSP tag libs that provides a
(with the proper tooling) a visual way to define dynamic,
data driven components which could be reused to build up pages.
* actions -- just as in the Eclipse UI but encapsulating either a
new request or else client-side scripting.
* preferences -- an admin site built with these components that
will allow site administrators to configure plugins, select
between them when two or more implementations for a single
function exists, etc.
My initial sketches suggest that these actually break down into many,
many individual extension points, but this should indicate the direction
I'm headed with this.
I understand that frameworks like Struts already provide many of these
services (and perhaps Struts code could be leveraged in building this)
but what these frame works do not provided in a component based
extension mechanism. Done properly, the approach I am suggesting would
allow one to add a new tab at the top of an existing web page (built on
the framework) simply by adding my plugin. I should not have to modify
any XML descriptors in doing so, other than those of my plugin. (Every
mvc framework I've seen for web applications requires that users
maintain a central map of requests to the java components which handle
them. The beauty of the Eclipse plugin registry is that this mapping can
be distributed among individual plugins.)
My first effort needs to be the bootstrapping servlet. Before I march
too far down this road does anyone see any problem launching Eclipse
core from a servlet with the core.boot classes?
Obviously we will not want to relaunch Eclipse with every request, only
on servlet startup. The plugin registry, etc. will be persistent across
requests perhaps via a singleton.
John-Mason
|
|
|
| Re: eclipse core in a web application context [message #29003 is a reply to message #28965] |
Tue, 15 July 2003 16:29 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Dorian,
I have found your post from the tools news group (10/28/2002):
> The current infocenter (to be significantly modified this week) uses
> the BootLoader mechanism to load eclipse inside a servlet and
> communicate with it. There are some problems with this approach, in
> particular the URL stream handlers, xml parsers, etc.
> We are moving aways from embedding eclipse directly into a servlet,
> and call it as an external process instead, using its own tomcat
> server.
> So, take a look at org.eclipse.core.boot.BootLoader and
> org.eclipse.core.runtime.IPlatformRunnable if you still want to call
> eclipse from your servlet.
Were the problems you were having related to the container's class
loader? I interpreted Mel Martinez's comments about the way a container
protects itself with seperate class loaders for iteself & for the
webapps it hosts as suggesting that the container's XML parser would not
necessarily be inflicted upon the applications it hosts. On the other
hand, I'd bet this varies from container to container. I believe I once
encountered this with an iPlanet application server. I suppose variances
in container classloaders could pose an obstical for this approach, no?
I assume your old servlet code is still in CVS somewhere, eh? Are there
notes about this anywhere, bugzilla perhaps?
John-Mason
|
|
|
| Re: eclipse core in a web application context [message #29041 is a reply to message #29003] |
Tue, 15 July 2003 18:49 |
 Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
user@domain.invalid wrote:
> Dorian,
>
> I have found your post from the tools news group (10/28/2002):
>
> > The current infocenter (to be significantly modified this week) uses
> > the BootLoader mechanism to load eclipse inside a servlet and
> > communicate with it. There are some problems with this approach, in
> > particular the URL stream handlers, xml parsers, etc.
>
> > We are moving aways from embedding eclipse directly into a servlet,
> > and call it as an external process instead, using its own tomcat
> > server.
>
>> So, take a look at org.eclipse.core.boot.BootLoader and
>> org.eclipse.core.runtime.IPlatformRunnable if you still want to call
>
> > eclipse from your servlet.
>
> Were the problems you were having related to the container's class
> loader? I interpreted Mel Martinez's comments about the way a container
> protects itself with seperate class loaders for iteself & for the
> webapps it hosts as suggesting that the container's XML parser would not
> necessarily be inflicted upon the applications it hosts. On the other
> hand, I'd bet this varies from container to container. I believe I once
> encountered this with an iPlanet application server. I suppose variances
> in container classloaders could pose an obstical for this approach, no?
>
Certainly the exact behavior of servlet classloaders will vary from
application server to application server due to implementation
differences. However, to be compliant with the Java Servlet
Specification (the current spec is available at:
http://jcp.org/aboutJava/communityprocess/first/jsr154/index 3.html
) then there are certain behaviors that must be consistent. In
particular the current spec requires (sec SRV 9.5) that all classes
within /WEB-INF/classes/ and /WEB-INF/lib/*.jar "must be available to
the application classloader". That statement implies that
implementation must be such that the classloader looks first in these
areas for classes prior to defering to the parent - otherwise the
statement would not be true and the spec would be violated.
I'm not sure whether this helps or hurts you because I'm not entirely
clear on what it is you want to achieve.
You give the example of being able to add a tab to a web page by
dropping in a plugin using an <extension>. I'm not sure why this is
easier or more desireable than just using static (JSP) or dynamic (JSPs
& Servlets) includes with appropriate logic and conventions or taglibs.
Or use one of the many frameworks that build on these things such as
struts. At any rate, good luck.
Cheers,
Mel
|
|
|
| Re: eclipse core in a web application context [message #29069 is a reply to message #29003] |
Tue, 15 July 2003 19:19 |
| Eclipse User |
|
|
|
Originally posted by: birsan.nospam.ca.ibm.com
I am not sure if this forum is appropriate for this thread, but here are a
few more comments:
<user@domain.invalid> wrote in message
news:3F142C02.2040009@domain.invalid...
> Dorian,
>
> I have found your post from the tools news group (10/28/2002):
>
> > The current infocenter (to be significantly modified this week) uses
> > the BootLoader mechanism to load eclipse inside a servlet and
> > communicate with it. There are some problems with this approach, in
> > particular the URL stream handlers, xml parsers, etc.
>
> > We are moving aways from embedding eclipse directly into a servlet,
> > and call it as an external process instead, using its own tomcat
> > server.
>
> > So, take a look at org.eclipse.core.boot.BootLoader and
> > org.eclipse.core.runtime.IPlatformRunnable if you still want to call
> > eclipse from your servlet.
>
> Were the problems you were having related to the container's class
> loader? I interpreted Mel Martinez's comments about the way a container
> protects itself with seperate class loaders for iteself & for the
> webapps it hosts as suggesting that the container's XML parser would not
> necessarily be inflicted upon the applications it hosts. On the other
> hand, I'd bet this varies from container to container. I believe I once
> encountered this with an iPlanet application server. I suppose variances
> in container classloaders could pose an obstical for this approach, no?
>
I don't fully remember the exact details, but I recall that the xml parser
was picked up based on the class loader set in the current thread's context.
This class loader happend to be the one in the app server (tomcat), not the
one supplied by eclipse (I may be wrong here, but the problem was along
these lines).
Another issue was the fact that both Eclipse and the app server set their
own URLStreamHandlerFactory, and there is only one allowed in a JVM.
In general, as Mel pointed out, app servers should implement a certain class
loader behavior so things should work out in the end. I think app servers
have some proprietary class loading mechanism that you can configure.
> I assume your old servlet code is still in CVS somewhere, eh? Are there
> notes about this anywhere, bugzilla perhaps?
Check the CVS links from the help development pages and find the appropriate
instructions. You should also be able to dig out the old 2.0 docs.
Here is a starting point (look under the "Plugins" section):
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-help-home/dev.html
-Dorian
>
> John-Mason
>
|
|
|
| Re: eclipse core in a web application context [message #29107 is a reply to message #29069] |
Wed, 16 July 2003 00:56 |
| Eclipse User |
|
|
|
Originally posted by: john-mason.shackelford.org
Dorian,
Thanks for the info. Apologies to pursuing this thread in the equinox
news group. My hope was that, as equinox will be the new core,
developers here would be able to indicate (as you have) whether or not
I'd run into obstacles booting Eclipse core from within a web container
given the new architecture. Dynamic loading of plugins holds promise in
a web context as it could mean that individual site features could be
hot deployed/undeployed.
> I don't fully remember the exact details, but I recall that the xml parser
> was picked up based on the class loader set in the current thread's context.
> This class loader happend to be the one in the app server (tomcat), not the
> one supplied by eclipse (I may be wrong here, but the problem was along
> these lines).
I've heard about other issues related to Xerces & the context
classloader. I wonder if this will cease to be an issue when the XPP is
integrated into Eclipse...
> Another issue was the fact that both Eclipse and the app server set their
> own URLStreamHandlerFactory, and there is only one allowed in a JVM.
Thanks for the tip. I am going to read up on this. Do you remember if
this appeared to be an unresolvable issue or was your refactoring driven
primarily by other issues?
I did find the old servlet code in CVS tag v20020920, I think
org.eclipse.help.webapp/src/org.eclipse.help.servlet.Eclipse
and EclipseConnector are probably the key classes I need to review.
Thanks again for your time.
John-Mason
|
|
|
| Re: eclipse core in a web application context [message #29145 is a reply to message #29041] |
Wed, 16 July 2003 11:57 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Mel,
Thanks for the valuable info.
> You give the example of being able to add a tab to a web page by
> dropping in a plugin using an <extension>. I'm not sure why this is
> easier or more desireable than just using static (JSP) or dynamic JSPs
> & Servlets) includes with appropriate logic and conventions or
> taglibs. Or use one of the many frameworks that build on these things
> such as struts. At any rate, good luck.
Broad frameworks like Struts, while providing a helpful framework for
developing web applications and a common language among developers, do
not foster the sort of sharing of building blocks among diverse teams
and projects that has made Eclipse such a phenomenal success. I believe
that bringing Eclipse's standard interface for extension-point/extension
to web applications could change the whole economy of web application
development.
I will relocate an additional blather on this topic in a more
appropriate forum :). Thanks for your help!
John-Mason
|
|
|
| Re: eclipse core in a web application context [message #29182 is a reply to message #29107] |
Wed, 16 July 2003 14:40 |
| Eclipse User |
|
|
|
Originally posted by: birsan.nospam.ca.ibm.com
"John-Mason P. Shackelford" <john-mason@shackelford.org> wrote in message
news:3F14A2BB.3070504@shackelford.org...
> Dorian,
>
> Thanks for the info. Apologies to pursuing this thread in the equinox
> news group. My hope was that, as equinox will be the new core,
> developers here would be able to indicate (as you have) whether or not
> I'd run into obstacles booting Eclipse core from within a web container
> given the new architecture. Dynamic loading of plugins holds promise in
> a web context as it could mean that individual site features could be
> hot deployed/undeployed.
>
> > I don't fully remember the exact details, but I recall that the xml
parser
> > was picked up based on the class loader set in the current thread's
context.
> > This class loader happend to be the one in the app server (tomcat), not
the
> > one supplied by eclipse (I may be wrong here, but the problem was along
> > these lines).
>
> I've heard about other issues related to Xerces & the context
> classloader. I wonder if this will cease to be an issue when the XPP is
> integrated into Eclipse...
>
> > Another issue was the fact that both Eclipse and the app server set
their
> > own URLStreamHandlerFactory, and there is only one allowed in a JVM.
>
> Thanks for the tip. I am going to read up on this. Do you remember if
> this appeared to be an unresolvable issue or was your refactoring driven
> primarily by other issues?
We fixed the problem on two app server, WebSphere AppServer and Tomcat. If
you check the 2.0 infocenter installation instructions you'll see the
workarounds. One of the limitations was that you could only have one eclipse
based webapp running in one particular server, and there were many other
reasons, documented somewhere in the platform-help-dev mailing list.
>
> I did find the old servlet code in CVS tag v20020920, I think
> org.eclipse.help.webapp/src/org.eclipse.help.servlet.Eclipse
> and EclipseConnector are probably the key classes I need to review.
For the url stream handler workaround take a look at the *proxy* packages as
well.
>
> Thanks again for your time.
>
> John-Mason
>
-Dorian
|
|
|
| Re: eclipse core in a web application context [message #29218 is a reply to message #29182] |
Wed, 16 July 2003 21:59 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Oddly enough, I have considered the same sort of issue with my own plugin
engine. My engine, as I have posted before, is based on (and is a work in
progress still, so not yet complete) the extension/extension point
mechanism, the service model, and so forth. While my engine is puny compared
to what Eclipse offers, it works in a similar fashion. We are just recently
adding an embeded jar classloader so that a plugin can be self contained
into a single .jar (.par we call it for plugin archive), and embed libraries
and so forth without requiring the plugin to be unarchived to disk in an
expanded directory format.
However, along the lines of Mel and others, I too have thought about the
classloader issue. It does pose some problems given that a container may use
a hierarchy of classloaders for hot-deploy, individual WAR/EAR deployments,
and also allow configurable loader hierarchies depending on needs, such as a
single classloader for EJB's so they can all be shared, or the unified
approach JBoss takes.
Quite honestly, I see no reason why the engine would be more beneficial than
perhaps working towards a slightly more dynamic WAR/EAR deployment strategy
as part of a future version of the J2EE spec. Even so, today most containers
support hot deployment, so its easy enough to build an app into its own war
file and drop it in, or remove it to hot deploy/undeploy portions of a site.
In regards to dropping in a plugin or removing one, how is that any
differnet than using WAR/EAR with container hot deploy/undeploy/redeploy? I
am not sure I see how using the equinox engine will make that better?
Now, that is not to say a server application that one writes couldn't
benefit from using this core. On the contrary, I think having a core like
equinox should be used in user written servers, so that they can indeed
support dynamic additions, reloading, etc. I was using part of my engine to
add this very thing to a small "service" we were deploying to auto-update
the entire service application. We weren't able to use JBoss in deployment,
so we wrote our own simple service, and we needed a way to update it at
will. Sadly, due to some of the issues with EJB, reflection and a higher
classloader trying to create dynamic classes in a lower classloader, we ran
into problems that we may be able to resolve using the
Thread.currentThread().setcontextLoader() stuff, which we were not doing.
Anyway, while I do agree a pluggable server is the way to go, I don't see
how it will benefit current J2EE containers, and more so I believe trying to
move the spec forward a bit by introducing some of the concepts Eclipse,
OSGi and other pluggable engines introduce is a better approach.
"dorian birsan" <birsan@nospam.ca.ibm.com> wrote in message
news:bf3o4r$cc7$1@eclipse.org...
>
> "John-Mason P. Shackelford" <john-mason@shackelford.org> wrote in message
> news:3F14A2BB.3070504@shackelford.org...
> > Dorian,
> >
> > Thanks for the info. Apologies to pursuing this thread in the equinox
> > news group. My hope was that, as equinox will be the new core,
> > developers here would be able to indicate (as you have) whether or not
> > I'd run into obstacles booting Eclipse core from within a web container
> > given the new architecture. Dynamic loading of plugins holds promise in
> > a web context as it could mean that individual site features could be
> > hot deployed/undeployed.
> >
> > > I don't fully remember the exact details, but I recall that the xml
> parser
> > > was picked up based on the class loader set in the current thread's
> context.
> > > This class loader happend to be the one in the app server (tomcat),
not
> the
> > > one supplied by eclipse (I may be wrong here, but the problem was
along
> > > these lines).
> >
> > I've heard about other issues related to Xerces & the context
> > classloader. I wonder if this will cease to be an issue when the XPP is
> > integrated into Eclipse...
> >
> > > Another issue was the fact that both Eclipse and the app server set
> their
> > > own URLStreamHandlerFactory, and there is only one allowed in a JVM.
> >
> > Thanks for the tip. I am going to read up on this. Do you remember if
> > this appeared to be an unresolvable issue or was your refactoring driven
> > primarily by other issues?
>
> We fixed the problem on two app server, WebSphere AppServer and Tomcat. If
> you check the 2.0 infocenter installation instructions you'll see the
> workarounds. One of the limitations was that you could only have one
eclipse
> based webapp running in one particular server, and there were many other
> reasons, documented somewhere in the platform-help-dev mailing list.
>
> >
> > I did find the old servlet code in CVS tag v20020920, I think
> > org.eclipse.help.webapp/src/org.eclipse.help.servlet.Eclipse
> > and EclipseConnector are probably the key classes I need to review.
>
> For the url stream handler workaround take a look at the *proxy* packages
as
> well.
>
> >
> > Thanks again for your time.
> >
> > John-Mason
> >
>
> -Dorian
>
>
|
|
|
| Re: eclipse core in a web application context [message #29256 is a reply to message #29218] |
Thu, 17 July 2003 15:51 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Kevin,
Thanks for your observations. I have been banging my head against the
wall on this one. (BTW Dorian, I found the posts in the
platform-help-dev mailing lists very helpful.) Every way I turn this
problem I seem to run into a brick wall. Perhaps you can help me see the
issues more clearly.
> Even so, today most containers support hot deployment, so its easy
> enough to build an app into its own war file and drop it in, or remove
> it to hot deploy/undeploy portions of a site. In regards to dropping
> in a plugin or removing one, how is that any differnet than using
> WAR/EAR with container hot deploy/undeploy/redeploy? I am not sure I
> see how using the equinox engine will make that better?
My complaint is not that I find the existing WAR/EAR hot deployment
mechanisms lacking--it is that web applications, as they are built
today, do not have a standard interface for the
extension-point/extension idea. It seems like every web application out
there winds up solving the same problems over and over again. In the
last four or five years the industry has tried to address this problem
by creating large frameworks that handle many commonly required
services, but these monolithic frameworks become a world of their own
and do not offer a good platform "best of breed" integration (cf. ACSJ).
Alternatively, we've shared only very basic tools, and structural
elements (cf. Struts). A plugin approach would provide a standard
interface for integrating working web application components.
The beauty of the Eclipse core is that the general extension mechanism
is very simple and broad, yet as each plugin defines its own interface
for extension, it may be as granular or course as is appropriate for the
services it offers (unlike a WAR which is always JSP, servlets, and
supporting code). Just as the standard plugin interface for Eclipse has
created a market for plugins--hundreds of contributions I can integrate
in my own IDE--a web application substrate with plugin kernel would
allow the community to develop and share components and could
significantly increase our productivity as web developers. Components
could be anything: a page layout, a user registration service, standard
interfaces for security to which specific implementations could be
plugged in, threaded discussion support, site administration and
configuration services, etc. These features could be comprised of
headless and ui plugins so that sites could implement their own ui for
the underlying functionality. Once a "platform" of basic services is
created, all sorts of plugins will begin poping up.
The benefit of using Equinox as the plugin engine is that it opens the
possibility for plugins to deployed in either a web application context,
or a desktop application context.
Though this appears to me to be a promising idea, I am currently at a
loss as to how to make it work:
1. Launching Eclipse core from a servlet is looking like a dead end
given the one app per server limitation noted in Dorian's last post.
2. Using the Eclipse as an external service (the current platform help
implementation) forces the developer to use a container provided by Eclipse.
3. Writing a light-weight version of Eclipse core that could run inside
a container would probably fail since the functionality that causes us
trouble inside a web container is probably not optional and would likely
jeopardize our being able to deploy a plugin in both web & desktop contexts.
Any ideas?
John-Mason
|
|
|
| Re: eclipse core in a web application context [message #29445 is a reply to message #29256] |
Wed, 23 July 2003 22:59 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Honestly, I don't see a solution to this without getting the J2EE spec
changed to accomodate the extension mechanism. Isn't that what JMX is
basically though? An extension mechansim? I haven't much looked at JMX, but
JBoss uses it exclusively, as does Primati, JRun and others. I would think
that if we could modify the JMX extension spec to include
extension/extension points, it might provide what we are looking for. But
then every app server vendor would have to build their implementation around
JMX, which I don't think is a requirement, is it?
What if we got the Equinox engine into our own implementation of a J2EE
container, perhaps web only initially? Take the source of Tomcat or Jetty,
wrap it around the engine, adhere to the spec and ultimately allow a
pluggable web container? The problem is standards. Without it being
standard, someone using it is stuck on our implementation. What to do?
<user@domain.invalid> wrote in message
news:3F16C5FB.5040302@domain.invalid...
> Kevin,
>
> Thanks for your observations. I have been banging my head against the
> wall on this one. (BTW Dorian, I found the posts in the
> platform-help-dev mailing lists very helpful.) Every way I turn this
> problem I seem to run into a brick wall. Perhaps you can help me see the
> issues more clearly.
>
> > Even so, today most containers support hot deployment, so its easy
> > enough to build an app into its own war file and drop it in, or remove
> > it to hot deploy/undeploy portions of a site. In regards to dropping
> > in a plugin or removing one, how is that any differnet than using
> > WAR/EAR with container hot deploy/undeploy/redeploy? I am not sure I
> > see how using the equinox engine will make that better?
>
> My complaint is not that I find the existing WAR/EAR hot deployment
> mechanisms lacking--it is that web applications, as they are built
> today, do not have a standard interface for the
> extension-point/extension idea. It seems like every web application out
> there winds up solving the same problems over and over again. In the
> last four or five years the industry has tried to address this problem
> by creating large frameworks that handle many commonly required
> services, but these monolithic frameworks become a world of their own
> and do not offer a good platform "best of breed" integration (cf. ACSJ).
> Alternatively, we've shared only very basic tools, and structural
> elements (cf. Struts). A plugin approach would provide a standard
> interface for integrating working web application components.
>
> The beauty of the Eclipse core is that the general extension mechanism
> is very simple and broad, yet as each plugin defines its own interface
> for extension, it may be as granular or course as is appropriate for the
> services it offers (unlike a WAR which is always JSP, servlets, and
> supporting code). Just as the standard plugin interface for Eclipse has
> created a market for plugins--hundreds of contributions I can integrate
> in my own IDE--a web application substrate with plugin kernel would
> allow the community to develop and share components and could
> significantly increase our productivity as web developers. Components
> could be anything: a page layout, a user registration service, standard
> interfaces for security to which specific implementations could be
> plugged in, threaded discussion support, site administration and
> configuration services, etc. These features could be comprised of
> headless and ui plugins so that sites could implement their own ui for
> the underlying functionality. Once a "platform" of basic services is
> created, all sorts of plugins will begin poping up.
>
> The benefit of using Equinox as the plugin engine is that it opens the
> possibility for plugins to deployed in either a web application context,
> or a desktop application context.
>
> Though this appears to me to be a promising idea, I am currently at a
> loss as to how to make it work:
>
> 1. Launching Eclipse core from a servlet is looking like a dead end
> given the one app per server limitation noted in Dorian's last post.
>
> 2. Using the Eclipse as an external service (the current platform help
> implementation) forces the developer to use a container provided by
Eclipse.
>
> 3. Writing a light-weight version of Eclipse core that could run inside
> a container would probably fail since the functionality that causes us
> trouble inside a web container is probably not optional and would likely
> jeopardize our being able to deploy a plugin in both web & desktop
contexts.
>
> Any ideas?
>
> John-Mason
>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 09:59:44 GMT 2024
Powered by FUDForum. Page generated in 0.04422 seconds |
] 
Search
Help
Register
Login
Home
