I asked this on superuser as well, but with no answers (even no views). If it's wrong to mention it here, please let me know or just move it. Thanks.
We are using a shared server (six people with root access for each user), which is reinstalled and -configured soon. I agreed to install GlassFish for everyone to use. However, I am developer and do only know basiscs of Unix/Linux.
Now my question is, what do I have to consider if I want to meet these requirements:
Automatic startup on reboot (did not happen often in the past)
Easy integration with Apache
Usage of existing MySQL/PostgresSQL instance
Patterns/Tools for easy (shared) usage (installation of Java EE apps, administration)
Patterns/Tools for easy (shared) monitoring (resources (mem, db), applications)
Tools for easing remote development (EJB/WAR deployment, JRebel?)
Of course, there might be other topics I forgot which should be addressed.
Automatic start up under FreeBSD can simply be implemented using a start-up script which should just do 'asadmin start-domain' to start glassfish and 'asadmin stop-domain'. I'm sure there's a number of articles on start-up script creation for your version of FreeBSD (I would check FreeBSD Handbook first).
As to remote deployments - you just need a local copy of glassfish and should use it's asadmin utility - it has command line arguments that allow doing any administrative tasks with remote glassfish installations as long as you have admin password on them.
If you have experience with Windows only then I would strongly consider using a Windows box for this. The Glassfish distribution has functionality to register a given domain as a service, and I would suggest that you just create a domain for each developer.
Related
I am new to WebSphere. One of the project came to upgrade the existing IBM WebSphere application server 6.1 to WebSphere application server 8.5. Four custom EJB application is running on server. Please guide what the solution to migrate to 8.5 Application Server.
I've handled a few migrations and there are definitely some gotchas to watch out for:
If this is any more critical than a development system, there is a bit of planning you'll need to do. You'll have to bring over any config from the old environment, and you'll have to make sure your applications will work in the new environment.
For the former, WebSphere itself ships with the configuration migration tools, both as command line tools and as a wizard. If you're migrating between installs on the same machine, I would definitely recommend the wizard as it better explains the process and what each setting does. If the installs are on different systems, the command line tools can help with that, but the wizard cannot. The tools to use are both documented at this link although for some reason the article neglects to mention that the wizard is also called migration.sh or migration.bat
If you have a cell topology (a deployment manager managing some number of application servers) you'll migrate the deployment manager first and then the nodes. In that case, the old cell will be disabled, so make sure you take a full backup of the old environment so you can roll back if you have to. The specific procedure for migrating a cell has a good overall order of steps to take, but doesn't mention the wizard. You can replace the "create profile, backup, restore" cycle with the wizard, but the rest of the steps should remain the same.
If it's just a standalone application server, those can usually coexist at the same time so you may be able to keep the old one active while you set the new one up, but I don't think there are any established documentation on how to do that, so to be safe, backup, and plan for some downtime.
Another consideration will be the applications themselves. You will be moving to a new version of WebSphere which supports a new level of Java EE and runs on much newer Java SE, and there are often problems and incompatibilities that come up. For that, I recommend running the binary application scanner with your applications and environment specified and seeing what it reports. If there are any severe issues it flags, it may be worth investigating those before starting the migration to minimize downtime.
Already I can tell that using EJB on WebSphere 6.1, you'll need to make sure that you install the EJBDeploy tool with your WebSphere 8.5 install. It will be automatically used during application deployment. Without that, it's pretty likely the applications won't work because their old EJBs won't deploy. Because of this, I believe you still need to use Java 7 unless you install this fix to get it to run on Java 8. I do not recommend running on Java 6 because that is going out of service by Oracle within a year or so.
So, to summarize:
Use the binary application scanner to see if there are any immediate compatibility issues to start addressing in the applications themselves
Make sure you have the EJBDeploy tool installed along with WebSphere 8.5
Use the migration wizard or command line tools to bring over your configuration and deploy your applications
#Jarid's answer documents everything available relating to WebSphere migration, and is also a good resource.
WebSphere provides an official migration toolkit to assist with the migration process: https://www.ibm.com/developerworks/library/mw-1701-was-migration/index.html
I understand the concept of source version control and how it applies to self-contained projects like a Windows application. But for web development, most files are stored on the web server. This has become a headache for development with many people just copying and renaming files and then pushing files over to production is another mess.
I need some kind of source version control that is relatively not too difficult to learn and must be GUI-based or have a GUI as an option. The people who will use this have little or no knowledge of the command line.
How can I integrate source version control with web server files? What software is available for such an endeavor? And is it possible to have the source version control software administer both the production and development web servers or I may only have two separate source version control installs for each web server and manually push over changes?
The web servers are Windows-based and also use Tomcat for Java/JSP.
Any help would be appreciated. Thank you.
I think you are not clear on the idea of version control. Version control is about managing your code. It is about putting your code in a remote server (may be in a central location) and accessing it using a client tool. This way a number of people can work on different part of the code and than push their work to version control server. It has nothing do with the type of the project.
The project can be a windows application, web server application or any application.
While using version control, in regular intervals or whenever needed you build your code from the version control server and deploy it to the web server which means you are deploying code that is already build (a .war for a web application).
You first deploy to your development server and later deploy the same war to the production server.
You can use SVN server for your version control server and Tortoise SVN as client.
You have to split in mind two different but interacting things - Version Control and Deploy Tools:
VCS has to do with any evolving over time items, which you want to have under control
Deploy just deliver correct object into the correct place at the correct time and convert "set of something" into Product.
Deploy isn't a problem per se (almost any job can be automated), main problem in multiDEV environment (2+) with central STAGE (less with PROD) server is question of communication between Devs and synchronizing of their operations, i.e. - workflow and management:
just imagine 2 (or more) devs, performing diferent unrelated tasks, which want to test latest own (and only own) changes on common STAGING server (because they haven't functional local environment). If 1-st deploy "some WIP" on server, he don't want to have own tests be interrupted and code poisoned by deploying third-party changes. They must to communicate and coordinate actions, it can't be dumb "copy to..." in post-commit hook
And is it possible to have the source version control software administer both the production and development web servers
Yes. But VCS does not "administer" web-servers in common sense, rather it's "communicates" or "take into account"
We have a java application hosted on JBoss with a Posgres DB, and we've traditionally been selling it as an appliance (full server with application installed). Now, we need to allow clients to be able to download and install it on their servers. What is the best way to approach this? Ideally, I'd like it to be a one packaged installation file that they can run and it checks for dependencies, deploys the war file, executes the postgres sql to setup the database and start up jboss.
JBoss and Postgres will be installed by the client prior to installation.
The simplest way is to use a bash script for Linux and possible bat/cmd files for Windows, though that is not ideal. Are there any libraries available to accomplish something like this?
install4j can be used to let users install applications. The installation package will contain everything needed (application, JBoss, postgres). Furthermore, it has ant and maven tasks, too, and you can even allow the users to do some basic configuration on-the-fly.
The latest version of JBoss is OSGi based. Have you consider to use this solution ?
If JBoss and Postgres are already preinstalled and configured by users as they wish then it would be very difficult to make a silver-bullet automatic installer that takes into account and correctly handles whatever incompatibilities it can face in real life.
Maybe a detailed install instruction would be enough. Especially for advanced users. For the others - bundle some diagnoctic scripts in case they face problem.
Also consider using liquibase to do automatic database initialization and migration on application's startup. This would greatly simplify the rest of install procedure: just check deps, make datasource and deploy app.
I'm a .NET developer looking do some research on my own time to better familiarize myself with Linux and Java (e.g JSP and Servlets).
My plan is to install Linux on an old PC. Then, install and configure a web server capable of hosting JavaServer Pages and Servlets. I would like to create a small web site with dynamic content being pulled from a database. Again, this site is only intended to be used by me for research and testing.
I have very little experience with Linux and Java. Did a couple projects back in college, but that was over 8 years ago.
Below are the questions I have about configuring a test environment I can use for research and testing.
1) What version of Linux should I install on my old PC?
2) What web server should I install on my Linux machine that can be used to host JavaServer Pages and Servlets?
3) What database should I install on the Linux machine? Since I'm doing this for research, it would be nice to test with a DBMS that is commonly used in the real world.
Thanks,
Chris.
You can use Debian, Tomcat and MySQL.
Debian is a fairly common linux distribution and will work on almost every PC.
Tomcat is a simple servlet container. It's the best choice if the only thing you want to do is servlets and JSP.
MySQL is, well MySQL :)
If you do mind using Linux, you can use Ubuntu which is more user-friendly but not really recommended as a server (at least for the default version).
These applications/distributions are from the most used and with the most active communities.
Resources :
debian.org
tomcat.apache.org
mysql.com
ubuntu.com
Whichever you want :-) At work, for example, our Linux servers run Red Hat Enterprise Linux, which is loosely based on Fedora, so that might be a good distribution to use that might be similar to what you would experience in the 'real world'.
Tomcat or JBoss Application Server would be good app servers to start with. Tomcat is just a servlet container, whereas JBoss supports more of the Java EE technologies. That said, many organisations find that a 'lightweight' app server like Tomcat is perfectly adequate.
MySQL and PostgreSQL are both widely-used open source database servers.
I would install the latest Ubuntu. The most user friendly and should work on your old PC.
I would install Glassfish or JBoss. Glassfish comes with Oracle's Java EE and is the easiest to install. JBoss is more widely used in commercial settings. Better yet, install both and try it on both!
MySQL is easy to install on Linux machines. In fact it's usually installed by default by the distribution.
Good luck! Linux is a great learning experience and a lot of fun!
I'm not a specialist in linux distributions, but as webserver the apache tomcat would be the best choice, I think version 6. The database may be a mysql, but for professional usage with more functionality postgresql will be the best choice.
Slackware. You will get lots of different answers on what distribution to use, and a lot of it is personal preference. I always prefer Slackware for server installations, and install all my software from source. I think of Ubuntu and Redhat more as client/desktop installations. I don't like to rely on packages to keep my servers up-to-date.
Tomcat. You don't need J2EE. Tomcat will do the job nicely.
MySQL. It's quite standard and works well.
1) As you want, but I suggest you a Red-Hat (CentOs for example) or Debian (Ubuntu for example) based distribution. With respectively Yum/RPMs and Aptitude/Synaptic, it will be easier to install Java (even if it is not difficult on other distributions).
2) To serve JSP pages and execute servlets, I suggest you Tomcat. It is much easier to install/configure it than other webservers (JBoss, Websphere, Weblogic, etc.), and you won't need them in a first time (EJB, etc.)
3) As a database, you can use MySQL (very easy to install), or PostgreSQL, or Oracle Express Edition (not Open Source but Free... And Oracle is very often used on big projects). From a Java point of view, it will be very similar (JDBC/Hibernate access to database "hide" the specificity of DB)
I think you are starting in the wrong place.
1.
If you want to try out linux try out linux. You don't need to install it - just download a "live CD". I believe the latest Ubuntu installer comes on a live cd.
2.
If you want to try out java web development you don't need to set up a server just install eclipse for java ee and create a dynamic web project. Then just start developing. Try to find some tutorials, etc. Eclipse can even download a development tomcat from within the ide.
3.
For databases - why not just use the same database you use with .net? I am sure there will be a jdbc driver and the code you write shouldn't be that different from any other database.
I recently have a problem that my java code works perfectly ok on my local machine, however it just wouldn't work when I deploy it onto the web server, especially the DB part. The worst part is that the server is not my machine. So I had to come back and forth to check the versions of softwares, the db accounts, the settings, and so on...
I have to admit that I did not do a good job with the logging mechanism in the system. However as an newbie programmer with little experience, I had to accept my learning curves. Therefore, here comes a very general but important question:
According to your experience, where would it be most likely to go wrong when it is working perfectly on the development machine but totally surprises you on the production machine?
Thank you for sharing your experience.
The absolute number one cause of problems which occur in production but not in development is Environment.
Your production machine is, more likely than not, configured very differently from your development machine. You might be developing your Java application on a Windows PC whilst deploying to a Linux-based server, for example.
It's important to try and develop against the same applications and libraries as you'll be deploying to in production. Here's a quick checklist:
Ensure the JVM version you're using in development is the exact same one on the production machine (java -version).
Ensure the application server (e.g. Tomcat, Resin) is the same version in production as you're using in development.
Ensure the version of the database you're using is the same in production as in development.
Ensure the libraries (e.g. the database driver) installed on the production machine are the same versions as you're using in development.
Ensure the user has the correct access rights on the production server.
Of course you can't always get everything the same -- a lot of Linux servers now run in a 64-bit environment, whilst this isn't always the case (yet!) with standard developer machines. But, the rule still stands that if you can get your environments to match as closely as possible, you will minimise the chances of this sort of problem.
Ideally you would build a staging server (which can be a virtual machine, as opposed to a real server) which has exactly (or as close as possible to) the same environment as the production server.
If you can afford a staging server, the deployment process should be something like this:
Ensure application runs locally in development and ensure all unit and functional tests pass in development
Deploy to staging server. Ensure all tests pass.
Once happy, deploy to production
You're most likely running under a different user account. So the environment that you inherit as a developer will be vastly different from that a a production user (which is likely to be a very cut down environment). Your PATH/LD_LIBRARY_PATH (or Windows equivalents) will be different. Permissions will have changed etc. Plus the installed software will be different.
I would strongly recommend maintaining a test box and a test user account that is set up with the same software, permissions and environments as the production user. Otherwise you really can't guarantee anything. You really need to manage and control the production and test servers wrt. accounts/installed software etc. Your development box will always be different, but you need to be aware of the differences.
Finally a deployment sanity check is always a good idea. I usually implement a test URL that can be checked as soon as the app is deployed. It will perform database queries or whatever other key functions are required, and report unambiguously as to what's working/not working via a traffic light mechanism.
Specifically you can check all the configuration files (*.xml / *.properties) in your application and ensure that you are not hard coding any paths/variables in your app.
You should maintain different config files for each env. and verify the installation guide from env admin. (if exists)
Other than that versions of all softwares/dependency list etc as described by others.
A production machine will likely miss some of the libraries and tools you have on your development machine. Or there may be older versions of them. Under circumstances it may interfere with the normal software function.
Database connection situation may be different, meaning users and roles and access levels.
One common (albeit easy to detect) problem is conflicting libraries, especially if you're using Maven or Ivy for dependency management and don't double check all the managed dependencies at least once before deploying.
We've had numerous incompatible versions of logging frameworks and even Servlet/JSP API .jar:s a few times too many in our test deployment environment. Also it's always a good idea to check what the shared libraries folder of your tomcat/equivalent contains, we've had some database datasource class conflicts because someone had put postgre's jdbc jar to the shared folder and project came with its own jar for jdbc connectivity.
I always try to get an exact copy of the Server my product is running. After some apps and of course a lot of Bugs i vreated myself a List of common Bugs/Hints. Another Solution i tested for my last project was to get the running Software on that Server and try to configure it. Strange effects can happen with that^^
Last but not least..i always test my apps on different machines.
In my experience there is no definite answer to this question. Following are some of the issues I faced.
Automatic updates was not turned on in dev server (windows) and it was turned on in the production server(which in first place is wrong!). So one of my web application crached due to a patch applied.
Some batch jobs were running in the production app server which changed some data on which my application was using.
It is not me who does the deployment for my company so most of the time people who deploy miss some registry entries, or add wrong registry entries. Simple but very hard to detect (may be for me ;-) ) once I took hours to identify a space in one of the registry values. Now We have a very long release document which has all the details about all servers used by the application and there is a check list for "current release" which the engineers who deploy the application fill in.
Willl add more if I remeber any.
Beyond just a staging server another strategy for making sure the environments you deploy into are the same is to make sure they are set up automatically. That is you use a tool like Puppet to install all the dependencies that the server has and run your install process before every installation so that all the configuration is reset. That way you can ensure the configuration of the box is what you have set it to during the development process and have the configuration of the production environment in source control.