2

A project with the following technologies and components has surfaced: to up a Web stack solution initially composed with Ubuntu, JDK, JBoss, Spring MVC 3.0+, and MySQL.

In planning this project, I have been struggling to find answers to the following questions for first steps, best practices, and sequence:

1) Does the JDK (and JBoss) need to be installed as ‘root’? (I have seen articles that mention it is not a good idea to operate in root unless absolutely necessary due to the fatal consequences.)

2) Does Ubuntu need to be installed as a Server in order to accomplish all this, or can it also be installed as a Desktop? I have not been able to determine if having a JBoss and MySQL need to be installed on top of Linux as a server.

3) Does Maven need to be used within Spring STS in order to get JBoss, and MySQL (and in the future Hibernate) to work successfully together?

4) My intent is to install in this order: a) Ubuntu -> b) Java -> c) JBoss -> d) Spring STS -> and e) MySQL. Are there any blatant conflicts in this sequence?

David
  • 37
  • 1
  • 1
  • 4

2 Answers2

0
  1. Installed as root, why not? Run as root, probably not a good idea.
  2. If you want a desktop, install a desktop distrib. If you want a server, install a server distrib. This doesn't change what can and can't be run in the OS. It only changes what is installed by default.
  3. Maven is a build tool. JBoss doesn't care how you build your app. All it cares about is if the application you deploy is a valid Java EE application.
  4. No. You need an OS, so Ubuntu must come first. JBoss and (AFAIK) Spring STS need a JRE to run, as they're Java applications, so Java should be installed before them. MySQL is independent of JBoss, STS and Java, so you can install it whenever you want.

Note that if you're struggling just with this installation part, be prepared to suffer with the rest. Building a Java EE webapp is not a piece of cake, and you should probably find some experienced developer to help you, as it seems you're only beginning with Java.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Thank you JB Nizet. I appreciate your reply. I was told this may take a while, but also told it was not 'rocket-science'. Confidence is low, but ambition and morale are high. I only need to focus and achieve. What makes this so challenging? Does it take a lot of custom code? I am searching on the Web, and realize it is not very clear cut. Humbly, David. – David Apr 18 '13 at 21:49
  • It's not rocket science, but it takes a whole lot of time,patience, trials and errors, to learn all the pieces and to choose the right paths : HTTP, HTML, CSS, JavaScript, Java, OO design, Servlet, JSP, Spring MVC, dependency injection, Java EE application structure, EJBs, JPA, JPQL, JBoss configuration, SQL, database design, testing and mocking frameworks. You'll need to learn all this, if you don't know them yet. Good luck: it's a long, but interesting journey. – JB Nizet Apr 18 '13 at 21:54
  • Seems I will be busy. I need some stones and a slingshot. This is the new Goliath in my life. Thank you JB Nizet. – David Apr 18 '13 at 22:04
  • Running as Root is not "probably not a good idea" -- it's a horribly terrible idea. Do not run anything as root on a server! Especially public internet facing servers, and double especially on public internet facing applications (such as your JBoss will end up being). This is just asking for someone to pwn your system! And they will! – SnakeDoc Apr 18 '13 at 22:14
  • @SnakeDoc: agreed. It was something like an understatement. OTOH, I assumed the question was or a development machine (since STS is installed). Still not a good idea, but not as bad as on a production machine. – JB Nizet Apr 18 '13 at 22:18
  • @JBNizet I concur - on my dev systems (and believe my, I have a lot of them) I almost always end up running crap as root, purely out of sys admin laziness. In production though, absolutely not. – SnakeDoc Apr 18 '13 at 22:23
0

JBoss will require Java (recommend Java 7) before it will do anything. I don't think it really "installs" per-say, but rather just unpacks to some directory (even if you install from the package manager, it just really extracts itself). I question your need for Spring since JBoss and Java EE in general really does everything Spring does, and better now-a-days. Unless you have a specific requirement for Spring, I'd question this extra dependency.

For linux - in a high level, any OS can be a "server", all it needs is to be capable of serving things (web pages, ssh connections, etc). In M$ world, different "levels" of the OS have been specially designed based on anticipated task/workload. So for example, while Windows 7 can indeed run as a server, it was not designed for it and therefore may not be optimized or include helper utilities and tools to make life easier as a sys admin of the system. Windows Server on the other hand does include all the "normal" server tools and lots of goodies to make maintaining and setting the server up easier.

In linux land, this is no such thing. Linux is the kernel that talks back and forth with the bare metal, etc... and Distro makers will take that and build an OS around the kernel, basically just attaching any packages they feel their distro needs... such as wget, or cat, or any other standard userland apps, plus some non-standard such as mysql or java or whatever they want.

