geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: no redeploy option for JSP files
Date Sat, 04 Jun 2011 08:42:25 GMT

On Jun 4, 2011, at 4:00 AM, David Jencks wrote:

> 
> On Jun 4, 2011, at 12:03 AM, Kevan Miller wrote:
> 
>> I took a look to see if "no re-deployment when only JSP files are updated" option
on the 3.0 server adapter was working. 
>> 
>> I couldn't get it to work. The server adapter is attempting to update JSP files to
an exploded directory structure. This fails since applications are packaged in a .car archive.
I tried directly editing JSP files in an archive. These edits aren't being detected by Jasper
(I configured development mode). 
>> 
>> Does anybody know of a way to get this to work, currently? It's time, IMO, to stop
storing apps in a .car archive.
> 
> I'm not sure what you mean by this.  Not a .car or not an archive?

Sorry, I mean the .car (archive) files which are stored in the repository in a zip file format.

> 
>> Wondering if there's an option, in the interim to prevent redeploys...
>> 
>> Also, the server adapter option seems to be limited to JSP files. Would be nice if
this feature could be supported for other files (.html, .css, etc...). Has there been discussion
of this?
> 
> Any kind of application after deployment has to look like a bundle to osgi.  A WAB already
does.  A plain war needs to have its manifest updated.  If it looks like a bundle, we can
store the geronimo "compiled plan" in the data area if necessary as we do now for WABs.  Then
we can tell osgi about it with a reference:file url and it won't get copied.  If an IDE doesn't
mind us updating the manifest in its workspace theoretically we could deploy directly from
such a workspace, unpacked.

I think we should have a separate "inPlace" discussion. 

> 
> Another option is to configure the default servlet (for static content) and jsp servlet
to point to file system locations of these files rather than the "in-app" locations.
> 
> I think the second option is more likely to be plausible for 3.0, and the first would
be more practical for the approach in the 3.0-osgi branch.

What's wrong with in-app locations? As long as the .car "bundle" isn't in a zip file format,
the server adapter can manage the files.

--kevan


Mime
View raw message