You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jan Vissers <Ja...@cumquat.nl> on 2007/09/30 21:14:24 UTC
"No redeploy, no restart ..." --- yeah right
Yep, its me again asking a question on Tapestry 5 and support for other
web server containers than Jetty for the complete techical features as
depicted for T5. Up until now I have never had a real answer, so I'm
trying my luck again.
On the home page of T5 I read:
http://tapestry.apache.org/tapestry5/
"It's more than what you can do with Tapestry ... it's also how you do it!
Tapestry is a vastly productive environment. Java developers love it
because they can make Java code changes and see them immediately ... no
redeploy, no restart!"
But somewhere I else I read this (on Tomcat):
http://tapestry.apache.org/tapestry5/tomcat.html
"Deploying Tapestry applications into Tomcat is relatively easy, with one
big caveat: you must not store your Tapestry component classes under
WEB-INF/classes.
At startup, Tapestry needs to locate all your page and component classes,
so that it can match page names in request URLs to page classes. Due to
the way Tomcat creates ClassLoaders, this information is not accessible to
Tapestry.
Fortunately, Maven has an option inside its war plugin, archiveClasses,
that changes the packaging; instead of putting compiled classes and
resource files in WEB-INF/classes, they are instead placed inside an
additional JAR inside WEB-INF/lib. This keeps Tapestry happy at runtime."
Doesn't this mean that Tomcat cannot use the great productivity booster of
"No redeploy, no restart"? I was told (by Howard) that for OC4J (Oracle's
J2EE container) I had to do something similar as for Tomcat - so my guess
is that "No redeploy, no restart" is also not feasable on that platform.
So, can I conclude from this that T5 has improved a great deal - but not
everything will work on servlet containers that are actually used?
Thanks,
-J.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "No redeploy, no restart ..." --- yeah right
Posted by Christian Gruber <ch...@gmail.com>.
This is the thing. You can even do this with Weblogic Server - the
trick is just that you have to start it up from within eclipse, and
eclipse's class loader hooks for that j2ee container provide the
classes. As long as you have a proper J2EE container starter that
uses eclipse's own classpath locations, you should be able to do this.
Christian.
On 30-Sep-07, at 7:55 PM, Martin Reurings wrote:
> With our developement team we're currently using maven to build/
> deploy Tapestry 5. By using the latest Eclipse build and wtp we're
> able to run Tapestry 5 on Tomcat 6 without restarting or redeploying
> anything. It seems most of the functionality comes out of Eclipse in
> this case, but it works...
>
> We're just using the default maven structure for our project, let
> maven build our eclipse project files (eclipse:eclipse) with wtp-
> compatibility enabled (-Dwtpversion=1.5) and in the Tomcat settings
> (dbl-click on the server definition inside eclipse) "Serve modules
> without publishing" enabled. In most situations this allows us to
> simply edit our files (java/html/css/gif) save them and go back to
> the browser to test them. Debugging doesn't work as smooth as this
> though, hot-deploying while debugging seems to fail and adding a new
> pages or component requires a server-restart as well :(.
>
> Hope this helps,
>
> Martin
>
> Howard Lewis Ship wrote:
>> First off, developing locally using Jetty is a fine idea, even if
>> you can't
>> deploy the same way. In most any servlet container, updating the
>> WAR causes
>> an undeploy/redeploy that is outside of Tapestry's scope to control.
>>
>> Second, there's a whole lot more that Tapestry *could* do if it
>> replaced the
>> servlet container entirely and acted as its own HTTP server
>> (possibly built
>> on Jetty). But this falls into the "boilling the ocean" category.
>>
>> Third, there is unfortunately a lot of vaguness in the servlet API
>> spec.
>> Remy (Tomcat) sees the class loader issue one way, Greg (Jetty)
>> sees it the
>> correct way.
>>
>> I can't emphasis enough: use Jetty for your tight, local write-test-
>> fix
>> cycle (with no deploys, and fairly rare restarts). But using Ant
>> or Maven
>> to package your application normally for deployment.
>>
>> On 9/30/07, Jan Vissers <Ja...@cumquat.nl> wrote:
>>
>>> Yep, its me again asking a question on Tapestry 5 and support for
>>> other
>>> web server containers than Jetty for the complete techical
>>> features as
>>> depicted for T5. Up until now I have never had a real answer, so I'm
>>> trying my luck again.
>>>
>>> On the home page of T5 I read:
>>> http://tapestry.apache.org/tapestry5/
>>>
>>> "It's more than what you can do with Tapestry ... it's also how
>>> you do it!
>>> Tapestry is a vastly productive environment. Java developers love it
>>> because they can make Java code changes and see them
>>> immediately ... no
>>> redeploy, no restart!"
>>>
>>> But somewhere I else I read this (on Tomcat):
>>> http://tapestry.apache.org/tapestry5/tomcat.html
>>>
>>> "Deploying Tapestry applications into Tomcat is relatively easy,
>>> with one
>>> big caveat: you must not store your Tapestry component classes under
>>> WEB-INF/classes.
>>>
>>> At startup, Tapestry needs to locate all your page and component
>>> classes,
>>> so that it can match page names in request URLs to page classes.
>>> Due to
>>> the way Tomcat creates ClassLoaders, this information is not
>>> accessible to
>>> Tapestry.
>>>
>>> Fortunately, Maven has an option inside its war plugin,
>>> archiveClasses,
>>> that changes the packaging; instead of putting compiled classes and
>>> resource files in WEB-INF/classes, they are instead placed inside an
>>> additional JAR inside WEB-INF/lib. This keeps Tapestry happy at
>>> runtime."
>>>
>>>
>>> Doesn't this mean that Tomcat cannot use the great productivity
>>> booster of
>>> "No redeploy, no restart"? I was told (by Howard) that for OC4J
>>> (Oracle's
>>> J2EE container) I had to do something similar as for Tomcat - so
>>> my guess
>>> is that "No redeploy, no restart" is also not feasable on that
>>> platform.
>>>
>>>
>>> So, can I conclude from this that T5 has improved a great deal -
>>> but not
>>> everything will work on servlet containers that are actually used?
>>>
>>> Thanks,
>>> -J.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "No redeploy, no restart ..." --- yeah right
Posted by Martin Reurings <ma...@windgazer.nl>.
With our developement team we're currently using maven to build/deploy
Tapestry 5. By using the latest Eclipse build and wtp we're able to run
Tapestry 5 on Tomcat 6 without restarting or redeploying anything. It
seems most of the functionality comes out of Eclipse in this case, but
it works...
We're just using the default maven structure for our project, let maven
build our eclipse project files (eclipse:eclipse) with wtp-compatibility
enabled (-Dwtpversion=1.5) and in the Tomcat settings (dbl-click on the
server definition inside eclipse) "Serve modules without publishing"
enabled. In most situations this allows us to simply edit our files
(java/html/css/gif) save them and go back to the browser to test them.
Debugging doesn't work as smooth as this though, hot-deploying while
debugging seems to fail and adding a new pages or component requires a
server-restart as well :(.
Hope this helps,
Martin
Howard Lewis Ship wrote:
> First off, developing locally using Jetty is a fine idea, even if you can't
> deploy the same way. In most any servlet container, updating the WAR causes
> an undeploy/redeploy that is outside of Tapestry's scope to control.
>
> Second, there's a whole lot more that Tapestry *could* do if it replaced the
> servlet container entirely and acted as its own HTTP server (possibly built
> on Jetty). But this falls into the "boilling the ocean" category.
>
> Third, there is unfortunately a lot of vaguness in the servlet API spec.
> Remy (Tomcat) sees the class loader issue one way, Greg (Jetty) sees it the
> correct way.
>
> I can't emphasis enough: use Jetty for your tight, local write-test-fix
> cycle (with no deploys, and fairly rare restarts). But using Ant or Maven
> to package your application normally for deployment.
>
> On 9/30/07, Jan Vissers <Ja...@cumquat.nl> wrote:
>
>> Yep, its me again asking a question on Tapestry 5 and support for other
>> web server containers than Jetty for the complete techical features as
>> depicted for T5. Up until now I have never had a real answer, so I'm
>> trying my luck again.
>>
>> On the home page of T5 I read:
>> http://tapestry.apache.org/tapestry5/
>>
>> "It's more than what you can do with Tapestry ... it's also how you do it!
>> Tapestry is a vastly productive environment. Java developers love it
>> because they can make Java code changes and see them immediately ... no
>> redeploy, no restart!"
>>
>> But somewhere I else I read this (on Tomcat):
>> http://tapestry.apache.org/tapestry5/tomcat.html
>>
>> "Deploying Tapestry applications into Tomcat is relatively easy, with one
>> big caveat: you must not store your Tapestry component classes under
>> WEB-INF/classes.
>>
>> At startup, Tapestry needs to locate all your page and component classes,
>> so that it can match page names in request URLs to page classes. Due to
>> the way Tomcat creates ClassLoaders, this information is not accessible to
>> Tapestry.
>>
>> Fortunately, Maven has an option inside its war plugin, archiveClasses,
>> that changes the packaging; instead of putting compiled classes and
>> resource files in WEB-INF/classes, they are instead placed inside an
>> additional JAR inside WEB-INF/lib. This keeps Tapestry happy at runtime."
>>
>>
>> Doesn't this mean that Tomcat cannot use the great productivity booster of
>> "No redeploy, no restart"? I was told (by Howard) that for OC4J (Oracle's
>> J2EE container) I had to do something similar as for Tomcat - so my guess
>> is that "No redeploy, no restart" is also not feasable on that platform.
>>
>>
>> So, can I conclude from this that T5 has improved a great deal - but not
>> everything will work on servlet containers that are actually used?
>>
>> Thanks,
>> -J.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
Re: "No redeploy, no restart ..." --- yeah right
Posted by Massimo Lusetti <ml...@gmail.com>.
On 9/30/07, Geoff Callender <ge...@gmail.com> wrote:
> Where does that leave those of us who wish to use EJB3?
A brave soul...
> With T4 I developed straight into an exploded EAR while JBoss ran the
> app. It worked beautifully and gave me the best of both worlds -
> Tapestry and EJB3. To do the same with Jetty would require Jetty to
> run EJB3. Since it doesn't, I'd need to run something like the JBoss
> Microcontainer in Jetty, but the Microcontainer isn't ready yet.
Did you forget about Geronimo? :)
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "No redeploy, no restart ..." --- yeah right
Posted by Christian Gruber <ch...@gmail.com>.
Heh. I had to almost do exactly that for my flex2 maven plugin.
Christian.
On 30-Sep-07, at 5:41 PM, Howard Lewis Ship wrote:
> (I would
> also have to come up with a special version of the Maven WAR plugin,
> for
> example).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "No redeploy, no restart ..." --- yeah right
Posted by Howard Lewis Ship <hl...@gmail.com>.
Seam works by putting the classes subject to live class reloading into a
special folder, something I've been loathe to force upon the world (I would
also have to come up with a special version of the Maven WAR plugin, for
example).
On 9/30/07, Geoff Callender <ge...@gmail.com> wrote:
>
> Where does that leave those of us who wish to use EJB3?
>
> With T4 I developed straight into an exploded EAR while JBoss ran the
> app. It worked beautifully and gave me the best of both worlds -
> Tapestry and EJB3. To do the same with Jetty would require Jetty to
> run EJB3. Since it doesn't, I'd need to run something like the JBoss
> Microcontainer in Jetty, but the Microcontainer isn't ready yet.
>
> So does Jetty really suit everyone? It seems that the JBoss Seam
> guys found a way to work with Tomcat. Can't T5 too?
>
> Cheers,
> Geoff
>
> On 01/10/2007, at 5:35 AM, Howard Lewis Ship wrote:
>
> > First off, developing locally using Jetty is a fine idea, even if
> > you can't
> > deploy the same way. In most any servlet container, updating the
> > WAR causes
> > an undeploy/redeploy that is outside of Tapestry's scope to control.
> >
> > Second, there's a whole lot more that Tapestry *could* do if it
> > replaced the
> > servlet container entirely and acted as its own HTTP server
> > (possibly built
> > on Jetty). But this falls into the "boilling the ocean" category.
> >
> > Third, there is unfortunately a lot of vaguness in the servlet API
> > spec.
> > Remy (Tomcat) sees the class loader issue one way, Greg (Jetty)
> > sees it the
> > correct way.
> >
> > I can't emphasis enough: use Jetty for your tight, local write-test-
> > fix
> > cycle (with no deploys, and fairly rare restarts). But using Ant
> > or Maven
> > to package your application normally for deployment.
> >
> > On 9/30/07, Jan Vissers <Ja...@cumquat.nl> wrote:
> >>
> >> Yep, its me again asking a question on Tapestry 5 and support for
> >> other
> >> web server containers than Jetty for the complete techical
> >> features as
> >> depicted for T5. Up until now I have never had a real answer, so I'm
> >> trying my luck again.
> >>
> >> On the home page of T5 I read:
> >> http://tapestry.apache.org/tapestry5/
> >>
> >> "It's more than what you can do with Tapestry ... it's also how
> >> you do it!
> >> Tapestry is a vastly productive environment. Java developers love it
> >> because they can make Java code changes and see them
> >> immediately ... no
> >> redeploy, no restart!"
> >>
> >> But somewhere I else I read this (on Tomcat):
> >> http://tapestry.apache.org/tapestry5/tomcat.html
> >>
> >> "Deploying Tapestry applications into Tomcat is relatively easy,
> >> with one
> >> big caveat: you must not store your Tapestry component classes under
> >> WEB-INF/classes.
> >>
> >> At startup, Tapestry needs to locate all your page and component
> >> classes,
> >> so that it can match page names in request URLs to page classes.
> >> Due to
> >> the way Tomcat creates ClassLoaders, this information is not
> >> accessible to
> >> Tapestry.
> >>
> >> Fortunately, Maven has an option inside its war plugin,
> >> archiveClasses,
> >> that changes the packaging; instead of putting compiled classes and
> >> resource files in WEB-INF/classes, they are instead placed inside an
> >> additional JAR inside WEB-INF/lib. This keeps Tapestry happy at
> >> runtime."
> >>
> >>
> >> Doesn't this mean that Tomcat cannot use the great productivity
> >> booster of
> >> "No redeploy, no restart"? I was told (by Howard) that for OC4J
> >> (Oracle's
> >> J2EE container) I had to do something similar as for Tomcat - so
> >> my guess
> >> is that "No redeploy, no restart" is also not feasable on that
> >> platform.
> >>
> >>
> >> So, can I conclude from this that T5 has improved a great deal -
> >> but not
> >> everything will work on servlet containers that are actually used?
> >>
> >> Thanks,
> >> -J.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Howard M. Lewis Ship
> > Partner and Senior Architect at Feature50
> >
> > Creator Apache Tapestry and Apache HiveMind
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
Re: "No redeploy, no restart ..." --- yeah right
Posted by Geoff Callender <ge...@gmail.com>.
Where does that leave those of us who wish to use EJB3?
With T4 I developed straight into an exploded EAR while JBoss ran the
app. It worked beautifully and gave me the best of both worlds -
Tapestry and EJB3. To do the same with Jetty would require Jetty to
run EJB3. Since it doesn't, I'd need to run something like the JBoss
Microcontainer in Jetty, but the Microcontainer isn't ready yet.
So does Jetty really suit everyone? It seems that the JBoss Seam
guys found a way to work with Tomcat. Can't T5 too?
Cheers,
Geoff
On 01/10/2007, at 5:35 AM, Howard Lewis Ship wrote:
> First off, developing locally using Jetty is a fine idea, even if
> you can't
> deploy the same way. In most any servlet container, updating the
> WAR causes
> an undeploy/redeploy that is outside of Tapestry's scope to control.
>
> Second, there's a whole lot more that Tapestry *could* do if it
> replaced the
> servlet container entirely and acted as its own HTTP server
> (possibly built
> on Jetty). But this falls into the "boilling the ocean" category.
>
> Third, there is unfortunately a lot of vaguness in the servlet API
> spec.
> Remy (Tomcat) sees the class loader issue one way, Greg (Jetty)
> sees it the
> correct way.
>
> I can't emphasis enough: use Jetty for your tight, local write-test-
> fix
> cycle (with no deploys, and fairly rare restarts). But using Ant
> or Maven
> to package your application normally for deployment.
>
> On 9/30/07, Jan Vissers <Ja...@cumquat.nl> wrote:
>>
>> Yep, its me again asking a question on Tapestry 5 and support for
>> other
>> web server containers than Jetty for the complete techical
>> features as
>> depicted for T5. Up until now I have never had a real answer, so I'm
>> trying my luck again.
>>
>> On the home page of T5 I read:
>> http://tapestry.apache.org/tapestry5/
>>
>> "It's more than what you can do with Tapestry ... it's also how
>> you do it!
>> Tapestry is a vastly productive environment. Java developers love it
>> because they can make Java code changes and see them
>> immediately ... no
>> redeploy, no restart!"
>>
>> But somewhere I else I read this (on Tomcat):
>> http://tapestry.apache.org/tapestry5/tomcat.html
>>
>> "Deploying Tapestry applications into Tomcat is relatively easy,
>> with one
>> big caveat: you must not store your Tapestry component classes under
>> WEB-INF/classes.
>>
>> At startup, Tapestry needs to locate all your page and component
>> classes,
>> so that it can match page names in request URLs to page classes.
>> Due to
>> the way Tomcat creates ClassLoaders, this information is not
>> accessible to
>> Tapestry.
>>
>> Fortunately, Maven has an option inside its war plugin,
>> archiveClasses,
>> that changes the packaging; instead of putting compiled classes and
>> resource files in WEB-INF/classes, they are instead placed inside an
>> additional JAR inside WEB-INF/lib. This keeps Tapestry happy at
>> runtime."
>>
>>
>> Doesn't this mean that Tomcat cannot use the great productivity
>> booster of
>> "No redeploy, no restart"? I was told (by Howard) that for OC4J
>> (Oracle's
>> J2EE container) I had to do something similar as for Tomcat - so
>> my guess
>> is that "No redeploy, no restart" is also not feasable on that
>> platform.
>>
>>
>> So, can I conclude from this that T5 has improved a great deal -
>> but not
>> everything will work on servlet containers that are actually used?
>>
>> Thanks,
>> -J.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "No redeploy, no restart ..." --- yeah right
Posted by Howard Lewis Ship <hl...@gmail.com>.
First off, developing locally using Jetty is a fine idea, even if you can't
deploy the same way. In most any servlet container, updating the WAR causes
an undeploy/redeploy that is outside of Tapestry's scope to control.
Second, there's a whole lot more that Tapestry *could* do if it replaced the
servlet container entirely and acted as its own HTTP server (possibly built
on Jetty). But this falls into the "boilling the ocean" category.
Third, there is unfortunately a lot of vaguness in the servlet API spec.
Remy (Tomcat) sees the class loader issue one way, Greg (Jetty) sees it the
correct way.
I can't emphasis enough: use Jetty for your tight, local write-test-fix
cycle (with no deploys, and fairly rare restarts). But using Ant or Maven
to package your application normally for deployment.
On 9/30/07, Jan Vissers <Ja...@cumquat.nl> wrote:
>
> Yep, its me again asking a question on Tapestry 5 and support for other
> web server containers than Jetty for the complete techical features as
> depicted for T5. Up until now I have never had a real answer, so I'm
> trying my luck again.
>
> On the home page of T5 I read:
> http://tapestry.apache.org/tapestry5/
>
> "It's more than what you can do with Tapestry ... it's also how you do it!
> Tapestry is a vastly productive environment. Java developers love it
> because they can make Java code changes and see them immediately ... no
> redeploy, no restart!"
>
> But somewhere I else I read this (on Tomcat):
> http://tapestry.apache.org/tapestry5/tomcat.html
>
> "Deploying Tapestry applications into Tomcat is relatively easy, with one
> big caveat: you must not store your Tapestry component classes under
> WEB-INF/classes.
>
> At startup, Tapestry needs to locate all your page and component classes,
> so that it can match page names in request URLs to page classes. Due to
> the way Tomcat creates ClassLoaders, this information is not accessible to
> Tapestry.
>
> Fortunately, Maven has an option inside its war plugin, archiveClasses,
> that changes the packaging; instead of putting compiled classes and
> resource files in WEB-INF/classes, they are instead placed inside an
> additional JAR inside WEB-INF/lib. This keeps Tapestry happy at runtime."
>
>
> Doesn't this mean that Tomcat cannot use the great productivity booster of
> "No redeploy, no restart"? I was told (by Howard) that for OC4J (Oracle's
> J2EE container) I had to do something similar as for Tomcat - so my guess
> is that "No redeploy, no restart" is also not feasable on that platform.
>
>
> So, can I conclude from this that T5 has improved a great deal - but not
> everything will work on servlet containers that are actually used?
>
> Thanks,
> -J.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind