My personal experience is that if you're writing the application in any form of tiered way (beans, classes, etc), only service providers that give you your own JVM instance are going to let you deploy those classes anyways (making the non-inclusion of Struts a moot point). I've found that every service provider that I've worked w/ or seen that provides a shared JVM won't allow you to deploy classes. In those situations I've had to write everything in JSP - SUCKS!
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, March 13, 2002 11:17 AM Subject: Perhaps TABOO Question, how to convert struts apps to non-struts > > A co-worker and I were talking about this yesterday and I was curious of > the following.... > > Seems like in order to develop a struts application, you'll have to pay for > a private JVM instance so you can start and stop the tomcat or other JSP > engine so that it can re-read the config.xml files.... > > Question 1: Any plans for struts to change in the future where you can > dynamically add new actions and forwards without having to stop and > re-start the web-server? I would guess (although I could be wrong) that > this would be pretty easy to do within struts in the future? I assume > struts is loading the config files in a DOM. Adding a new servlet within > struts to reload the config files and update the DOM does not seem like it > would be that difficult... > > Question 2: Supposing I wrote this app in struts and I could not find a > sponser to pay the $50 per month fees to host a web-site... Well, I > could reconvert the apps to a non-struts approach and then pay only $10 per > month (because I would no longer need to start/stop the web-server and > would only need to dump updated JSP's and such).... Is there a > document/technique/pattern/advice on the best way to convert existing > struts applications to non-struts? I know that putting javabeans back > into the JSP files would be a royal pain but if it would save $40 per > month, it may be the best way to go :-) > > thanks, > Theron > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
