Sometimes you need to pass some additional / contextual data to the called EJB method. Because it’s a contextual data you don’t want to end in changing signatures of all your EJB methods just to add a single or few such parameters. It is possible to add context data using the SessionContext object.
Recently, I’ve bumped into few posts on StackOverflow where people tend to compare container managed EntityManager instances (so the one injected by the container) by invoking EntityManager#toString() method. I’ve felt that it’s fundamentally wrong to compare EntityManager instances without knowing how they’re managed by the JPA provider or the Server Application. And what if this behaviour differs between Application Server vendors?
The JPA provider provides an implementation of EntityManager – that’s obvious. More interesting is that the Application Server is scanning all @PersistenceContext fields and wrapping these EntityManagers into its own class – a proxy – which delegates requests to the JPA provider’s EntityManager. Therefore, if you’re comparing results of toString() method of such EntityManagers, you can’t say about PersistenceContexts equality but rather about Server Application EntityManager equality.
Needless to say, an Application Server could use one proxy as an access point to different EntityManagers. Without knowing the internals, you’re not able to say how it will work and decide if your results are meaningful.
If you’ve cloned a GitHub repository from the original one and not from your forked version and you would like to change it, you can just edit the .git/config file in your project and change the URL of the origin remote:
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = VALUE_WHICH_SHOULD_BE_ADJUSTED
Simple, easy, and most importantly – it works.
You probably know that if you use BMT (Bean Managed Transactions) you can get information about current transaction status by using UserTransaction interface (which implementation can be fetched either by JNDI or using dependency injection) and executing it’s getStatus() method.
If you use CMT (Container Managed Transactions) you cannot use UserTransaction interface. Instead, you can manage your transaction through SessionContext interface. This interface gives you two places that hooks to the current transaction: setRollbackOnly(-) and getRollbackOnly().
But what if you would like to check the current transaction’s status?
Well, the first answer would be: think twice if you really need to do this.
The transaction is container managed, so get/setRollbackOnly(-) should be probably the most important methods for you.
However, if you still need to get some more detailed information about your CMT you can use the TransactionSynchronizationRegistry interface which (just like UserTransaction) can be fetched using JNDI or @Resource annotation:
@Resource TransactionSynchronizationRegistry txReg; txReg.getTransactionStatus();
Here you can find what the integer status returned by this method invocation means.
Once again Windows know exactly how to surprise me.
I’ve added entries to the Windows/System32/drivers/etc/hosts on my remote Windows 2008 Server. The entry was resolved properly as it could be tested from the command line (ping, telnet, etc.) but in IE and FF browsers it didn’t work.
DNS flushing, clearing browsers data or restart didn’t help a bit. It occurs that the IE had a proxy settings and apparently (when any proxy is set) it refuses to take hosts file under consideration. It affects not only IE but also the FF.
The solution was to remove the proxy setup in IE and from this moment the hosts file entries were resolved properly.
Just a note to myself – always check what classes are you importing in IDE, because if you see @Singleton in your class, it doesn’t mean it will work as a EJB Singleton. In my case it wasn’t referencing to javax.ejb.Singleton as I assumed, but com.sun.jersey.spi.resource.Singleton…
Wasted 2 hours of looking for the answer or issue in a glassfish-3.1 JIRA.
Did I mention I should always check the exact package of the imported class…?
If you want to execute a GUI based application on the remote server through SSH, you can achieve it quite easily using the ssh command. Just type
ssh -X username@server
The -X flag is used to define the DISPLAY environmental variable on the remote host, so each X11 executed application will be forwarded to your machine.
Recently I needed to find out what GNU/Linux a terminal-only server is using. The most obvious thing I could think of was to use:
uname -a
Unfortunately, it will return the kernel information only – no details about the distribution though.
The distribution info is located in a different file which is dependent on… the distribution itself. Check out the list of those filenames here.
As a majority of those files ends with “release” part, in most cases it should be enough to execute the following command:
cat /etc/*release
If you want to add your classes (or any other resources) to your ShrinkWrap archive to a non-root location, you can use the following:
@Deployment
public static JavaArchive deploy() {
// This is the classes and resources archive
JavaArchive ar;
ar = ShrinkWrap.create(JavaArchive.class, "resources.jar")
.addPackage(TestClass.class.getPackage());
/*
* The 'ar' archive will be added to the 'yourDir', so you'll
* end with test.jar#/yourDir/TestClassPackage/TestClass.class
*/
JavaArchive endArch;
endArch = ShrinkWrap.create(JavaArchive.class, "test.jar")
.merge(ar, "yourDir");
endArch.merge(ar, "yourDir");
return endArch;
}
When you create a deployment using Arquillian (great test runner for testing your Java EE code in the container of your choice: jBoss, Glassfish, OpenEJB, … either in embedded, managed or remote mode) remember that the name of the deployment archive file is the exact filename that will be executed in the container.
It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:
@Deployment
public static JavaArchive deploy() {
JavaArchive ar;
ar = ShrinkWrap.create(JavaArchive.class, "YourTests.war")
.addPackage(YourTestClass.class.getPackage());
return ar;
}
In this case you can end with ClassNotFoundException for YourTestClass.
Just use the archive format you need (in this case I needed a *.jar and not a *.war) as this does make a difference for the application server.
