You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glen Marchesani <gd...@gmail.com> on 2006/06/13 00:55:14 UTC
WebappLoader RFC
Hi All,
I have created a custom WebappLoader that allows additional classpath
settings. It's use is as follows..
<Context
docBase="C:/mycode/myproject/WebRoot/"
distributable="false"
>
<Loader
className="org.apache.catalina.loader.MyWebappLoader"
extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/"
/>
</Context>
The reason for doing this is when developping a webapp that consists of
several smaller projects I wanted to be able to from within the ide
edit-compile-run skipping the deploy step. Skipping the deploy step saves a
fair bit of tediousness.
My thiking is that this would be useful to others and hence this post. Is
there interest in this being an included feature on the default
WebappLoader? Or as an add on WebappLoader? The number of lines/complexity
of code
this adds is minimal a gettter/setter for extendedClasspath and a loop at
the bottom of the setRepositories() method to add the entries in the
extendedClasspath to the proper places..
Also I am willing to clean up/refactoring the WebappLoader code if someone
is willing to be the committer and let me know what I need to provide.. I
am well versed in Classloader intracacies ;-)
As for cleanup there is code like this throughout WebappLoader and
WebappClassloader
String results[] = new String[repositories.length + 1];
for (int i = 0; i < repositories.length; i++)
results[i] = repositories[i];
results[repositories.length] = repository;
repositories = results;
thanks,
Glen
Re: WebappLoader RFC
Posted by Darryl Miles <da...@netbauds.net>.
Its unclear now what you are trying to fix. Your first post stated you
wanted to cut down on the "deploy" part (I pointed out the features we
currently get that we'd loose with your approach; also that deploy is
necessary to flush out the old version of the code in the JVM) and this
last post I get the impression you want to cut down on the "build and
copy JAR to WEB-INF/lib" step.
I think I understand your situation as I have been there too but lets
work through your points.
Glen Marchesani wrote:
> The IDE features you mention sound cool which one is it?
I don't want to get into any religious IDE war but Eclipse 3 with WTP 1.0.
> Any pointers/links
> to how you got that setup?
See below for the outline.
> Unfortunately for the environment I am working
> in an IDE specific solution would be incomplete. We have a broad range of
> use cases (IDEs, OSes) as well as users where we need people to be able to
> checkout a project and be productive with it in a minimal amount of time.
> So doing IDE specific tweaks won't cut it. Our solution has worked
> extremely well with other app containers for example WebSphere, Resin and
> Jetty (all three that we use) come with support for something like this out
> of the box.
I understand what you are saying, from your commercial standpoint you
see the lack of this feature as causing a headache in supporting your
customer base container diversity.
My point from a technical standpoint your feature is already obsolete
since at least one popular IDE already has a working solution which
probably works for all containers the IDE supports (I've never tested on
anything but TC) which includes the ones you list above. It is just
matter of time before the other popular IDEs play catch up.
> The IDE we use really depends on the customer, project and environment. So
> could be any of the following ant+text editors, eclipse, WSDC, and/or
> netbeans... We can seemlessly switch between any of these using this
> technique by just adding the extendedClasspath line to the context and
> dropping a jar in server/lib/ all of which is handled by our ant scripts.
>
> I am all for continuing this tangential discussion of webapp development
> techniques but it really is tangential to the intent of the original post..
I'm not against your feature per say just the reasons you cite the need
for it.
> Hot-code replace works fine in this scenario, I get the impression that you
> think it doesn't. As for your comments about future proofing. I am very
> confident that IDE's will from now on into the future will compile my .java
> files to some directory on the disk and that this option will be
> configurable and use some consistent default. So this solution is
> completely future-proof.
>
> In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's
> you
> need to manually kick off that process so it is adding a step to the
> edit-compile process.
Are you really sure hot code replace work fine in this scenario, I
thought the IDE had to be able to understand from its internal
dependency graph that the compiled .class file is running on the JVM to
be able to push an update to that JVM.
The situation you present sounds like you have a web-app running under
TC under the IDE and another standalone java project in the IDE. If you
edit this standalone project sure you get a compiled .class file out of
it, but why would the IDE then offer it up to the TC JVM ? For all
intents and purposes the standalone project is disconnected from the
running web-app.
Since Eclipse WTP 1.0 you can create a J2EE Utility Project which can
contribute a JAR into the WEB-INF/lib of J2EE Dynamic Web Project
(create those 2 project types, goto the Project Properties page J2EE
Module Dependancy of the DWP and tick the box). You can have both
projects open and develop them at the same time with the IDE
automatically propagating the new compiled code.
This feature is still not perfect since TC will auto-redeploy when a JAR
changes, the WTP feature would be better if it had a toggle to allow the
J2EE Utility Project exported as individual .class files into the
WEB-INF/classes tree this would allow Eclipse to attempt a Hot-code
replace and thwart some unnecessary TC reloading.
In any case if you alter the fields of a class which has one or more
active instances Sun's JVM doesn't allow that class to be
hot-code-replaced you get an error and Eclipse offers to
continue/restart/shutdown the JVM. But there are many common cases
where it works well, like adding/changing methods.
Eclipse's solution is nearer my vision of the future and generic this
makes it future proof to me. What you are proposing as a solution to
this problem is a band aid, a dead end; that prohibits the next step to
be taken by the IDE towards the ultimate seamless developer experience.
Geez I should try marketing.
> Effectively adding a deploy step so you have
> edit-compile-deploy. Which is exactly what I am trying to avoid albeit if
> it is properly contained in the IDE it is less of a headache.
This is back to my opening question. Which bit is the tedious task for
you at this time ? The "having to click a button", the "compile, build
JAR, copy JAR to web-app" or the "waiting for the reploy to complete" ?
These were (before WTP 1.0) the only productivity killers for me.
The first and second problem have been solved.
The third problem has room for improvement (by reducing the cases where
a redeploy is necessary) but at this time serves a useful purpose of
flushing out the old version of code from the container, causing the
container to re-read tag descriptors, causing the container to flush all
tag-pools, causing the web-app to re-read config files, blah blah, so
there are still many changes where a redeploy just can't be avoided.
> I enjoy the discussion of good practices (I don't think there is a one size
> fits all best practice here) for having a smooth development process so
> keep
> it coming ;-)
There are a number of little gems of info that maybe useful, like making
sure you setup a META-INF/context.xml and use a <Context ... debug="1"
reloadable="false"> then sit back and let Eclipse do the right thing.
Eclipse itself has room for improvement, like it shouldn't update the
timestamp on files which have not changed. The container correctly
thinks it is a new file version when infact no net change occured but
the lame building tools updated the target anyway. There are some
really lame components which truncate files to rebuild them, rather than
write to a .tmp file, do an overwrite-if-modified check. These things
all contribute to unnecessary web-app redeploys which impedes productivity.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: WebappLoader RFC
Posted by Glen Marchesani <gd...@gmail.com>.
The IDE features you mention sound cool which one is it? Any pointers/links
to how you got that setup? Unfortunately for the environment I am working
in an IDE specific solution would be incomplete. We have a broad range of
use cases (IDEs, OSes) as well as users where we need people to be able to
checkout a project and be productive with it in a minimal amount of time.
So doing IDE specific tweaks won't cut it. Our solution has worked
extremely well with other app containers for example WebSphere, Resin and
Jetty (all three that we use) come with support for something like this out
of the box.
The IDE we use really depends on the customer, project and environment. So
could be any of the following ant+text editors, eclipse, WSDC, and/or
netbeans... We can seemlessly switch between any of these using this
technique by just adding the extendedClasspath line to the context and
dropping a jar in server/lib/ all of which is handled by our ant scripts.
I am all for continuing this tangential discussion of webapp development
techniques but it really is tangential to the intent of the original post..
Hot-code replace works fine in this scenario, I get the impression that you
think it doesn't. As for your comments about future proofing. I am very
confident that IDE's will from now on into the future will compile my .java
files to some directory on the disk and that this option will be
configurable and use some consistent default. So this solution is
completely future-proof.
In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's you
need to manually kick off that process so it is adding a step to the
edit-compile process. Effectively adding a deploy step so you have
edit-compile-deploy. Which is exactly what I am trying to avoid albeit if
it is properly contained in the IDE it is less of a headache.
I enjoy the discussion of good practices (I don't think there is a one size
fits all best practice here) for having a smooth development process so keep
it coming ;-)
On 6/13/06, Darryl Miles <da...@netbauds.net> wrote:
>
> Glen Marchesani wrote:
> > <Loader
> > className="org.apache.catalina.loader.MyWebappLoader"
> >
> extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/"
> > />
> > </Context>
> >
> > The reason for doing this is when developping a webapp that consists of
> > several smaller projects I wanted to be able to from within the ide
> > edit-compile-run skipping the deploy step. Skipping the deploy step
> > saves a
> > fair bit of tediousness.
>
> Which IDE are you using ?
>
> My IDE understands both the containers classpath and the web-app
> classpath fairly well. This means my IDE is able to resolve a
> dependency tree so its able to calculate the best possible approach to
> take. My IDE also supports hot-code replace (providing the JVM will
> allow it for a given situation, adding fields is a problem when one or
> more instances exist). My IDE also supports exporting of a JAR from
> another project into the WEB-INF/lib of the web-app project that is
> running under a debugging version of TC.
>
> If you are now bypassing all of the above, how do you cope with the
> problematic scenarios this now presents ? On the face of it; it may
> appear to skip the redeploy process but how can you be sure what you are
> debugging is the current version of code ? Then how in the future as
> IDE technology and tooling gets better can it make the best decision
> given that only the IDE has all the available knowledge about the
> edit-compile-run process.
>
>
> In short if one popular IDE is able to do so much (without patching
> features into TC) then it would appear to set the mark of what is
> possible. It questions if your approach would be a long term fix or
> just a patch over how you currently see the problem in the moment.
>
>
> Maybe your problem is more of configuration.
>
> Infact I think might be worth adding a section to the documentation
> outlining the features TC supports in the development cycle and when and
> how to set them up for use. Then another section on how setup (or tips)
> on working with a particular IDE (from the web-app developers PoV).
>
>
> Darryl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: WebappLoader RFC
Posted by Darryl Miles <da...@netbauds.net>.
Glen Marchesani wrote:
> <Loader
> className="org.apache.catalina.loader.MyWebappLoader"
> extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/"
> />
> </Context>
>
> The reason for doing this is when developping a webapp that consists of
> several smaller projects I wanted to be able to from within the ide
> edit-compile-run skipping the deploy step. Skipping the deploy step
> saves a
> fair bit of tediousness.
Which IDE are you using ?
My IDE understands both the containers classpath and the web-app
classpath fairly well. This means my IDE is able to resolve a
dependency tree so its able to calculate the best possible approach to
take. My IDE also supports hot-code replace (providing the JVM will
allow it for a given situation, adding fields is a problem when one or
more instances exist). My IDE also supports exporting of a JAR from
another project into the WEB-INF/lib of the web-app project that is
running under a debugging version of TC.
If you are now bypassing all of the above, how do you cope with the
problematic scenarios this now presents ? On the face of it; it may
appear to skip the redeploy process but how can you be sure what you are
debugging is the current version of code ? Then how in the future as
IDE technology and tooling gets better can it make the best decision
given that only the IDE has all the available knowledge about the
edit-compile-run process.
In short if one popular IDE is able to do so much (without patching
features into TC) then it would appear to set the mark of what is
possible. It questions if your approach would be a long term fix or
just a patch over how you currently see the problem in the moment.
Maybe your problem is more of configuration.
Infact I think might be worth adding a section to the documentation
outlining the features TC supports in the development cycle and when and
how to set them up for use. Then another section on how setup (or tips)
on working with a particular IDE (from the web-app developers PoV).
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org