Home » Eclipse Projects » Equinox » eclipse based struts applications.
| eclipse based struts applications. [message #1599] |
Mon, 24 February 2003 17:59  |
Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
Hi.
We are in the process of developing struts based applivcations that we need
to deploy ultimately. One thing we could do with eclipe is provide the
framework for installing/removing/starting/stoping etc the webapps. So when
eclipse starts up it finds plugins relating to the installed web apps. Do
you see a pattern here where one of this project deliverables being a
platform for that ?
|
|
|
| Re: eclipse based struts applications. [message #1622 is a reply to message #1599] |
Mon, 24 February 2003 18:27  |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Dominic,
Sounds cool, where would those strut applications run ?
Do they expect entire Tomcat or just a servlet engine?
As I pointed out in one of my previous posting, Eclipse embeds a web
application
server. Futhermore, I was pushing for a Java foundation layer for
network-deployed
Java components, which would be specialized as either plug-ins or web
applications.
Indeed, both plug-ins and web applications are a set of Java packages and
resources
at the core. They are both loaded in their own class loader. They differ in
that
one expects a servlet engine environment where the other expects a plug-in
registry.
I would like to see a design and an architecture where the foundation
supports
two containers, one for plug-ins and one for web applications. The core
deployment
of the jar files would be done by the foundation, so would be the class
loading.
The plug-in and servlet engine would be two containers deployed above the
foundation.
I do realize that requires to modify Tomcat, but it is not clear how much.
The resulting architecture would be very interesting, bringing Java plug-in
programming and web programming together.
Best regards,
Olivier.
"dominic" <dominic@nospam.com> wrote in message
news:b3dkro$um2$1@rogue.oti.com...
> Hi.
>
> We are in the process of developing struts based applivcations that we
need
> to deploy ultimately. One thing we could do with eclipe is provide the
> framework for installing/removing/starting/stoping etc the webapps. So
when
> eclipse starts up it finds plugins relating to the installed web apps. Do
> you see a pattern here where one of this project deliverables being a
> platform for that ?
>
>
|
|
|
| Re: eclipse based struts applications. [message #3056 is a reply to message #1622] |
Tue, 25 February 2003 16:41 |
| Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3dmcb$cf$1@rogue.oti.com...
> Hi Dominic,
>
> Sounds cool, where would those strut applications run ?
> Do they expect entire Tomcat or just a servlet engine?
Inside tomcat.To avoid changing tomcat they are located under its webapps
directory.
>
> As I pointed out in one of my previous posting, Eclipse embeds a web
> application
> server. Futhermore, I was pushing for a Java foundation layer for
> network-deployed
> Java components, which would be specialized as either plug-ins or web
> applications.
> Indeed, both plug-ins and web applications are a set of Java packages and
> resources
> at the core. They are both loaded in their own class loader. They differ
in
> that
> one expects a servlet engine environment where the other expects a plug-in
> registry.
> I would like to see a design and an architecture where the foundation
> supports
> two containers, one for plug-ins and one for web applications. The core
> deployment
> of the jar files would be done by the foundation, so would be the class
> loading.
> The plug-in and servlet engine would be two containers deployed above the
> foundation.
I do not see why you make that difference. From plugin point of view they
should not be different. All the platform should see is that one plugin
depends on the container plugin (tomcat) while the others do not. In the
short time i can live with fragmenting the web based plugins so that the
real jar reside under the web apps directory. I am not sure if tomcat can be
told to host a web app located elsewhere. But thqat could cahnge in the
future.
>
> I do realize that requires to modify Tomcat, but it is not clear how much.
> The resulting architecture would be very interesting, bringing Java
plug-in
> programming and web programming together.
>
> Best regards,
> Olivier.
>
> "dominic" <dominic@nospam.com> wrote in message
> news:b3dkro$um2$1@rogue.oti.com...
> > Hi.
> >
> > We are in the process of developing struts based applivcations that we
> need
> > to deploy ultimately. One thing we could do with eclipe is provide the
> > framework for installing/removing/starting/stoping etc the webapps. So
> when
> > eclipse starts up it finds plugins relating to the installed web apps.
Do
> > you see a pattern here where one of this project deliverables being a
> > platform for that ?
> >
> >
>
>
|
|
|
| Re: eclipse based struts applications. [message #12174 is a reply to message #3056] |
Tue, 11 March 2003 23:21 |
 Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
dominic wrote:
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3dmcb$cf$1@rogue.oti.com...
>
>>Hi Dominic,
>>
>>Sounds cool, where would those strut applications run ?
>>Do they expect entire Tomcat or just a servlet engine?
>
>
> Inside tomcat.To avoid changing tomcat they are located under its webapps
> directory.
>
More specifically, strut applications are web applications (i.e.
servlets) that run within a <context>. Webapps that conform to the WAR
layout (as either jars or directory trees) that are placed in the
webapps directory are automatically given a <context>. However, you can
also configure a <context> in the server.xml that points to an
alternative directory (using the 'docbase' attribute).
>
>>As I pointed out in one of my previous posting, Eclipse embeds a web
>>application
>>server. Futhermore, I was pushing for a Java foundation layer for
>>network-deployed
>>Java components, which would be specialized as either plug-ins or web
>>applications.
>>Indeed, both plug-ins and web applications are a set of Java packages and
>>resources
>>at the core. They are both loaded in their own class loader. They differ
>
> in
>
>>that
>>one expects a servlet engine environment where the other expects a plug-in
>>registry.
There are a some interesting parallels and differences. WebApps are
loaded by their own classloader. Tomcat provides additional
classloaders that specifically load classes for use exclusively by the
container (i.e. tomcat itself), to be common to the container AND
webapps and finally for sharing just across webapps. From the 4.1 docs:
Bootstrap
|
System
|
Common
/ \
Catalina Shared
/ \
Webapp1 Webapp2 ...
This illustrates the classloader hierarchy. One key difference with a
plugin model is that webapps do not themselves get to decide what they
will share with other webapps. A webapp's deployment descripter does
not have an '<exports>' or <publish> element. For a class to be shared
it must be loaded by the Common or Shared classloaders which normally
simply pickup whatever classes are dropped into the $CATALINA/common or
$CATALINA/shared directories. Unlike the normal Java classloader
semantics, the individual webapp classloaders do not have to defer to
versions of classes loaded by the parent class loaders. This allows a
webapp to load it's own XML DOM implementation, for example. Catalina
is protected by being down it's own branch. This is all documented well at:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader -howto.html
Tomcat sandboxes web applications with the standard Java Security
Manager API to control what they can do. By default, webapps can read
(but not write) only within their context docbase. They also by default
cannot open connections and are limited in what system properties they
can read. Permissions are granted in the catalina.policy file.
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/security-man ager-howto.html
>>I would like to see a design and an architecture where the foundation
>>supports
>>two containers, one for plug-ins and one for web applications. The core
>>deployment
>>of the jar files would be done by the foundation, so would be the class
>>loading.
>>The plug-in and servlet engine would be two containers deployed above the
>>foundation.
>
>
> I do not see why you make that difference. From plugin point of view they
> should not be different. All the platform should see is that one plugin
> depends on the container plugin (tomcat) while the others do not. In the
> short time i can live with fragmenting the web based plugins so that the
> real jar reside under the web apps directory. I am not sure if tomcat can be
> told to host a web app located elsewhere. But thqat could cahnge in the
> future.
>
As I indicate above, tomcat can deploy a web app located elsewhere from
it's webapps directory. Note - my comments refer to the full tomcat 4.1
- I'm not sure what has been trimmed in the version of tomcat that is
embedded as a plugin in eclipse.
I agree that, for the simple purpose of having eclipse host webapps
deployed as 'plugins', this can be done simply indicating that a
webapp-plugin is an 'extension' to the tomcatplugin and modifying the
tomcat plugin to pick that up and deploy it as a webapp by dynamically
creating a context for it. This doesn't sound very difficult to do and
should not have any impact on the rest of eclipse.
The question is: is this what we want to do to accomplish our goals?
Mel
|
|
|
| Re: eclipse based struts applications. [message #12926 is a reply to message #3056] |
Tue, 11 March 2003 23:27 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
dominic wrote:
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3dmcb$cf$1@rogue.oti.com...
>
>>Hi Dominic,
>>
>>Sounds cool, where would those strut applications run ?
>>Do they expect entire Tomcat or just a servlet engine?
>
>
> Inside tomcat.To avoid changing tomcat they are located under its webapps
> directory.
>
More specifically, strut applications are web applications (i.e.
servlets) that run within a <context>. Webapps that conform to the WAR
layout (as either jars or directory trees) that are placed in the
webapps directory are automatically given a <context>. However, you can
also configure a <context> in the server.xml that points to an
alternative directory (using the 'docbase' attribute).
>
>>As I pointed out in one of my previous posting, Eclipse embeds a web
>>application
>>server. Futhermore, I was pushing for a Java foundation layer for
>>network-deployed
>>Java components, which would be specialized as either plug-ins or web
>>applications.
>>Indeed, both plug-ins and web applications are a set of Java packages and
>>resources
>>at the core. They are both loaded in their own class loader. They differ
>
> in
>
>>that
>>one expects a servlet engine environment where the other expects a
plug-in
>>registry.
There are a some interesting parallels and differences. WebApps are
loaded by their own classloader. Tomcat provides additional
classloaders that specifically load classes for use exclusively by the
container (i.e. tomcat itself), to be common to the container AND
webapps and finally for sharing just across webapps. From the 4.1 docs:
Bootstrap
|
System
|
Common
/ \
Catalina Shared
/ \
Webapp1 Webapp2 ...
This illustrates the classloader hierarchy. One key difference with a
plugin model is that webapps do not themselves get to decide what they
will share with other webapps. A webapp's deployment descripter does
not have an '<exports>' or <publish> element. For a class to be shared
it must be loaded by the Common or Shared classloaders which normally
simply pickup whatever classes are dropped into the $CATALINA/common or
$CATALINA/shared directories. Unlike the normal Java classloader
semantics, the individual webapp classloaders do not have to defer to
versions of classes loaded by the parent class loaders. This allows a
webapp to load it's own XML DOM implementation, for example. Catalina
is protected by being down it's own branch. This is all documented well at:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader -howto.html
Tomcat sandboxes web applications with the standard Java Security
Manager API to control what they can do. By default, webapps can read
(but not write) only within their context docbase. They also by default
cannot open connections and are limited in what system properties they
can read. Permissions are granted in the catalina.policy file.
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/security-man ager-howto.html
>>I would like to see a design and an architecture where the foundation
>>supports
>>two containers, one for plug-ins and one for web applications. The core
>>deployment
>>of the jar files would be done by the foundation, so would be the class
>>loading.
>>The plug-in and servlet engine would be two containers deployed above the
>>foundation.
>
>
> I do not see why you make that difference. From plugin point of view they
> should not be different. All the platform should see is that one plugin
> depends on the container plugin (tomcat) while the others do not. In the
> short time i can live with fragmenting the web based plugins so that the
> real jar reside under the web apps directory. I am not sure if tomcat
can be
> told to host a web app located elsewhere. But thqat could cahnge in the
> future.
>
As I indicate above, tomcat can deploy a web app located elsewhere from
it's webapps directory. Note - my comments refer to the full tomcat 4.1
- I'm not sure what has been trimmed in the version of tomcat that is
embedded as a plugin in eclipse.
I agree that, for the simple purpose of having eclipse host webapps
deployed as 'plugins', this can be done simply indicating that a
webapp-plugin is an 'extension' to the tomcatplugin and modifying the
tomcat plugin to pick that up and deploy it as a webapp by dynamically
creating a context for it. This doesn't sound very difficult to do and
should not have any impact on the rest of eclipse.
The question is: is this what we want to do to accomplish our goals?
Mel
|
|
| |
| Re: eclipse based struts applications. [message #14290 is a reply to message #1599] |
Thu, 20 March 2003 02:31 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"dominic" <dominic@nospam.com> wrote in message
news:b3dkro$um2$1@rogue.oti.com...
> Hi.
>
> We are in the process of developing struts based applivcations that we
need
> to deploy ultimately. One thing we could do with eclipe is provide the
> framework for installing/removing/starting/stoping etc the webapps. So
when
> eclipse starts up it finds plugins relating to the installed web apps. Do
> you see a pattern here where one of this project deliverables being a
> platform for that ?
>
>
I have developed plugins that wrap Tomcat and that provide the ability for a
plugin to deploy a .war file.
I am planning on having an official release of these plugins within a few
weeks but I will create an earlier release if anyone is interested.
These plugins are 'normal' Eclipse plugins and I expect them to only be
enhanced by the Equinox framework.
Here are the details...
A couple of months ago I decided that my project, JLense, would shift its
focus to providing a framework for developing web services and web service
front-ends. My first such release will port the current JLedger
application from an EJB-based implementation to a web service
implementation. JLedger is a very simple business accounting application
that includes a back-end general ledger and a front-end Swing-based GUI.
I decided that I would implement the JLedger web service as an EJB session
bean and that I would built a web service facade using Apache Axis and
Tomcat. I also determined that, in order to provide web service support in
Eclipse, that I would create Eclipse plugins that wrapped JBoss, Tomcat, and
Apache Axis.
To be able to wrap JBoss and Tomcat as Eclipse plugins I decided to first
create an Eclipse plugin that would provided basic JMX functionality to
Eclipse and that would enable Eclipse plugins to export MBeans. I
accomplished this by creating an Eclipse plugin that wraps the JBoss MBean
server. This plugin creates the MBean server so that only plugin
classloaders are used to load MBeans and associated classes.
JBoss and Tomcat are both implemented as sets of JMX MBeans that are hosted
by a core JMX MBean server. Therefore, after I had JMX support in Eclipse,
I was able to create plugins that embedded JBoss and Tomcat by creating
plugins that wrap the core JBoss and Tomcat MBeans. One of the core JBoss
MBeans is the 'MainDeployer' MBean. The MainDeployer MBean provides an
extendable framework for deploying various kinds of application files: EJB
beans in .jar files, web applications in .war files; JMX MBeans in .sar
files, etc. I have some simple extension points for starting and stopping
any of these component types using the JBoss MainDeployer.
I decided early on that I would not try to support any hot-deploy feature of
JBoss or Tomcat. However, I think that hot deploy probably still works but
I don't intend to use it or test it .
I currently have JBoss and Tomcat working OK. I have sucessfully deployed
both my web service and the EJB session bean. However, I still have lots of
problems in my client code and none of my JUnit tests work yet :-( so
things are still pretty raw.
ted stockwell
jlense.sf.net
|
|
|
| Re: eclipse based struts applications. [message #15685 is a reply to message #14290] |
Thu, 27 March 2003 17:47 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
This looks interesting; I'll be looking forward to seeing it.
Best,
Dave Orme
ted stockwell wrote:
> "dominic" <dominic@nospam.com> wrote in message
> news:b3dkro$um2$1@rogue.oti.com...
>
>>Hi.
>>
>>We are in the process of developing struts based applivcations that we
>
> need
>
>>to deploy ultimately. One thing we could do with eclipe is provide the
>>framework for installing/removing/starting/stoping etc the webapps. So
>
> when
>
>>eclipse starts up it finds plugins relating to the installed web apps. Do
>>you see a pattern here where one of this project deliverables being a
>>platform for that ?
>>
>>
>
>
> I have developed plugins that wrap Tomcat and that provide the ability for a
> plugin to deploy a .war file.
> I am planning on having an official release of these plugins within a few
> weeks but I will create an earlier release if anyone is interested.
> These plugins are 'normal' Eclipse plugins and I expect them to only be
> enhanced by the Equinox framework.
>
> Here are the details...
>
> A couple of months ago I decided that my project, JLense, would shift its
> focus to providing a framework for developing web services and web service
> front-ends. My first such release will port the current JLedger
> application from an EJB-based implementation to a web service
> implementation. JLedger is a very simple business accounting application
> that includes a back-end general ledger and a front-end Swing-based GUI.
>
> I decided that I would implement the JLedger web service as an EJB session
> bean and that I would built a web service facade using Apache Axis and
> Tomcat. I also determined that, in order to provide web service support in
> Eclipse, that I would create Eclipse plugins that wrapped JBoss, Tomcat, and
> Apache Axis.
>
> To be able to wrap JBoss and Tomcat as Eclipse plugins I decided to first
> create an Eclipse plugin that would provided basic JMX functionality to
> Eclipse and that would enable Eclipse plugins to export MBeans. I
> accomplished this by creating an Eclipse plugin that wraps the JBoss MBean
> server. This plugin creates the MBean server so that only plugin
> classloaders are used to load MBeans and associated classes.
>
> JBoss and Tomcat are both implemented as sets of JMX MBeans that are hosted
> by a core JMX MBean server. Therefore, after I had JMX support in Eclipse,
> I was able to create plugins that embedded JBoss and Tomcat by creating
> plugins that wrap the core JBoss and Tomcat MBeans. One of the core JBoss
> MBeans is the 'MainDeployer' MBean. The MainDeployer MBean provides an
> extendable framework for deploying various kinds of application files: EJB
> beans in .jar files, web applications in .war files; JMX MBeans in .sar
> files, etc. I have some simple extension points for starting and stopping
> any of these component types using the JBoss MainDeployer.
>
> I decided early on that I would not try to support any hot-deploy feature of
> JBoss or Tomcat. However, I think that hot deploy probably still works but
> I don't intend to use it or test it .
>
> I currently have JBoss and Tomcat working OK. I have sucessfully deployed
> both my web service and the EJB session bean. However, I still have lots of
> problems in my client code and none of my JUnit tests work yet :-( so
> things are still pretty raw.
>
> ted stockwell
> jlense.sf.net
>
>
>
--
Dave Orme
Advanced Systems Concepts
http://www.swtworkbench.com
|
|
|
| Re: eclipse based struts applications. [message #22556 is a reply to message #12174] |
Fri, 11 April 2003 05:14 |
| Eclipse User |
|
|
|
Originally posted by: dorian.birsan.net
Hi Mel,
I've added a couple of comments regarding the current org.eclipse.tomcat
plugin.
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:3E6E6F6B.1070609@us.ibm.com...
> dominic wrote:
> > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > news:b3dmcb$cf$1@rogue.oti.com...
> >
> >>Hi Dominic,
> >>
> >>Sounds cool, where would those strut applications run ?
> >>Do they expect entire Tomcat or just a servlet engine?
> >
> >
> > Inside tomcat.To avoid changing tomcat they are located under its
webapps
> > directory.
> >
>
> More specifically, strut applications are web applications (i.e.
> servlets) that run within a <context>. Webapps that conform to the WAR
> layout (as either jars or directory trees) that are placed in the
> webapps directory are automatically given a <context>. However, you can
> also configure a <context> in the server.xml that points to an
> alternative directory (using the 'docbase' attribute).
>
> >
> >>As I pointed out in one of my previous posting, Eclipse embeds a web
> >>application
> >>server. Futhermore, I was pushing for a Java foundation layer for
> >>network-deployed
> >>Java components, which would be specialized as either plug-ins or web
> >>applications.
> >>Indeed, both plug-ins and web applications are a set of Java packages
and
> >>resources
> >>at the core. They are both loaded in their own class loader. They differ
> >
> > in
> >
> >>that
> >>one expects a servlet engine environment where the other expects a
plug-in
> >>registry.
>
> There are a some interesting parallels and differences. WebApps are
> loaded by their own classloader. Tomcat provides additional
> classloaders that specifically load classes for use exclusively by the
> container (i.e. tomcat itself), to be common to the container AND
> webapps and finally for sharing just across webapps. From the 4.1 docs:
>
> Bootstrap
> |
> System
> |
> Common
> / \
> Catalina Shared
> / \
> Webapp1 Webapp2 ...
>
> This illustrates the classloader hierarchy. One key difference with a
> plugin model is that webapps do not themselves get to decide what they
> will share with other webapps. A webapp's deployment descripter does
> not have an '<exports>' or <publish> element. For a class to be shared
> it must be loaded by the Common or Shared classloaders which normally
> simply pickup whatever classes are dropped into the $CATALINA/common or
> $CATALINA/shared directories. Unlike the normal Java classloader
> semantics, the individual webapp classloaders do not have to defer to
> versions of classes loaded by the parent class loaders. This allows a
> webapp to load it's own XML DOM implementation, for example. Catalina
> is protected by being down it's own branch. This is all documented well
at:
>
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader -howto.html
>
> Tomcat sandboxes web applications with the standard Java Security
> Manager API to control what they can do. By default, webapps can read
> (but not write) only within their context docbase. They also by default
> cannot open connections and are limited in what system properties they
> can read. Permissions are granted in the catalina.policy file.
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/security-man ager-howto.html
>
>
>
> >>I would like to see a design and an architecture where the foundation
> >>supports
> >>two containers, one for plug-ins and one for web applications. The core
> >>deployment
> >>of the jar files would be done by the foundation, so would be the class
> >>loading.
> >>The plug-in and servlet engine would be two containers deployed above
the
> >>foundation.
> >
> >
> > I do not see why you make that difference. From plugin point of view
they
> > should not be different. All the platform should see is that one plugin
> > depends on the container plugin (tomcat) while the others do not. In the
> > short time i can live with fragmenting the web based plugins so that the
> > real jar reside under the web apps directory. I am not sure if tomcat
can be
> > told to host a web app located elsewhere. But thqat could cahnge in the
> > future.
> >
>
> As I indicate above, tomcat can deploy a web app located elsewhere from
> it's webapps directory. Note - my comments refer to the full tomcat 4.1
> - I'm not sure what has been trimmed in the version of tomcat that is
> embedded as a plugin in eclipse.
If I remember correctly, the embedded Tomcat contains all the jars with
org.apache.* packages, as well as servlet.jar (javax.servlet.* packages).
>
> I agree that, for the simple purpose of having eclipse host webapps
> deployed as 'plugins', this can be done simply indicating that a
> webapp-plugin is an 'extension' to the tomcatplugin and modifying the
> tomcat plugin to pick that up and deploy it as a webapp by dynamically
> creating a context for it. This doesn't sound very difficult to do and
> should not have any impact on the rest of eclipse.
>
The embedded Tomcat plugin is pluggable, see the
org.eclipse.help.appserver.server extension points.
One can define a standard webapp inside a plugin and start it using
org.eclipse.help.internal.appserver.WebappManager.start(...) call.
Classes in the webapp will have access to both their regular webapp
classloader as well as their plugin classloader.
> The question is: is this what we want to do to accomplish our goals?
>
> Mel
>
-Dorian
|
|
|
Goto Forum:
Current Time: Mon Aug 19 02:10:19 GMT 2024
Powered by FUDForum. Page generated in 0.04493 seconds |
] 
Search
Help
Register
Login
Home
