Remember, there are at least those files that are potentially run:

• /etc/profile
• /etc/bash.bashrc
• /etc/bash_completion
• .profile
• .bash_profile
• .bashrc
• .bash_completion

Depending if you login interactively (getting a shell) or just running a command,some of these files are sourced.

Assumptions

We will take the case where:

• You login through SSH
• Or you change to a user using su
• You have an Ubuntu or Debian Linux machine

I suspect that Redhat/Fedora and others are not far away from these assumptions, but I have none to check…

There are in fact 6 scenarios

First Scenario : interactive shell with SSH

You login to a remote machine using SSH, getting a shell. This is the most current use of SSH.

With:

     ssh user@machine

You then get a shell.

The files that are sourced are:

• /etc/profile
• /etc/bash.bashrc
• .profile
• .bashrc
• /etc/bash_completion
• .bash_completion

That’s right only if there is no .bash_profile file in your HOME directory. Else the files sourced are:

• /etc/profile
• /etc/bash.bashrc
• .bash_profile

In fact, bash sources .bash_profile if it exists, else .bashrc

Note that

• /etc/bash.bashrc is sourced by /etc/profile if the shell is bash
• .bashrc is sourced by .profile
  
• /etc/bash_completion is in fact sourced by .bashrc (not bash itself directly)

So we could summarize this way.

When asking for an interactive shell, bash sources:

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Second scenario : running a command through SSH

You login to a remote machine using SSH, asking to run a command (no interactive shell)

     ssh user@machine "command to run" (Ex: ssh user@machine "ls /tmp")

The files that are sourced are:

• /etc/bash.bashrc
• .bashrc

Note that .bashrc is run in place of .bash_profile in this case.

Third scenario : getting an interactive shell using su -

You are logged with root and want to get a shell as another user:

     su - user

Note that the minus sign means that you want to source the config files for the target user.

The files that are sourced, are

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Fourth scenario : running a command using su -

You are logged with root and want to get a shell as another user:

     su - user -c "touch /tmp/file"

The files that are sourced, are

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Note that in this case, .bashrc is NOT run from /etc/profile since the shell is not interactve! (PS1 is not defined)

Fifth scenario : getting an interactive shell using su (without the minus sign)

You are logged with root and want to run a shell as another user:

     su user

Surprise! Even since you thought that the minus sign would source NO config files, the files that are sourced, are

• /etc/bash.bashrc
• .bashrc

Note that the sourced files are the same as running a command through SSH!

Sixth scenario : running a command using su (without the minus sign)

You are logged with root and want to run a shell as another user:

     su user -c "touch /tmp/file"

And this time, no surprise, the files that are sourced, are … NONE!

That’s exactly what the minus sign means. Become <user>, but don’t source its config files.

And the bonus scenario

What happens when you run a command from a crontab?

First, the default shell when running from a CRON, is /bin/sh. You can change this to bash putting:

     SHELL=/bin/bash

as the first line of your crontab file (crontab -e is your friend for this one).

Then sourced config files when the command is run are … NONE also.

Conclusion

Every time I need to run remote command on a machine or run a script as a user using su, I ask myself the same questions about those config files!

And we can see above that it’s not that clear which files are run when…

So now that’s done, for the posterity, on my blog so it should last for some time.

Comments of course welcome!

I work at « Etat de Vaud » in Switzerland and we have a lot of j2ee Servlet applications which run on Tomcat 6.0.x, that are multi-modules Maven projects.

My main concern is about development time, about the time the developer spend (or loose) compiling, packaging, deploying and running the application between 2 « tests »

Of course, we use unit tests extensively here, to develop Services, DAOs and other classes, but when it comes to pure web development (understand JSP) the « round-trip » time can become huge.

For example, on one of our project, when the developer change code in a controller (Spring MVC), it must

• Run maven to compile the code and package the war (~30-60 seconds)
• Copy the war to webapps of the Tomcat server (or have a symlink if on Linux)
• Then tomcat redeploy the application, including the Spring context (DAOs, Services, SessionFactory) which takes around 30 seconds

One code modification, round-trip time = ~1 minute…

Compare that to PHP, Ruby on Rails or even Grails which are quite instantaneous!

Multi-modules Maven projects

If you have single modules Maven projects, this is not a problem. Say we have:

myapp/webapp

which contains JSP and static contents:

myapp/webapp/css/...
myapp/webapp/images/...
myapp/webapp/WEB-INF/jsp/...

You have all your code in one location, say

myapp/src/main/java/...

then Eclipse can output compiled classes to

myapp/webapp/WEB-INF/classes/...

and have your libs in

myapp/webapp/WEB-INF/lib/...

Then you can start tomcat on

myapp/webapp/

And that’s all.

But when you have Multi-modules Maven projects, then you have Java source files in 2-3 places and Eclipse is unable to write all the compiled classes in one place (myapp/webapp/WEB-INF/classes)

Embedding Tomcat in Eclipse to the rescue!

The idea is to embedd Tomcat in Eclipse, so Tomcat is in the same JVM/ClassLoader of Eclipse and Tomcat « sees » all the projects, and also all the compiled classes and all the libs that are configured in Eclipse.

Step by step:

