Joshua Davis

+ Follow
since Nov 26, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joshua Davis

Jelle Klap wrote:Right, so you want to do a look-up of an EJB packaged inside the market-cadastro-ejb.jar archive from a class inside the market-web.war that's part of the same .ear deployment.
A local JNDI lookup should work in that case using the java:app namespace, but I would take a different approach altogether.
Instead of manually performing a look-up that couples your code to JNDI, in my opinion, you'd be better of using dependency injection and have JBoss figure out how to obtain a reference to the EJB (via JNDI somwhere in the background). Have a look at the @EJB and @Inject annotations

Jelle is right. Using EJBs deployed in an EAR from the WAR deployed in the same EAR is best done by injection. Without knowing why you're doing a JNDI lookup, or what kind of object needs the EJB, it's really hard to offer any more help.

@Inject is a CDI annotation. If you want to use that, you'll have to set up CDI in your application and learn to use it (I highly recommend this). I don't see enough information about the packaging to tell.

@EJB is an EJB3 annotation. This should work if your application is packaged properly. However, I've noticed that your EJB is stateful. That can change things a little because the container needs to know more about the state of the thing that is injecting the EJB.

Either way, most of the time you should not need to do any JNDI lookups inside a JEE6 application.
9 years ago

Jay Dilla wrote:

Here are a few solutions that are a little more robust:

this is not working for me
what type of shell does this work with?

It's bash. I've tested this on various Linux distros and Cygwin.

What, exactly is the problem you're having?
9 years ago
Fair enough, and thanks reading!
10 years ago

Tim Holloway wrote:The easy way to do it is to note that a Java properties file has the same format as a basic shell script.

However, there's a trick to it. If you just run the properties file like so:


The assignments will be made at the sub-level, then discarded when the properties file (script) ends execution.

So to get the properties in a calling script, you need to use the "source" command:


Note that the space after the initial dot is very important!

To reference shell variable assignments, you use the "$" to indicate variable substitution.

So, to put it all together:

This solution is good because it's simple, but it will only work if you have Java properties file that doesn't have any property names or values that have special characters (to shell) in them. For example, if there is a property with a '.' in the name, then this solution won't work. That's the case for most Java properties files I've used, especially those used with ANT.

Here is a properties file that Java can read, but bash can't:

The second property is going to cause problems because it has a dot in the name, as well as having spaces in the value. Java and ANT can read this in just fine, but bash can't:

Here are a few solutions that are a little more robust:

10 years ago