Rick DeBay

I have a class:

public class Foo
{
long ndc;
long largerNdc;
public long getLargerNdc()
{
return largerNdc;
}
public void setLargerNdc(byte b)
{
if ( b > 99 || b < 0 )
{
throw new IllegalArgumentException("Larger NDC suffix must be from 0 through 99");
}
largerNdc = (getNdc_9() * 100) + b;
}
public long getNdc_9()
{
return ndc / 100;
}
}

When I get the property descriptors, I get null for the write method:
propClass=long
writeMethod=null

Granted the 'byte' type of the setter is probably confusing Instrospector.getBeanInfo(), but I can't find anything in the API saying this could be a problem.

Originally posted by Nicholas Cheung:
The Interface can define to throw the RemoteException (in fact, any necessary exceptions), but the real class method does not necessary to throw such exception.

Nick

Correct, although I hate declaring something like that if I'm not going to throw it. Code should be self documenting, and the throws signature implies that it does something it doesn't.

I need to find a Wiki to set up for work. Since I'll probably be the one extending it, it needs to be J2EE. Content development should be easy for the non-computer literate.
I found a few, but I have no time to evaluate any of them (much less set it up...) so I'm asking in places that usually have good answers.
Does anyone have any experience or opinions on the matter?

Thanks, Rick DeBay

I wasn't getting any answers in the Bunkhouse Porch, so here's a link:
Bunkhouse Porch common interface question

The InitialContext returned to a client from the JBoss naming service contains entries for all the EJBs, services (such as topic and queue), etc. The name jdbc is not bound (I dumped the contents using list("java:/")).
When the InitialContext is obtained from within the container, jdbc is bound (lookups against java:/jdbc succeed).
The startup log shows it being bound here:

16:25:41,736 INFO [jdbc/FirebirdDS] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=NoTxCM,name=jdbc/FirebirdDS to JNDI name 'java:/jdbc/FirebirdDS'
16:25:41,746 INFO [jdbc/XA-Firebird-Rxs] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=TxCM,name=jdbc/XA-Firebird-Rxs to JNDI name 'java:/jdbc/XA-Firebird-Rxs'

Why isn't jdbc showing up outside the container, and how may I begin correcting it?

One answer I've gotten was that the java:/ namespace shouldn't be available outside the container, but I'm looking up and using EJBs from the client that way, and OC4J returned pooled connections the same way.

Page 86 lists a way for the compiler to enforce that the stub and bean both contain the same methods. But the methods for EJBObject should throw RemoteException, and the bean methods shouldn't.
How can this be resolved?

Page 86 lists a way for the compiler to enforce that the stub and bean both contain the same methods. But the methods for EJBObject should throw RemoteException, and the bean methods shouldn't.
How can this be resolved?

Connections in the pool randomly die overnight. Stack traces show that for some reason, the evermind driver is being used even though the MySql connection pool is specified.
Also, the evermind connection pool is saying connections aren't being closed, and the stack trace shows they're being allocated by entity beans that are definitely not left hanging around.
Has anyone seen this problem?
<data-sources> <data-source class="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource" name="SQLServerDSCore" location="jdbc/SQLServerDSCore" xa-location="jdbc/xa/SQLServerXACore" ejb-location="jdbc/SQLServerDSCore" connection-driver="com.mysql.jdbc.Driver" min-connections="5" username="xxx" password="xxx" staleness-timeout="3600" alive-poll-query="SELECT 1 FROM medispan" url="jdbc:mysql://1.2.3.4:3306/dbo?autoReconnect=true&autoReconnectForPools=true&cachePrepStmts=true&is-connection-validation-required=true" inactivity-timeout="30" > <property name="autoReconnect" value="true"/> <property name="autoReconnectForPools" value="true"/> <property name="is-connection-validation-required" value="true"/> <property name="cachePrepStmts" value="true"/> </data-source>

Connections in the pool randomly die overnight. Stack traces show that for some reason, the evermind driver is being used even though the MySql connection pool is specified.
Also, the evermind connection pool is saying connections aren't being closed, and the stack trace shows they're being allocated by entity beans that are definitely not left hanging around.
Has anyone seen this problem?
<data-sources> <data-source class="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource" name="SQLServerDSCore" location="jdbc/SQLServerDSCore" xa-location="jdbc/xa/SQLServerXACore" ejb-location="jdbc/SQLServerDSCore" connection-driver="com.mysql.jdbc.Driver" min-connections="5" username="xxx" password="xxx" staleness-timeout="3600" alive-poll-query="SELECT 1 FROM medispan" url="jdbc:mysql://1.2.3.4:3306/dbo?autoReconnect=true&autoReconnectForPools=true&cachePrepStmts=true&is-connection-validation-required=true" inactivity-timeout="30" > <property name="autoReconnect" value="true"/> <property name="autoReconnectForPools" value="true"/> <property name="is-connection-validation-required" value="true"/> <property name="cachePrepStmts" value="true"/> </data-source>

The filter requires parameters to be set correctly, so inside init() if the parameters are incorrect or missing, I throw the exception. I was hoping that the container would continue without the filter. But I guess it makes more sense that it wouldn't.

If an implementation of javax.servlet.Filter.init() throws javax.servlet.UnavailableException(), shouldn't the container not add the filter to the FilterChain? I'm getting an HTTP 503 error from OC4J in this case.

I'm referring to code that looks like:

class FooSessionBean { MyEntity myEntity; public void bar() { myEntity = someHome.findByPrimaryKey(someKey); // now do stuff with myEntity } }

The variable myEntity is created and just hangs around, not getting garbage collected unless the session bean is collected, or another call to bar() on the same bean reassigns the variable. And no, I have no idea why it was coded that way.

Thanks. I wrote such a cache when I started working with EJBs a few months ago, but I just assumed they were thread safe.

Thanks for the quick reply. I ask because I've inherited some code that doesn't clean up anything, and I have a fair amount of work ahead of me and want to make sure I don't try to fix anything that doesn't need immediate fixing.
I'm going to get rid of the persistent EJBObjects, they seem to be causing stale database connections.

Are home objects thread safe? I'd like to look them up only once and then cache them. Obviously this won't work if multiple threads can't use them at the same time.