• Create a muli-modules Maven project that have, say, 2 modules : business and web (web depends on business)
• Import them in Eclipse using the Maven plugin for Eclipse (http://m2eclipse.codehaus.org/)
• You then have 3 projects in Eclipse: base, business and web
• At this point, the web project sees all the classes and libs from business and web
• Create a class to Embed Tomcat in Eclipse as I’ll show below
• Run your webapp using that class and you have instantaneous view of your modifications

Embedded Tomcat, with JNDI data sources

Tomcat 6.0.x is totally able to Embed itself in your code. The idea, is to create a java main() in the test part of the web project (in myapp/src/test/java). It’s important to create it in the test part, so it won’t be in your generated WAR, and the needed dependencies (catalina.jar, jsp-api, …) won’t be neither in your packaged WAR.

Step by step:

• Create a class that implements the Embedded part of Tomcat (See below)
• Debug it as Java Application (It’s important to « Run as Debug » so Eclipse is able to « feed » the webapp with the modified code without restarting the whole application)

Embedded class:

public class TomcatRunner {

 private static final Logger log = Logger.getLogger(TomcatRunner.class);

 private Embedded embedded;
 private String catalinaHome;
 private String pwd;

 public TomcatRunner(String contextPath, String webappDir, String contextXmlPath) throws Exception {

 // Current dir => ..../myapp/web
 final File file = new File(".");
 pwd = file.getCanonicalPath();

 // Create CATALINA_HOME
 File catalinaHomePath = new File(pwd+"/target/CATALINA_HOME");
 if (!catalinaHomePath.exists()) {
 Assert.isTrue(catalinaHomePath.mkdirs());
 }
 catalinaHome = catalinaHomePath.getCanonicalPath();

 // Create an embedded server
 embedded = new Embedded();
 embedded.setCatalinaHome(catalinaHome);

 // Create an engine
 final Engine engine = embedded.createEngine();
 engine.setDefaultHost("localhost");

 // Create a default virtual host
 final Host host = embedded.createHost("localhost", pwd /*Bas dir for webapps*/);
 engine.addChild(host);

 // The context of myapp
 // myapp/default-web.xmlis the default web.xml used for the context.
 // It contains the JSP and "static content" servlets. You can find that file in apache-tomcat-6.0.18/conf/web.xml
 final Context context = createContext(contextPath, pwd+"/"+webappDir, pwd+"/"+contextXmlPath, "myapp/default-web.xml");
 host.addChild(context);

 // Install the assembled container hierarchy
 embedded.addEngine(engine);

 // Assemble and install a default HTTP connector
 final Connector connector = embedded.createConnector(""/*Default to localhost*/, 8080/*Port to listen*/, false/*Secure*/);
 embedded.addConnector(connector);
 }

 public void start() throws Exception {
 // Start the embedded server
 embedded.start();
 }

 private static Context createContext(String path, String docBase, String contextFilePath, String defaultWebXmlPath) {
 log.debug("Creating context '" + path + "' with docBase '" + docBase + "'");

 StandardContext context = new StandardContext();

 context.setDocBase(docBase);
 context.setPath(path);

 ContextConfig config = new ContextConfig();
 config.setDefaultWebXml(defaultWebXmlPath);
 config.setCustomAuthenticators(null);
 context.addLifecycleListener(config);
 // This is the config of the JDNI datasources
 if (StringUtils.isNotBlank(contextFilePath)) {
 File configFile = new File(contextFilePath);
 context.setConfigFile(configFile.getAbsolutePath());
 }
 return context;
 }

}

Then you can use it with:

 // A global property configured for the server
 System.setProperty("myapp.appDir", "appDir/devel");

 TomcatRunner runner = new TomcatRunner("/my/app", "webapp", "webapp/META-INF/context.xml");
 runner.start();

And then start it as « Debug ». That’s it!

JNDI

If you have JNDI data sources, you can configure them in the file

webapp/META-INF/context.xml

Example of context.xml:

<Context debug="true" reloadable="true" crossContext="true" antiJARLocking="true">
   <Resource name="jdbc/myAppDataSource" auth="Container" type="javax.sql.DataSource"
     maxActive="100" maxIdle="30" maxWait="10000"
     validationQuery="select sysdate from dual"
     username="WEB_USER" password="pwd" driverClassName="oracle.jdbc.OracleDriver"
     url="jdbc:oracle:thin:@<server>:1521:orcl"/>
</Context>

Usage

The goal is to be able to modifiy static content, JSPs or java code and that it is used instantaneously without needing a restart or a manual operation.

To be able to use that Embedded tomcat thing, you need to start it as debug, then browse to http://localhost:8080/my/app

You should then be able to access your application, through the embedded tomcat.

Static content (CSS, images):

Say you modify myapp/webapp/css/myapp.css, the file is directly in the webapp folder so it is reloaded next time you load a page that use that CSS. Idem for images.

JSPs

If Tomcat is configured to recompile JSPs when they are modified (which is the default), then as soon as you modify a JSP, it’s recompiled the next time you access it.

Java code

This is the greatest part. If you modify java code in Eclipse, eclipse recompiles the java file to the corresponding .class, then also feed it to the debugger so the JVM sees the new version. (That works only if you « Run as Debug » from Eclipse)

So when you reload your page, the new class is used and the modified code is used. Magic!

Limitations

There is one limitation, which is not due to this setup, eclipse or Tomcat. It’s due to the fact that Java debugger can’t be feed a class that has « changed too much ». Changing too much means that as long as you change code in a method, that’s normally fine. But if you add/remove/rename a class, a class method or a class member, then the debugger is unable to feed it to the JVM through the debugger. Eclipse warns by saying: « Hot code replaced failed », saying that your modified code is not available in the JVM (the old code stays there) and that you should restart your application.

You then need to simply stop the TomcatRunner and restart it.

Another limitation is that if the modified classes was already run and loaded, then it won’t be reloaded before a server restart. One example, is if you have a class that set up some values in a Singleton, changing the singleton code won’t change the singleton already in memory. Idem for the spring context.

Conclusion

Using this setup change the round-trip time from ~60 seconds to instantaneous, which is great. Due to the limitations above, we must restart the webapp every 3-10 minutes depending which code we are changing, but that’s acceptable. And remember we use Unit tests for all development, we use that setup only for pure web development (JSPs)

References:

http://www.onjava.com/pub/a/onjava/2002/04/03/tomcat.html

http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/startup/Embedded.html

Fini le site jesc.ch de mon travail indépendant et vive mon (notre) blog sur wordpress.

Ce changement est important parce qu’li met un terme à mon travail indépendant, terminé effectivement en décembre 2006 sur burn-out, mais le site restait. Il est maintenant down, voila, ça c’est fait, comme dirait brice.

Pour votre info, JeSC ca voulait dire « Jean-Eric Software et Consulting »

Et maintenant ça veut tout simplement dire: « Jean-Eric et Sara Cuendet »

A bientot donc pour de nouvelles aventures.

Intel made several families of microprocessors:
- Pentium
- Pentium II
- Pentium 3
- Pentium 4
- Pentium M (for laptops, also known as Centrino)
- Intel Core
- Intel Core 2

These are families, based on different micro-architectures.
In 2000, Intel introduced the new P4, a completely new processor family, with a new micro-architecture called NetBurst. It was designed to be able to go very high in frequency. At the expense of a bad instruction/cycle rate. This had also the drawback that it used a lot of power, since the frequency was very high (as high as 4GHz). And also become very hot, needing BIG fans to cool it.

In parallel, Intel developped its Pentium 3 processor into the Pentium M, known as Centrino, for laptops. The P4 used too much power for laptops, so Intel used that good old P3 and redesigned it to be very power efficient.

Intel also has the Xeon family of processors, used in servers. It is based on the P4 design. The differences between a P4 and a P4 Xeon is the quantity of cache memory on the processor chip and the ability to be run as multi-processors.

Then Intel unveiled the « Intel Core » processors, which is a Pentium-M (aka Centrino) redesigned to be more powerful. They were used in laptops, but also in desktops, for not too demanding applications. Apple Intel based Macs use the « Intel Core » processors. These processors are available in 2 flavors:
- Intel Core Solo : 1 processor
- Intel Core Duo : 2 processors
The DUO is just like a Dual-processor computer (it’s like having 2 « Core Solo » processors), but the 2 processors are in the same chip (In the same piece of silicon).

So Intel has 3 lines of processors:
- Desktops (P4)
- Laptops (Centrino)
- Servers (P4 Xeon)

Since 3 years, AMD, the other microprocessor firm, has the lead in performance over Intel, with its Opteron and Athlon64 series of processors. They are more powerful, and use less power to do it. That’s all that companies want for servers. Less power means less climatisation and smaller power bill at the end of month! And that’s also all that gamers want for best FPS in games! So AMD got +16% market share from Intel last year only!
AMD has the lead in servers and desktops computers, but are quite insignifiant in laptops.

But now, Intel strikes back! They unveil the « Core 2″ microarchitecture. This is not the same as « Core Duo », this is a new architecture based on the « Intel Core ». So you have:
Intel Core
Core Solo (One « Intel core » processor)
Core Duo (Two « Intel core » processors)
Intel Core 2
Core 2 Solo (One « Intel core 2″ processor)
Core 2 Duo (Two « Intel core 2″ processors)

These processors are designed to get the lead back from AMD. After the first benchmarks (based on Games like Quake or UnrealTournament), they seem to be around 30% faster that AMD Athlon64 at the same clock speed! Done by independent reviewers of course:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2795 http://reviews.cnet.com/Intel_Core_2_Duo_E6700/4505-3086_7-31973836.html
http://www.tomshardware.com/2006/07/14/core2_duo_knocks_out_athlon_64/

« Core 2″ processors are declined in 3 versions:
- Laptops (Code name Merom)
- Desktops (Code name Conroe)
- Servers (Code name Woodcrest)
They are all based on « Core 2″ architecture, and they all come in Solo or Duo versions (which is 1 or 2 processors on the same chip). Core 2 processors are available now for Desktops and Servers, while laptops ones will arrive in september.

Voila. The goal of this (lengthy) mail was to explain that « Core 2″ and « Core Duo » are not the same thing as a lot of people tend to believe.

See you.

Jean-Eric Cuendet
Perso : http://www.jesc.ch