Could anyone educate me a big piture of the Amazon EC2 Unix instance? I would like to know how Tomcat works in an EC2 instance so that in the future I know how to reconfigure/customize it.
After I create/launch a new EC2 instance running with Tomcat server, everything seems to be well set up. It does not require additional configuration to have the Tomcat running and to deploy.
When I connect to my instance and walk through this UNIX server, I have no idea how the structure is designed. For example, where is Tomcat located and what is linking to the Tomcat so that from AWS managment console UI I can just start/stop the server with a few mouse clicks.
-
Please have me clarify if you found my statement unclear.
I have worked on linux version and in it you can find tomcat home directory(if prior included)
at /usr/share/tomcat .User can use putty to log in to that.
You might want to have a look here
Your best bet is to install Tomcat yourself, from the packages you can find at tomcat.apache.org. You can install it on any OS you want, on any flavor of machine you can launch within EC2. You'll also get patches more quickly than the distro maintainers can, the file layouts will make sense, and you can get all the help you need from the Tomcat community via their users' mailing list without having to first explain that you have no idea where Tomcat is installed, where the configuration files are, etc.
Do you really need point-and-click starting and stopping of Tomcat?
If you just want to deploy a web application into the AWS Magic, consider using Amazon Elastic Beanstalk. I haven't used it, but it if actually does what they claim it does, it's pretty magical.
I have no idea how the structure is designed. For example, where is Tomcat located and what is linking to the Tomcat
Assuming you're referring to Linux instance (again which Linux instance is another question)
but to answer what you want, run below commands on your instance:
# updatedb
# locate tomcat
The output of 2nd command will list you all the files/directories which has tomcat in their name. This way you will be able to figure out the location where Tomcat resides.
Related
I am new to IBM Bluemix, till now the application (Spring-Hibernate-Rest App) was running on Tomcat Apache server of Oracle ecosystem but because of some requirement changes now it needs to be deployed on Bluemix (IBM), How can I migrate the Apache server to Bluemix ? Please let me know if there is any documentation/blog which I can refer to. Thanks
Edit:
I got this link which helped a lot Liberty for java, still searching for a decent source.
IBM developerWorks hosts numerous tutorials for getting started on Bluemix, such as the following: http://www.ibm.com/developerworks/websphere/library/techarticles/1306_king/1306_king.html and http://www.ibm.com/developerworks/cloud/library/cl-move-java-app-hybrid-cloud-bluemix-trs/index.html. You can also ask product-related questions at the IBM forum: https://developer.ibm.com/answers/smart-spaces/12/bluemix.html. And as Kayaman points out, Google is always a good place to start.
As you probably figured out WebSphere Liberty is the Java app server in Bluemix.
There is a migration toolkit for migrating Tomcat to Liberty: http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/index.html
More about Liberty can be found on http://wasdev.net
Please take a look at this post about the migration from LAMP to Bluemix to have a good starting point.
You should also note that moving from an on-premise solution to a Cloud Foundry-based one requires some considerations regarding the local file system:
Local file system storage is short-lived. When an application instance crashes or stops, the resources assigned to that instance are reclaimed by the platform including any local disk changes made since the app started. When the instance is restarted, the application will start with a new disk image. Although your application can write local files while it is running, the files will disappear after the application restarts.
Instances of the same application do not share a local file system. Each application instance runs in its own isolated container. Thus if your application needs the data in the files to persist across application restarts, or the data needs to be shared across all running instances of the application, the local file system should not be used.
For this reason local file system should not be used.
Moreover, I think you should take a look at IBM Containers: A container is basically an application with all its dependencies, that is stored in a portable, platform-independent module (the container).
These should help. I know this is a couple of years late, but better late than never.
https://console.bluemix.net/docs/runtimes/tomcat/getting-started.html#getting_started
https://console.bluemix.net/docs/runtimes/tomcat/index.html#tomcat_runtime
https://github.com/IBM-Cloud/get-started-tomcat
The idea is to embed jboss AS7 to my project and add it to version control. Additionally to check the ability of start the server using mvn jboss:devserver (similar to how we run mvn appengine:devserver) So does it makes sense to write my own archtype ?
To my client this reduce lot of complexities so we can create our own jboss configuration to work with and the client's C# developers who will be going to work on java project development. find it easier to setup their local machines to run their changes locally. using similar command mentioned above.(mvn jboss:devserver) I wonder if anyone ever had this idea to work by?
I would probably look into using something like Puppet, instead of checking in all of JBoss.
Puppet uses a custom declarative language to define system configurations. Your puppet script would probably do the following:
Download JBoss from a public server, and unzip it to your desired location
Copy custom configuration files from your version control repo into JBoss
Copy your applications into JBoss
Puppet is a lot more powerful than the simple scenario that I have just described, but this scenario is a start.
With this solution, you would only end up checking in your puppet script and any custom JBoss configuration files you might need. In addition, I believe it would make your JBoss upgrade path a lot simpler, as you would only need to change the version of JBoss in your puppet script, and re-run puppet.
I think the ideal way to deal with situations like this is through packaging. If your client is deploying on some sort of unix server (i include Linux in that), then they are already using a package manager to manage system software on their servers. A package manager has the ability to install software, remove it, upgrade it, and, crucially for you, to install other packages on which some package depends.
You could therefore package JBoss, so that the package manager could install it, then package your application, specifying a dependency on JBoss. When the client installs your application package, JBoss will automatically be installed.
However, this plan only works if you client has a certain degree of infrastructure set up. They need to be using a system with a package manager. They need to have a way of managing package installation (a configuration management tool like Puppet, Chef, Ansible, or something vendor-proprietary is ideal for this). They need to be able to distribute custom packages inside their environment. They need to have either a way of accepting custom packages from you, or of accepting package build scripts and then building packages themselves.
In a server environment of any size, the sysadmins should and probably will have all this infrastructure anyway, because it's fundamental to managing a fleet of servers. But if your client doesn't have it, it may be too much effort to set up.
That said, the absolutely minimal version of this approach would be for you to send them the package files for the application and JBoss by email or SFTP or whatever, and then for the sysadmins to install them manually (eg with yum localinstall). This is not a lot better than having them install JBoss manually, but it's a step in the right direction.
I have a jar file which contains two Java classes. Using the javamail API I have developed these classes to read and edit my mail, then send to another mail id.
I am able to execute this through my standalone system via Eclipse. Now I want to host this jar file somewhere remotely so that it would fetch the data in real time and execute the job regularly. I have contacted couple of hosting sites and they are saying that they require a war file instead.
Does anyone have any suggestions to this problem?
To give you another point of view and to be constructive, I would go with embedding your jar into a war application and you get some things for free, the most important I think is that you gain a managed application lifecycle so with a standard web application context listener you can start and stop your program in a managed way. Besides you have more hosting options and it is less work.
Good luck with that.
As I don't know of any services specifically for plain execution of executables, your best bet is probably getting a cheap VPS. With some searching you can probably find one that would work for around $5 USD/month. For a single simple app you'd only need around 128MB of memory.
Pick one up, install Java (whatever Linux distro you get probably has OpenJDK in the repositories), copy your files over, and set up a cron job to run the executable at a set interval.
For easier administration, install something like webmin and use that to configure the cron job. The command would likely just be java -jar /path/to/my/App.jar, and you can use the web interface to configure the intervals for the command to be executed.
For an app like this, I would avoid anything related to a war file. You aren't making an application with a web interface (like a PHP app or some such) so it really wouldn't be appropriate. You would have to write some extra code to make it compatible with a container like Tomcat, and on top of that the memory requirements for running the application server would be a lot higher.
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 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.