I have Jetty 9 deployed on production right now. I was working, but then recently I pushed some change and now my production database jndi connection doesn't work anymore. ActiveWeb complains
There are no connection specs in 'production' environment
At this point of the process, I'm over trying to configure everything to work. I wasted days trying to get Jetty and AW to run on Elastic Beanstalk and I ended up going with my own deploy (I've deployed dozens of my own production server setups over the years). With Jetty there are multiple configs along with my web.xml and I just need to get it working on move on.
I've seen Tomcat mentioned in some AW posts for production, so I'm just gonna go with that.
I'm sticking with AW because we're building something that needs to handle a decent load (we already have the customers) and AW will give me better performance for the price than Rails will. However, there is little to no documentation on best practices to deploying AW to production.
So, my question now is, what version of Tomcat should I use? 8.x or 9.x? I see Servlet 3.x spec thrown around in the AW docs, so I'm guessing Tomcat 8, but will I be ok running that on 9? Are there any pros / cons?
I usually go with the latest rev of anything and just want to check before I deploy.
We have switched to Tomcat 8.5.32.0 a few months ago, and it is working well. JavaLite indeed performs a lot better than Rails (will have to pay ~10x for Rails infrastructure).
We have not tried Tomcat 9 yet, but I see no reason it would not work. ActiveWeb is based on the the older Servlet 2.3 specification, so any Servlet container should just run JavaLite.
Related
For work, I need a free web server system to host a few web apps that I will develop. The server will be installed on Windows. The apps will need to be able to access a bunch of files on the intranet, and massage them. Mostly 10 people at same time will be using the apps. I would prefer to write code in .NET as it contains many great APIs, but I am not sure if the latest IIS Express has any major restrictions (number of clients connected to web server or database, etc.).
The other web servers I looked at (which are not .NET) are:
glassfish - seems that many are switching from it since Oracle stopped supporting it
wamp servers - there are many, the other day I installed wampserver and wrote an app in PHP to see how good it is. I must say PHP was very slow accessing my intranet files and processing them.
oracle weblogic server - never used it and have no idea how good it is
tomee - seems to be new and I do not know how good it is for web application development
I am wondering what do you recommend?
Thank you
first of all I very invested in TomEE. That here here is my feedback:
weblo, TomEE and GlassFish are java servers where wamp is a php/httpd one. Depending what you target it can be enough to make a choice (investment for java is more important than php).
If you choose java then weblogic is not free AFAIK.
Then TomEE is very close to TomEE giving you just all the power you need for web development so it is a safe choice (you'll benefit from a lot of integration and tools for free).
GlassFish is not bad by itself and the best way to select one server is to test it with a small app in your environment IMO.
I am just starting a new web application (as a learning project). I have some freedom to choose what framework I use, but I must use JavaEE, it must be MVC, and it must run on Tomcat 6.0.24. I've decided to go with JSF 2, using the MyFaces implementation (the choice of MyFaces was arbitrary...I just need to get started with something to learn, but I wanted it to be something used in practice for real-world apps). The latest release is 2.1.11, and I figured I'd go with that. However, will I run into any problems trying to run an app built with MyFaces 2.1.11 on Tomcat 6.0.24? I'm new to Java web development and JSF, so I wasn't sure if there'd be any issues, but I don't want to get down this path (especially starting from scratch with whichever framework I use) and realize that my app won't work with Tomcat 6.0.24. Thanks.
Ok, as I've done some more reading and practicing over the past week, things have become clearer and the feeling of being overwhelmed by buzzwords has subsided a bit. In retrospect, getting JSF 2 and JSTL in place were pretty easy, and I now have what I think is a fully functional development environment.
Confirming the supported Servlet/JSF versions in Tomcat was a cinch. Using Eclipse Indigo, JavaEE 6, Apache MyFaces 2.1.11, and JSTL 1.2.1, my (very simple) test apps worked on Tomcat 6.0.24.
This was a very specific question, so I'm not sure whether it will be of use for anyone else, but I figured I'd give an answer just for completeness. Thanks to BalusC for his input on this question and for his many other contributions on SO!
I have been trying to deploy my web application (war) from Glassfish AdminConsole but I keep getting the following error message -
Exception while loading the app : Error in linking security policy for MyApp-war -- Inconsistent Module State.
But it deploys without any problem when I do it from Netbeans. (I don't know if Netbeans is doing something that I am missing before deploying the application.)
And I also tried with the latest version of Glassfish (i.e. V3.1.1 (build 12)
), and I can deploy the same application without any problem from AdminConsole.
I am using Glassfish 3.1 (build 43) and Netbeans 7.0.
Is there any Security Policy setting that I have to have before deploying my application with this version of Glassfish?
The same thing was happening to me.
Here is what I did:
Stoped the Glassfish server
Deleted all the content from glassfishhome/glassfish/domains/yourdomainname/generated
Started Glassfish
It worked for me. But what still sucks is that everytime I need to deploy I need to follow this procedure again...
I will answer this in response to the comment of #SteveTaylor. His answer in the above comment helped me solving the problem, so he is the one who deserves the credits.
Original answer from #SteveTaylor:
The problem is a corrupt OSGi cache. The reason upgrading worked for
you is because you started with a clean OSGi cache. All that's needed
to fix this problem is delete the entire OSGi cache under
$GLASSFISH_HOME/glassfish/domains//osgi-cache
This answer worked for me as well. Thanks a lot. I am using a cluster (Oracle GlassFish 3.1.2.2) consisting of two nodes and a domain server. I removed the OSGi cache under all three directories (2 nodes and domain) after I stopped the cluster and restarted it then. After that, the problem was solved.
It happen to me to, especially after I check out different version of my web application and try to deploy it to Glassfish.
The only certain solution I've found is to completely stop galssfish, restart it and deploy the application.
Probably a bug in the version of Glassfish I was using.
Basically changing to a different (later) version solved the problem.
In my case, I was missing #Stateless tag in one of my Managed Beans. Adding it, solved it for me. Hope it helps.
I don't know if this helps, but I got the same error when deploying from the command line. In my case I'm using a pretty up-to-date version (GlassFish Server Open Source Edition 3.1.2 (build 23)). What worked for me was removing --force=true from this:
$ sudo /usr/local/glassfish3/bin/asadmin deploy --force=true ~cornell/designer.war
What's important (I think) is that I had not previously deployed the app. Confusing!
In my case ,just I do "clean and build". that usually works well.
It happen to me too. In my case, it have occurred when I try to deploy the project and forget to start the database server, and then when I start the database server and I deployed again, I got this error message.
When this occurred, I recompile the code, stop the server, undeploy the old project and deploy the new again.
I am trying to deploy the Liferay portal onto the Eclipse Virgo Web Server and haven't had much luck. I have at least solved two of the problems involved in this process:
1) The portal.jar that is part of the liferay dependencies has a malformed manifest. The Bundle-SymbolicName incorrectly sets the value to "JSR 286" when it should be "JSR286" (no space). Also, the Import-Package has a bunch of spaces/tabs and I removed those. That took care of problem 1.
2) The Virgo web server wasn't finding the liferay dependency jars (at least not where I was putting them), so I just stuck the dependencies into the main liferay.WAR and that has gotten rid of all the error messages.
Unfortunately, this didn't solve the overall problem. Perhaps there are other issues, but Virgo is not reporting any errors.
I've looked on both the Liferay and Virgo forums, but no one seems to have an answer to this, so I'm hoping someone here has had more success than me. If so, please let me know what you tried to get it to work.
A little more detail: I used the liferay-portal-6.0.5 WAR that is not bundled with an app server. And, I'm using Virgo 2.1.0.
Thanks,
David
I got it! http://sourceforge.net/projects/liferayforvirgo. But Virgo 3.6.0.RELEASE demonstrates too low performance and the couple Liferay+Virgo is not able to use for production
We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.