> -----Original Message-----
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 1:50 PM
> To: [EMAIL PROTECTED]; Luke Taylor;
> [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Developing with JBoss
>
>
> |In our app, we don't use wars and ears, only jars for our EJBs. Our jsps
> |run off of a directory exposed through Jetty. That way we can
> |easily modify
> |jsps on the fly. Can't see why anybody would use WARS and EARS
> unless you
> |were shipping a product.
>
> this from teh "packaging" lover of 3 days ago ?
>
> ;=)
>
Doh!
I did say, unless you were shipping a product.... :)
> marcf
> |
> |> -----Original Message-----
> |> From: [EMAIL PROTECTED]
> |> [mailto:[EMAIL PROTECTED]]On Behalf Of Luke
> |> Taylor
> |> Sent: Wednesday, November 21, 2001 12:59 PM
> |> To: [EMAIL PROTECTED]
> |> Subject: Re: [JBoss-dev] Developing with JBoss
> |>
> |>
> |> Andrew Scherpbier wrote:
> |>
> |> > Rickard �berg wrote:
> |> >
> |> >> David Jencks wrote:
> |> >>
> |> >>> How would this help in the least? My understanding is that
> |> if you use a
> |> >>> directory, the dd is checked for time changes
> |> >>
> |> >>
> |> >> For the auto-deployer, yes. I think I'd actually prefer to
> |not use the
> |> >> auto-deployer, and instead make an Ant task that does the deploy
> |> >> command explicitly. Then there's no need to watch dd's or anything.
> |> >
> |> >
> |> > I ran into the same problem and solved it by running Tomcat 4.0 as a
> |> > separate process during development. Since tomcat works just
> |fine with
> |> > an already unpacked tree for my webapp, I simply modify my
> |> JSPs directly
> |> > (I have a symbolic link from my webapp development tree to tomcat's
> |> > webapps directory.)
> |>
> |>
> |> I remember now raising the same sort of issue during the JBoss training
> |> in London. I always end up running a separate web container during
> |> development because the turnaround of redeploying due to minor jsp
> |> changes is just too frustrating.
> |>
> |> It's not just about the time for the deployment, which is minimal - if
> |> you're working on frontend stuff and just essentially modifying web
> |> pages, then you lose your whole session state. If you have a
> complicated
> |> web application with security, shopping carts etc, and you're
> working on
> |> the checkout pages, then you have to go through the whole use-case
> |> procedure every time you redeploy. If a web container can be configured
> |> to pick up the jsp's directly then you only have to reload the page to
> |> see a change.
> |>
> |> The only solution I've found is to run a separate tomcat instance
> |> against jboss, with only the web application configured. The
> full ear is
> |> still deployed in jboss as it would be in production. Configuring
> |> security for a separate web container is a bit of a drag.
> |>
> |> The ideal situation would be if an integrated JBoss/Jetty or
> |> JBoss/Tomcat could also be configured to use a separately
> configured web
> |> application context during development and have the web coantainer spot
> |> modifications to JSPs as above.
> |>
> |> Dunno if this is feasible, pie in the sky or what ...
> |>
> |> Luke.
> |>
> |>
> |> --
> |> Luke Taylor. Monkey Machine Ltd.
> |> PGP Key ID: 0x57E9523C http://www.mkeym.com
> |>
> |>
> |>
> |>
> |> _______________________________________________
> |> Jboss-development mailing list
> |> [EMAIL PROTECTED]
> |> https://lists.sourceforge.net/lists/listinfo/jboss-development
> |>
> |
> |
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
