no redeploy option for JSP files

[Kevan Miller <ke...@gmail.com>]

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. 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?

--kevan

Re: no redeploy option for JSP files

[Kevan Miller <ke...@gmail.com>]

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

Re: no redeploy option for JSP files

[David Jencks <da...@yahoo.com>]

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?

> 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.

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.

thanks
david jencks

> 
> --kevan
>