Chris Adkin

Greenhorn
+ Follow
since Aug 01, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Adkin

Fixed it !!!

I found: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB.

If the standlone client is to be run on the same machine as the app server, the client code is as simple as:-

package www.client.com;

import javax.naming.Context;
import javax.naming.InitialContext;
import www.async.com.AsyncBeanRemote;

//import www.async.com.AsyncBean;

public class Client {
public static void main(String[] args) {
try {
Context ctx = new InitialContext();
@SuppressWarnings("unused")
AsyncBeanRemote asyncBean = (AsyncBeanRemote)ctx.lookup("AsyncEJB");
} catch (Exception e) {
e.printStackTrace();
}
}
}

You only have to mess around with initial content factories, IIOP ports etc, if the client is genuinely remote. Also, the glass fish jar: appserv-rt.jar needs to be added to the build path.

Chris
14 years ago
I have a simple stand alone Java client, the code for which is:-

package www.client.com;

import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import www.async.com.AsyncBean;

public class Client {
public static void main(String[] args) {
try {
Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "127.0.0.1");
jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
Context ctx = new InitialContext(jndiProps);
@SuppressWarnings("unused")
AsyncBean mySessionBean = (AsyncBean)ctx.lookup("AsyncEJB");
} catch (Exception e) {
e.printStackTrace();
}
}
}

This invokes the following stateless bean:-

package www.async.com;

import javax.ejb.Stateless;

/**
* Session Bean implementation class AsyncBean
*/
@Stateless(mappedName="AsyncEJB")
public class AsyncBean implements AsyncBeanRemote, AsyncBeanLocal {

/**
* Default constructor.
*/
public AsyncBean() {
// TODO Auto-generated constructor stub
}

public void doSomething(String message) {
System.out.println(message);
}

}

The remote interface for this is:-

package www.async.com;
import javax.ejb.Remote;

@Remote
public interface AsyncBeanRemote {
public void doSomething(String message);
}

My understaning with JEE6 is that the mapping information provided with the @Stateless annotation should create a JNDI reference of AsyncBean for me, although I should not need any deployment descriptors, this is my sun-ejb-jar.xml file:-

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>AsyncBean</ejb-name>
<jndi-name>AsyncEJB</jndi-name>
</ejb>
</enterprise-beans>
</sun-ejb-jar>


When I run the client I get:-

ava.lang.NullPointerException
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:297)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:271)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:430)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at www.client.com.Client.main(Client.java:19)
javax.naming.NamingException: Lookup failed for 'AsyncEJB' in SerialContext targetHost=127.0.0.1,targetPort=3700 [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext targetHost=127.0.0.1,targetPort=3700 [Root exception is java.lang.NullPointerException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at www.client.com.Client.main(Client.java:19)
Caused by: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext targetHost=127.0.0.1,targetPort=3700 [Root exception is java.lang.NullPointerException]
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:276)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:430)
... 2 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:297)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:271)
... 3 more

My initial thoughts are that the lookup is not finding the JNDI reference for my bean, or the reference I'm providing is incorrect. I would have posted this on a Sun forum, if it were not for the fact that some moron appears to have completely spammed it. Can someone advise as to why my client is not working.
14 years ago
I want to be able to take files (typically flat files) although I may later on need to use XML, validate these files based on some simple validation rules and ultimately load the transalated data into a database.
Not the most complicated stuff in the world, but I can't believe that there isn't a framework somewhere for simplifying the development of such a thing.

Chris
15 years ago
Can someone recommend to me a framework or anything off the shelf that can take some of the hand cranking out of developing some data mapping software. I trawled the apache web site half expecting someone working on one of their projects to have produced something I could reuse, unfortunately this doesn't appear to be the case.

Chris
15 years ago
Katrina,

I think someone else has already mentioned this, but it depends on what sort of data is retrieved from the database, if this is standing / configuration data and the numbers of logical reads this results in is a significant total of the total number of logical reads that your app performs, then you most definitely need to look at caching this data. If the data is so large that it cannot be cached in the heap without causing serialization or garbage collection collection issues you might want to look at products specifically designed for this sort of job such as Coherence or Gigaspace application fabric etc. Although you should not design or tune for performance goals that do no exist, a general rule of thumb is that accessing a database from any language damages performance, therefore you should make your queries as efficient as possible in terms of execution plans, in stead of going out to the database ten times to get data, see if you can do this using one query, batch queries together using the JDBCs batching features and consider database stored procedures.
16 years ago
Ernest - I've rectified my display name as per the guidelines.
16 years ago
I'd like to canvas peoples opinions on increasing the scalability of some software I'm working with, this is an EJB application using stateless session beans, bean managed persistence and a database as the hard store. One of the most performance critical elements of the software are a set of batch processes which at present process their work load on a job by job basis. We have identified that we could make this far more scalable if the EJB middle tier processed it's workloads in multiple jobs at a time and accessed the database in such a way that single queries could provide the data necessary for servicing multiple jobs. However, this approach would require a major re-write exercise. Although we are considering this, another approach would be to use some caching software such as Coherence or Giga Spaces application fabric to act as a read through / write through cache to the database. I was wondering if someone could provide me with the benefit of any experience they have when encountering a similar problem.
16 years ago