Now, some distributions of linux will tailor themselves at being "server" ready, while others will tailor themselves at being a desktop OS. The difference? It's really just whatever default packages the distribution maker decides to include or not. For example, the overwhelming majority of linux servers are run completely headless, and therefore there is absolutely no reason to have X11 and a huge bloated GUI environment installed and/or running on that system... it's pointless. Also, an "average joe" user does not need MySQL installed by default on his desktop system since it would only bloat his system and he likely won't ever use it.

So basically it comes down to default installed packages.

Some linux server distros take this further and exercise extreme caution when making updates, patches, or new releases in the name of stability and security, while on the other hand most desktop distros are more haphazard with their updates since if it breaks a home users web browser, it's probably not a huge deal... but if a server update breaks the webserver application stack, now that's a serious problem.

So you'll find server OS's like CentOS (based on upstream RHEL) are extremely slow to bring in the "latest and greatest" features that desktop OS's get early on. Their goal is high security and long term stability.

Now, for Ubuntu. While I certainty know a lot of folks run Ubuntu as their server OS choice (partly due to Amazon choosing Ubuntu as the default linux VM for their ECS cloud), but I'd really question this. Ubuntu is not focused on being a server. It's focused on being a great all-around desktop oriented OS. Yes the LTS version is meant for long term stability, but it's based out of a desktop OS, so it's still not the focus.

IMHO, I'd go with CentOS because it's free and completely binary compatible version of RHEL - and RHEL is the de-facto standard for enterprise-grade linux servers. Be aware though, the RHEL way of doing things is a bit different than the debian way -- so there is no apt-get, you must use yum install instead. Startup scripts are different and some ways of doing things are different, but really, once you know linux, you know linux.

EDIT: Also check into Jenkins - its a free opensource continuous integration system that runs on JBoss or Tomcat or any other container, and can automagically pull your code from a repo (github, git, svn, etc) and compile/package it then push it to live deployment. You setup your ANT or Maven build scripts, and it can kick off on a schedule or however you configure it.

EDIT EDIT: I'd also recommend using OpenJDK -- as it's likely included in your package manager (for just about every disto) and will be more updated than the oracle version if it's in your package manager too. I've found most "server" distros will have OpenJDK 7 while only having Oracle java 6 in their package managers. Also, installing it via the package manager will enable you to keep it updated a ton easier.

SnakeDoc
  • 13,611
  • 17
  • 65
  • 97
  • Thank you SnakeDoc. This is interesting insight on the server aspect, and items to really think about. What you offer here makes sense. Regarding Spring, it is requested for this project - I am mainly familiar with the Eclipse-ish aspect of the environment. Including Spring seems to add an additional learning curve component; the thought towards the future is that it will make things easier. I say that not as an expert, but only hearing it from so-called experts. – David Apr 18 '13 at 22:19
  • Hmm... I have never used Spring myself, and I'm a newbie to Java EE (I do a lot of Java development, just not EE oriented), but from what I hear/gather, Spring was originally meant as a replacement for Java EE back in the days where Java EE was downright terrible. Java EE has come a long long ways since then, with Oracle's own container (GlassFish) including most of the default Java EE functionality. JBoss is just a different implementation of the same Java EE framework. Java EE is a standard, but the implementation is up to the vendor (Red Hat in the case of JBoss). – SnakeDoc Apr 18 '13 at 22:26
  • I could be way off on Spring though, so I'd do some homework on that before just believing someone else's word on it. If it really will help in any way, go for it. ***speaking from the mentality of more dependencies == more trouble – SnakeDoc Apr 18 '13 at 22:27
  • When you refer to Java EE, I am trying to imagine what then actually brings all the components together in say, a framework, if you will? (For lack of better/unknown terminology.) – David Apr 18 '13 at 22:34
  • yes... Java EE is a hard thing to wrap your head around. Java EE is a standard put forth by some governing body, but they do not specify how to implement/create the framework, they only specify what it must do and be able to do in order to be considered a full Java EE implementation. So this leaves vendors to be able to come up with their own competing Java EE frameworks, such as JBoss or GlassFish (there are a ton of other options). Your Java EE code needs the Java EE environment in order to be able to execute. This is where the application servers come in -- – SnakeDoc Apr 18 '13 at 22:42
  • Something like JBoss will "host" your application code and allow it to hook into the internal Java EE libraries and framework that JBoss provides. Basically without a Java EE container of some sort, your Java EE code will do nothing. I had this very same question myself -- here's my thread on SO detailing out some great answers - http://stackoverflow.com/questions/15774924/just-what-is-java-ee-really – SnakeDoc Apr 18 '13 at 22:44