RE: [OT] Java Hosting Providers, yes, I know it's been brought up before on the list.
I'll include my plug here for a company that we partner with when infrastructure/hosting work is involved. http://www.apparatus.net/hosting/ They are based out of Indianapolis and have some great sysadmins on hand. They currently offer Tomcat 4.1.x, JDK 1.4.2_09 and MySQL 3.2.3 via fedora core 3. They will be upgrading to fedora core 4 soon. -Troy Troy J. Kelley E-gineering, LLC 10401 North Meridian Street | Suite 150 Indianapolis, IN | 46290 | 317.616.3974 www.e-gineering.com -Original Message- From: Bryan LaPlante [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 8:15 AM To: Struts Users Mailing List Subject: Re: [OT] Java Hosting Providers, yes, I know it's been brought up before on the list. I feel your pain guys. I found a provider that made me wander why more of them don't do this. http://www.eapps.com you get a virtual machine running Linux for each domain and one of the most comprehensive control panels I have ever used. 20 bucks a month gives you a fair amount of features and space. My 2 cents Bryan LaPlante - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Wednesday, March 01, 2006 11:28 PM Subject: Re: [OT] Java Hosting Providers, yes, I know it's been brought up before on the list. While I agree they do this (it happened to me once), that is a risk you run in ANY shared hosting environment... an admin has to make a quick decision that will keep the other people sharing your box running, and many times the easiest solution (and arguably best) is to shut down the offending service, or app, or even domain, and then try and resolve it with the person who owns the supposed offender. They seem to be pretty good at least of informing you in a timely fashion that they had to shut X or Y down on you. At least, the one time it happened to me this was true. I have been with Lunarpages for I think close to 3 years now, something like that, and it's been a fantastic experience overall. I personally WOULD recommend them... good price for what you get, and they are quite responsive (in my experience) to support requests, and for the most part let you do what you want (yes, there are some not allowed items to be aware of as Wendy points out). But, I seriously doubt they are checking everyones' domains, they will only know if a problem arises, so if your careful I suspect you can skirt that rule just a bit :) Frank Wendy Smoak wrote: On 3/1/06, Rick Reumann [EMAIL PROTECTED] wrote: Of my mailing list searching, this hosting provider seems to hold the most promise: http://www.lunarpages.com/plan2.php I wouldn't... LunarPages has a habit of just disabling access to anything that they suspect is causing a problem. Sometimes they have a legitimate point, sometimes they just say you're using too many resources or affecting other customers on the server. And look at the things that they say are not allowed, including JSF and Spring: http://helpdesk.lunarpages.com/faq.php?do=articlearticleid=120 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strategy for incorporating Shale w/JSF
I did my best to see if this was already addressed by searching mail archives. All I found so far is a comment from Craig here: http://marc.theaimsgroup.com/?l=struts-userm=112604395721097w=2 Craig writes: If, on the other hand, you decide to commit to JSF's controller early rather than late, you might as well just use Shale along with it from the beginning. Unlike the way that other frameworks deal with JSF, Shale *assumes* you will be using the JSF controller architecture, and it just adds ease of use around problems you'll face anyway. It doesn't try to treat JSF as purely a component architecture. I'm in a situation where I'm consulting in a corporate environment. I really love what shale has to offer, but I'm concerned about adopting things a bit too early. I checked out the API Stability section of the project docs (http://struts.apache.org/struts-shale/api-stability.html - which is great, btw) and I'm trying to answer the question: What components of shale can I integrate into a JSF app and get the biggest benefit from, without sacrificing stability at the functional and API level? For instance, shale-core is a mixture of Developing and Evolving packages at both the Application and Framework level. If I'm writing and enterprise app that's going to production in 6 months, how do I choose wisely? :-) I've included the start of a package dependency diagram that might help - it's incomplete. I figured somebody might know this by heart, and could finish it quickly :-) Feel free to distribute. I've spent the past several days doing research on web app frameworks and JSF is a contender for *this environment* - but only becomes more promising with offerings like facelets and shale (IMHO). Thanks, -Troy Troy J. Kelley E-gineering, LLC 10401 North Meridian Street | Suite 150 Indianapolis, IN | 46290 | 317.616.3974 www.e-gineering.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Strategy for incorporating Shale w/JSF
Craig, *Exactly* what I was looking for, thanks. Yes, we're keeping an eye on MyFaces, Facelets, Tomahawk components, IBM Components (We have Rational Application Developer and IBM ships some components), and the recent news of Oracle donating many components to add to Tomahawk. If I get a chance, I'll play with the remoting stuff and see if I can't find a good use for it in one of our apps. Thanks again, -Troy Troy J. Kelley E-gineering, LLC 10401 North Meridian Street | Suite 150 Indianapolis, IN | 46290 | 317.616.3974 www.e-gineering.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, January 30, 2006 3:46 PM To: Struts Users Mailing List Subject: Re: Strategy for incorporating Shale w/JSF Inline. On 1/30/06, Troy J. Kelley [EMAIL PROTECTED] wrote: I did my best to see if this was already addressed by searching mail archives. All I found so far is a comment from Craig here: http://marc.theaimsgroup.com/?l=struts-userm=112604395721097w=2 Craig writes: If, on the other hand, you decide to commit to JSF's controller early rather than late, you might as well just use Shale along with it from the beginning. Unlike the way that other frameworks deal with JSF, Shale *assumes* you will be using the JSF controller architecture, and it just adds ease of use around problems you'll face anyway. It doesn't try to treat JSF as purely a component architecture. I'm in a situation where I'm consulting in a corporate environment. I really love what shale has to offer, but I'm concerned about adopting things a bit too early. I checked out the API Stability section of the project docs (http://struts.apache.org/struts-shale/api-stability.html - which is great, btw) Thanks ... I hope it nudges my fellow framework developers (both here and other webapp projects) to provide the same sort of information. and I'm trying to answer the question: What components of shale can I integrate into a JSF app and get the biggest benefit from, without sacrificing stability at the functional and API level? For instance, shale-core is a mixture of Developing and Evolving packages at both the Application and Framework level. If I'm writing and enterprise app that's going to production in 6 months, how do I choose wisely? :-) The most conservative approach would be to use the following rules: * Stay away from any package targeted as Framework ... that's for modifying Shale itself, rather than using it. (If you find yourself tempted to change things here, please file RFEs so we can make the stuff you need a standard part of Shale). * Stick with packages marked as Stable or Evolving. In practical terms, that means (as of today): * The JSF components provided by Shale are only those needed to integrate framework capabilities ... I don't forsee Shale itself becoming a general repository for JSF components. Instead, it should interoperate nicely with libraries like those from MyFaces. * The ViewController APIs (org.apache.shale.view) that an application requires are solid, although new features might get added later. One reason for my confidence here is that Sun Java Studio Creator 2 (for which I'm the architect) provides very similar (paranoids would say suspiciously similar :-) capabilities in the page beans that it produces for you, and the paradigm seems to fit the proposed application design pattern quite nicey. * The dialog stuff (one of my favorite features) is marked as Evolving not because I expect to break backwards compatibility, but because some known deficiences need to be addressed (particularly in dealing with more than one simulataneously active dialog) that *might* require such changes. Even in that circumstance, I would strive to not break old apps (one of the reasons Struts 1.x was and is popular is we were really conservative about changes like this) ... but it's not yet clear what we might need/want to do to finish this functionality. * I'm pretty happy with the new remoting stuff (org.apache.shale.remoting) but it's going to stay Evolving until someone actually *does* use it and provides some feedback. Hows that Catch-22 for you? :-). (It also needs better documentation ... in progress.) * Do not assume that APIs marked Developing necessarily *will* break -- so depending on them shouldn't be dismissed out of hand. It's just that the likelihood of needing adaptations here is slightly higher than Evolving packages. I've included the start of a package dependency diagram that might help - it's incomplete. I figured somebody might know this by heart, and could finish it quickly :-) Feel free to distribute. I don't see the attachment, but as long as you stick with the packages targeted at *Application* deveopers rather than *Framework* developers, you should not have to care about internal-to-Shale dependencies on the framework stuff. That's
