Lars Vonk

Hello Robin,

You can deploy an EAR file in the test environment by using the admin console. To start the admin console, start the server and right click on "Run administrative console". (If this option is disabled then first go to your server configuration, go the the configuration tabpage and select "Enable administration console". You must restart the server after this action.)
When you clicked "Run administrative console", the administration console appears, optionally fill in a userid and hit OK.
Now you are in your the admin console and via "Applications - Install new Application" you should be able to deploy your application by just using an EAR file......

If it doesnot work make sure you install all available fixpacks/updates for both WSAD and the WSAS.

Hopes this works for you.
Lars

Okay you were just one minute earlier.... :-)

Hello David,

are you behind a firewall or so? Because in your DOCTYPE you are reffering to a DTD that will be retrieved from the internet:

<?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE hibernate-configuration PUBLIC<br /> "-//Hibernate/Hibernate Configuration DTD 3.0//EN"<br /> "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

It will try to get the http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd. Change the URL to hibernate-configuration-3.0.dtd and put the DTD in the same directory as your hibernate config file. This will probably work.

Lars

Hello Mark,

Does setting the logging level change the classpath, or need more in the classpath that not changing the logging level?

I am not sure if I understand your question correctly but you don't have to change your classpath if you change your logging level using log4j.

Maybe you can check the dependencies for the ehcache.jar:
According to the ehcache docs you need commons-logging when using jdk1.4.
If you are using jdk1.3 you need commons-collections, version 2.1 and Apache xerces (xml-apis.jar and xercesImpl.jar), version 2.5.
I know these jars are all marked are required in the _README.txt but maybe its worth double checking.

Lars

Hello Kristof,

I did some more research and maybe found something interesting information concerning the SimpleNativeJdbcExtractor you use as nativeJdbcExtractor.
In the javadocs of the SimpleNativeJdbcExtractor it says:

This extractor should work with any pool that does not wrap DatabaseMetaData, and will also work with any plain JDBC driver. Note that a pool can still wrap Statements, PreparedStatements, etc: The only requirement of this extractor is that java.sql.DatabaseMetaData does not get wrapped, returning the native Connection of the JDBC driver on metaData.getConnection().

The 'interesting information' here is the fact that it states that if you want to use this class the java.sql.DatabaseMetaData does not get wrapped and returns the native Connection of the JDBC driver on metaData.getConnection().
In your case it apparently doesn't because it is returning null after invoking the getMetaData().getConnection() in the method doGetNativeConnection of the class SimpleNativeJdbcExtractor. If you look into this method you'll see the DEBUG statement 'Returning native Connection [null] for given ....' being called there.
Why the WebLogicNativeJdbcExtractor failes, I do not know (I have never worked with Weblogic). But my guess (and I am just guessing here...) is that it is on the same point (also the method doGetNativeConnection of the class WebLogicNativeJdbcExtractor. What I find strange in the exception trace is that the figure 813 is in the name of the connection implementation class of Weblogic.
java.io.NotSerializableException: oracle.jdbc.driver.LogicalConnection] at weblogic.jdbc.rmi.internal.ConnectionImpl_weblogic_jdbc_wrapper_JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection_[B]813[/B]_WLStub.getVendorConnection(Unknown Source)
Maybe this is refering to an older Oracle version 8.1.3? Maybe there is an older oracle driver jar/zip or something like that in the classpath or libpath, or maybe the jdbc/native drivers of weblogic need to be upgraded?

Good luck!

Thanks for replying Paul. I agree with you that most of the one-to-many association can be described as parent-child, although I cannot say I find the 'stand-alone' version an unasual scenario. Thanks again.

Hello Ruud,

Yes you are right, if your webcontainer and EJB container run in the same JVM you can use local interfacing.
In WAS 5 each application server has it own JVM. So if your web container and ejb container are in the same application server they are in the same JVM.
This also means that if you have multiple applications deployed in the same application server they also run in the same JVM.

Check out this redbook http://www.redbooks.ibm.com/redbooks/SG246195/ for more information about the websphere application server.

Regards,
Lars

Hello,

The Hibernate reference Documentation 3.0.5 states in paragraph 8.2.3 that:

A unidirectional one-to-many association on a foreign key is a very unusual case, and is not really recommended.

Does anyone know why this is considered an unusual case (I have seen it many times) and not recommended?
Regards,
Lars
[ August 21, 2005: Message edited by: Lars Vonk ]

Does the stacktrace of the ArrayIndexOutOfBounds gives you more information about where this exception occurs?
Maybe you can try to insert a LOB with the driver jar in a standalone application to verify it works without WebLogic, Hibernate and Spring.

What i find strange is that in your first post the cause of the Exception was

Caused by: weblogic.rmi.extensions.RemoteRuntimeException: Unexpected Exception - with nested exception:[java.rmi.MarshalException: error marshalling return; nested exception is: java.io.NotSerializableException: oracle.jdbc.driver.LogicalConnection]

I cannot find this class (oracle.jdbc.driver.LogicalConnection) in the jdbc driver jars, also a google search came up with nothing. Is this a generated class or so?

Regards,
Lars

Hello,

The code you received 12514 is an ORA message. It means that the servicename given in the connect descriptor is not known by the TNS listener. Verify you entered the right name in the connect descriptor. Also check that that name exists in your tnsnames.ora

Lars
[ August 18, 2005: Message edited by: Lars Vonk ]

Yes, Stan is right. Persistent messages are indeed an implementation detail of durable subscribtions.

Lars

Hello Kristoff,

Did you check that you have the correct oracle drivers for oracle 9 in your classpath? I believe this is classes12.zip for jdk1.2 and jdk1.3 and ojdbc14.jar for jdk1.4.

And do you really need an XADataSource? Because (maybe you already know this) this is only necessary when your transaction have to deal with multiple databases. Otherwise you should just use the non XA datasource.

Hope this helps you in someway,
Lars

Hello Shrinivas,

You have 2 kinds of Pub/Sub models: Durable and non-durable.

The durable model is actually as Stan told you earlier:
You use persistent messages in combination with durable subscribers when you want your messages retained even when your message consumer is not connected. This means that your messages are 'saved' untill your consumer connects again.

Non-durable means that if you use non-durable subscribers and non-persistent messages then a message sent to a consumer that is not connected is 'lost' for that consumer.

Hope this helps,
Lars

Thanks for your feedback Jeff, and thanks for sharing your findings.
In my opinion I don't think it's recommended (or 'legal') to interact with Transaction's directly in a container. But for the purpose your using it, and seeing your requirements, I would not worry about that. Good idea using the dynamic proxy. (It's starting to look like a nice framework )

Lars

Hello Oliver,

One way to solve it is this:

synchronized(myVector) {
//Iterate myVector here
}

This way your Vector cannot be modified while iterating over it.

Cheers,
Lars