Kodo 2.5.3 reversetutorial issue

Hi,
Using the finder I got more or less the same exception posted in my
preceding post on tutorial
D:\kodo-jdo-2.5.3\reversetutorial>java reversetutorial.Finder "true"
0 INFO [main] kodo.Runtime - Starting Kodo JDO version 2.5.3
(kodojdo-2.5.3-20030827-0055) with capabilities: [Enterprise Edition
Features
Evaluation License, Query Extensions, Performance Pack, Statement
Batching, Global Transactions, Developer Tools, Custom Database
Dictionaries,
ResultObjectProviders, Datacache Plug-in]
60 WARN [main] kodo.Runtime - WARNING: Kodo JDO Evaluation expires in
20 days. Please contact [email protected] for information on exte
Exception in thread "main" java.lang.NoClassDefFoundError: Article (wrong
name: reversetutorial/Article)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:217)
at serp.util.Strings.toClass(Strings.java:149)
at com.solarmetric.kodo.query.QueryImpl.toClass(QueryImpl.java:905)
at
com.solarmetric.kodo.query.QueryImpl.classForName(QueryImpl.java:854)
at
com.solarmetric.kodo.query.QueryImpl.bindClasses(QueryImpl.java:1032)
at
com.solarmetric.kodo.query.QueryImpl.bindVariableClasses(QueryImpl.java:1007)
at
com.solarmetric.kodo.query.QueryImpl.internalCompile(QueryImpl.java:471)
at
com.solarmetric.kodo.query.QueryImpl.executeQueryWithMap(QueryImpl.java:682)
at
com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:545)
at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:495)
at reversetutorial.Finder.main(Finder.java:32)
Thanks for a solution.
Best Regards
Bruno

Have you tried declaring the full class when declaring parameters or
variables?
i.e. instead of pm.declareParameter ("Animal food"), put in
pm.declareParameter ("reversetutorial.Animal food"))? Sorry if the code
doesn't line up. I don't have the tutorial handy.
Seznec wrote:
Hi,
Using the finder I got more or less the same exception posted in my
preceding post on tutorial
D:\kodo-jdo-2.5.3\reversetutorial>java reversetutorial.Finder "true"
0 INFO [main] kodo.Runtime - Starting Kodo JDO version 2.5.3
(kodojdo-2.5.3-20030827-0055) with capabilities: [Enterprise Edition
Features
Evaluation License, Query Extensions, Performance Pack, Statement
Batching, Global Transactions, Developer Tools, Custom Database
Dictionaries,
ResultObjectProviders, Datacache Plug-in]
60 WARN [main] kodo.Runtime - WARNING: Kodo JDO Evaluation expires in
20 days. Please contact [email protected] for information on exte
Exception in thread "main" java.lang.NoClassDefFoundError: Article (wrong
name: reversetutorial/Article)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:217)
at serp.util.Strings.toClass(Strings.java:149)
at com.solarmetric.kodo.query.QueryImpl.toClass(QueryImpl.java:905)
at
com.solarmetric.kodo.query.QueryImpl.classForName(QueryImpl.java:854)
at
com.solarmetric.kodo.query.QueryImpl.bindClasses(QueryImpl.java:1032)
at
com.solarmetric.kodo.query.QueryImpl.bindVariableClasses(QueryImpl.java:1007)
at
com.solarmetric.kodo.query.QueryImpl.internalCompile(QueryImpl.java:471)
at
com.solarmetric.kodo.query.QueryImpl.executeQueryWithMap(QueryImpl.java:682)
at
com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:545)
at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:495)
at reversetutorial.Finder.main(Finder.java:32)
Thanks for a solution.
Best Regards
Bruno
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

Similar Messages

KODO 4.2 - RACE condition issue

Hi All,
Recently we have migrated our application (DEM ap0467) to Weblogic 10.3 on 20 FEB 2010. Since then we are observing that there is a race condition occurring in the code where it is interacting with the database.
We use KODO for interacting with the database & this version of weblogic supports KODO 4.2, earlier to this we were using KODO 4.0.1. After upgrading KODO to become compatible with new version of Weblogic we have seen this acute problem in working of our application.
Whenever new trade comes in our application one process picks the data, inserts and commits it in database & publishes the message on internal queue, another MDB picks this msg from this queue & fires select query on the DB but this time it doesn't find the data from database & throws an exception giving error "... Not found in Database" but when we check the database, the data remains present there.
So our primary analysis says that the KODO is not flushing data to the database on time & it tries to keep this data in memory only & so in the next step the other process doesn't find the data in DB.
We tried using different properties of KODO to flush data to the DB as soon as it gets change such as
kodo.FlushBeforeQueries
but its not working.
So could you please give some pointers who know this issue or could help on KODO from oracle support ?

Try closing the entityManagerFactory itself before publishing the message. This will force Kodo to flush all data.
This is not the permanent solution since closing and opening the entityManagerFactory with each request is expensive But this will ensure the that its Kodo issue.

Kodo 3.0.0 beta now available

All,
Kodo JDO 3.0.0 beta 1 is now available at:
http://solarmetric.com/Software/beta/3.0.0/
Kodo JDO 3.0.0 is a major release, and contains significant changes to
properties, mapping information, and Kodo-specific APIs. To read more about
these, and to read about how to convert a Kodo 2 project to Kodo 3, see the
migration documentation at:
http://solarmetric.com/Software/beta/3.0.0/b1-docs/docs/kodo2.html
NOTE: the conversion is non-trivial, so we have provided a number of tools
to automate most of the process. So please read and obey the migration
documentation, which will guide you through the migration tool process.
For details about some of the major new features in this release, please
read the release notes at:
http://solarmetric.com/Software/beta/3.0.0/b1-docs/docs/relnotes.html
The full documentation is available online at:
http://solarmetric.com/Software/beta/3.0.0/b1-docs/docs/index.html
Some of the major new features include:
* New mapping system, providing more powerful and flexible mapping options.
* More configuration options for connection pooling.
* Configurable eager fetching of 1-1, 1-many and many-many relations.
Potentially reduces the number of database queries required when iterating
through an extent or query result and accessing relation fields of each
instance.
* More optimized SQL batching.
* Simplified package structure for Kodo-specific APIs.
Known issues:
* DB2, Informix, and Sybase do not fully pass our internal tests yet. Sybase
is close to passing, and DB2 and Informix probably work in many situations
as well, but they are not yet officially supported by this release.
* We have done only limited integration testing with application servers.
* Our IDE integration components are not included in this release.
As usual, please discuss any issues, desires, etc. on the beta newsgroup:
news://news.solarmetric.com/solarmetric.kodo.beta
Enjoy,
- Greg
Greg Campbell
SolarMetric, Inc.

1. I can't see any standalone GUI tool to do mapping tasks, as you have
ever announced.The GUI will have its own beta program and release schedule.
2. the file : <kodo3.0>/samples/jsp/build.xml has a line wrong:
<fileset dir="../../../lib/">
should be:
<fileset dir="../../lib/">Thanks!

(Kodo 4.1); DELETE issued even with @ForeignKey cascade delete?

I'm wondering if anyone has seen this.
I'm using Kodo 4.1, and MySQL, and I basically have the following situation (default generated IDs omitted):
Code:
@Entity
public class A {
@OneToMany(mappedBy="a", cascade=CascadeType.ALL, fetch=FetchType.EAGER)
private Set<BB> bMany = new HashSet<BB>();
@Entity
public class BB {
@ManyToOne(cascade={CascadeType.PERSIST, CascadeType.REFRESH })
@JoinColumn(name = "A_ID")
@ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
private A a;
Schema:
CREATE TABLE BB(
A_ID BIGINT NOT NULL,
CONSTRAINT FOREIGN KEY (A_ID) REFERENCES A(ID) ON DELETE CASCADE
) ENGINE=InnoDB;OK. I create an A with a couple of BBs in it, and persist it. Everything's fine. Now I call entityManager.remove() on the A instance I persisted, and I can see it issuing DELETE commands for BB after the DELETE for A, which produces an OptimisticLockException. I'd have hoped that the above @ForeignKey would have told Kodo not to issue such commands, knowing that the DB would do it.
Any insight? Have I used @ForeignKey correctly (examples seem sparse in the documentation)? Is there a workaround, other than removing the cascade delete and doing deletions manually from code?
Thanks,
-- Bryan Loofbourrow

1. Kodo needs to know the constraints set on mapped columns.
Set the following properties in your configuration
kodo.jdbc.SchemaFactory:native(ForeignKeys=true)
2. Are you explictly setting kodo.jdbc.UpdateManager property?

Kodo/Postgres speed issue

Hello,
I was going to compare MySQL and PostgreSQL performance using Kodo. It was
really surprising to find that reading records was about 25 times slower
using Postgres. After some research, I found that Kodo's querys do not put
single quotes around numerals and this, for some reason, makes Postgres
ignore column indices. To me, this sounds like a bug in Postgres.
Anyway, I was able to circumvent the problem by adding the quotes around
numerals in a Dictionary which extended PostgresDictionary, but I suppose
you would like to know about the issue.
And another thing: The Kodo documentation states that the Postgres
dictionary is called
"com.solarmetric.kodo.impl.jdbc.schema.dict.PostgreSQLDictionary", when it
is in fact "...PostgresDictionary".
Dag H__idahl

Hi-
If a table's indexed column isn't an int4, postgres's query parser will see
the int4s in the
query and won't realize that it can use the index. This is a known issue
for Postgres, but
the quotes-workaround seems to be the best way to fix it.
-Mike
Dag Hoidahl wrote:
Hello,
I was going to compare MySQL and PostgreSQL performance using Kodo. It was
really surprising to find that reading records was about 25 times slower
using Postgres. After some research, I found that Kodo's querys do not put
single quotes around numerals and this, for some reason, makes Postgres
ignore column indices. To me, this sounds like a bug in Postgres.
Anyway, I was able to circumvent the problem by adding the quotes around
numerals in a Dictionary which extended PostgresDictionary, but I suppose
you would like to know about the issue.
And another thing: The Kodo documentation states that the Postgres
dictionary is called
"com.solarmetric.kodo.impl.jdbc.schema.dict.PostgreSQLDictionary", when it
is in fact "...PostgresDictionary".
Dag H__idahl--
Mike Bridge

Kodo logging issue on IBM WAS 5.0

Hi All,
Thank you for reading this. I could use a good advice here, I have been
banging my head against wall for a while ...
We have a J2EE application that uses Kodo 2.4.2 with IBM WAS 5.0. Due to
'class not found' problems (related to registering the PMfactory with
JNDI, I reckon), I was forced to use a Websphere extension classloader to
load Kodo. (deploy Kodo libraries to c:\program
files\websphere\AddServer\lib\ext )
That is good and well, however now I want to configure logging (Log4J) for
Kodo. To do that, I have tried (feels like I have tried it all ;-)) to put
the log4j.properties to:
c:\program files\websphere\AddServer\properties\log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.jar!log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.properties
inside of the Kodo.jar (desperate people do desperate things ;-))
log4j.properties is also referenced as a part of shared library
Just for completness, log4j.properties also exists in Java utility jar
file that is part of EAR file (although that probably would not help the
Websphere extension classloader-loaded classes)
I have also tried to define the log4j.configuration in my startServer.bat:
SET LOG4J=-Dlog4j.configuration=file:/c:/log4j.properties
echo LOG4J set %LOG4J%
"%JAVA_HOME%\bin\java" %LOG4J% %WAS_TRACE%
To initialize Log4J differently. Yes, you guessed right, that damn thing
still does not work. What am I missing???
What exactly is happening when Kodo/Log4j configures the logging?
It may sound like just a nuisance, but it is actually quite important,
because we are just inch from production and need to get rid of heaps of
debuging messages (including the annoying SQL Server induced close cursor
exceptions). It just would not shut up!!! ;-))))
Any idea how to silence the bloody thing beside turning off the power? ;-)
Thank you,
Petr

Petr-
The easiest thing to do would be to put some code in your application
that will give information on the definitive location of the
log4j.properties file. E.g.:
System.out.println (getClass().getClassLoader().getResource("/log4j.properties"));
Other than that, note that there are a variety of System properties you
can use to override the logging system that will be use. The Kodo 2.5
documentation covers this a bit better than the 2.4 docs:
http://www.solarmetric.com/Software/Documentation/2.5.0b1/docs/manual.html#ref_guide_logging
Finally, note that some application servers use log4j internally for
logging, and configure it differently (e.g., JBoss uses a log4j.xml
file, rather than a log4j.properties file). You might want to check the
documentation of your appserver to determine if there is an alternate
mechanism for configuring log4j.
Let us know if you still need help with this.
In article <[email protected]>, Petr Bulanek wrote:
Hi All,
Thank you for reading this. I could use a good advice here, I have been
banging my head against wall for a while ...
We have a J2EE application that uses Kodo 2.4.2 with IBM WAS 5.0. Due to
'class not found' problems (related to registering the PMfactory with
JNDI, I reckon), I was forced to use a Websphere extension classloader to
load Kodo. (deploy Kodo libraries to c:\program
files\websphere\AddServer\lib\ext )
That is good and well, however now I want to configure logging (Log4J) for
Kodo. To do that, I have tried (feels like I have tried it all ;-)) to put
the log4j.properties to:
c:\program files\websphere\AddServer\properties\log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.jar!log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.properties
inside of the Kodo.jar (desperate people do desperate things ;-))
log4j.properties is also referenced as a part of shared library
Just for completness, log4j.properties also exists in Java utility jar
file that is part of EAR file (although that probably would not help the
Websphere extension classloader-loaded classes)
I have also tried to define the log4j.configuration in my startServer.bat:
SET LOG4J=-Dlog4j.configuration=file:/c:/log4j.properties
echo LOG4J set %LOG4J%
"%JAVA_HOME%\bin\java" %LOG4J% %WAS_TRACE%
To initialize Log4J differently. Yes, you guessed right, that damn thing
still does not work. What am I missing???
What exactly is happening when Kodo/Log4j configures the logging?
It may sound like just a nuisance, but it is actually quite important,
because we are just inch from production and need to get rid of heaps of
debuging messages (including the annoying SQL Server induced close cursor
exceptions). It just would not shut up!!! ;-))))
Any idea how to silence the bloody thing beside turning off the power? ;-)
Thank you,
Petr
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Issue while getting the Hibernate EntityManagerFactory in Weblogic (EJB3)

I am facing an issue when am getting the EntityManagerFactory from JPA from the following code in weblogic StartUp Class
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("testEJBPU");
logger.info("Created EntityManagerFactory");
Context ctx = new InitialContext();
ctx.rebind("testEJBPU", emf);
The above code is only returning the OPenJPA EntityManagerFactory instead of the Hibernate's I have the following in my Presistence.xml file
<?xml version="1.0" encoding="UTF-8"?>

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="testEJBPU" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>jdbc/evolvDS</jta-data-source>
<properties>
<property name="hibernate.ejb.cfgfile"
value="META-INF/hibernate.cfg.xml"/>
<property name="hibernate.transaction.factory_class"
value="org.hibernate.ejb.transaction.JoinableCMTTransactionFactory"/>
<property name="hibernate.transaction.manager_lookup_class"
value="org.hibernate.transaction.WeblogicTransactionManagerLookup"/>
<property name="hibernate.cache.provider_class"
value="org.hibernate.cache.EhCacheProvider"/>
<property name="hibernate.cache.jndi"
value="evolv-cache"/>
</properties>
</persistence-unit>
</persistence>
and am getting the following error which is related to openJPA when application starts up
<Apr 14, 2009 9:48:18 AM PKT> <Critical> <WebLogicServer> <BEA-000286> <Failed to invoke startup class "binder", <1.0.0 fatal user error> org.apache.openjpa.util.UserException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property.
<1.0.0 fatal user error> org.apache.openjpa.util.UserException: A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName property.
at org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:70)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:802)
at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:568)
at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1185)
at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:450)
at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:375)
at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:102)
at kodo.conf.CachingMetaDataRepositoryPlugin.instantiate(CachingMetaDataRepositoryPlugin.java:29)
at org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:79)
at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:833)
at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:828)
at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:539)
at org.apache.openjpa.kernel.AbstractBrokerFactory.readResolve(AbstractBrokerFactory.java:381)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1033)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1728)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at weblogic.rmi.extensions.server.CBVInputStream.readObjectInternal(CBVInputStream.java:71)
at weblogic.rmi.extensions.server.CBVInputStream.readObject(CBVInputStream.java:65)
at weblogic.jndi.internal.JNDIHelper.copyObject(JNDIHelper.java:36)
at weblogic.jndi.internal.WLEventContextImpl.copyObject(WLEventContextImpl.java:379)
at weblogic.jndi.internal.WLEventContextImpl.rebind(WLEventContextImpl.java:114)
at javax.naming.InitialContext.rebind(InitialContext.java:367)
at com.illuminatics.test.weblogic.EntityManagerFactoryBinder.main(EntityManagerFactoryBinder.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.invokeMain(ClassDeploymentManager.java:353)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.invokeClass(ClassDeploymentManager.java:263)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.access$000(ClassDeploymentManager.java:54)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager$1.run(ClassDeploymentManager.java:205)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.invokeClassDeployment(ClassDeploymentManager.java:198)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.invokeClassDeployments(ClassDeploymentManager.java:177)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.runStartupsAfterAppActivation(ClassDeploymentManager.java:158)
at weblogic.management.deploy.classdeployment.StartupClassPrelistenService.start(StartupClassPrelistenService.java:13)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
>
My EAR Structure is as:
testEJBProject.ear
-->lib/
-->META-INF/
----->application.xml
----->MANIFEST.MF
-->testEJB.jar
----->META-INF/
--------->hibernate.cfg.xml
--------->INDEX.LST
--------->MANIFEST>MF
--------->persistence.xml
----->com/../..*
Kindly Let me know its solution if anyone has encountered it before!.

Hi,
It doesn't look like your persistence.xml file is being found so Kodo (the current default JPA provider in WLS) is being used (and it's complaining because it doesn't see a datasource configured or any necessary properties for Kodo to setup its own connection pool).
In order for your persistence.xml to be found it must be visible to the context ClassLoader on the Thread when the Persistence.createEntityManagerFactory call is made. Is your startup class configured at the server level or is it configured in your application (via a weblogic-application.xml file)?
I don't think a server startup class would work in this case but an application startup class should.
- Matt

Kodo 4.1.2 license key problem

Has anyone tried the JDO tutorial provided with Kodo 4.1.2? Everything works fine until I try to create the mappings with 'mappingtool -p jdo.properties package.jdo'. Then I get:
Exception in thread "main" com.solarmetric.license.LicenseException: No product
license key was found. Please ensure that you either have a valid "license.bea"
file in your CLASSPATH or in the directory specified by the "bea.home" environme
nt variable, or else that you have a valid license key specified in the "kodo.Li
censeKey" property of you Kodo configuration. If you need to request an evaluati
on license, please go to http://commerce.bea.com or contact [email protected]
at com.solarmetric.license.License.<init>(License.java:67)
at kodo.conf.KodoCapabilities.newLicense(KodoCapabilities.java:133)
at kodo.conf.LicenseKey.getLicense(LicenseKey.java:38)
at kodo.conf.LicenseKey.getLicense(LicenseKey.java:22)
at kodo.jdbc.meta.KodoClassMapping.validateMapping(KodoClassMapping.java
I'm running the tutorial using the kodocmd.bat and I changed the properties to point to kodo's install directory and my jdk home directory.
I've downloaded the xml document at 'http://ftpmain.bea.com/download/pub/license/kodo/kodo40/license.bea', named it license.bea and put it in kodo's install directory which is on the classpath.
I think the problem is getting Kodo to recognize the license outside of a web application. I am trying to use Kodo in a standalone application and obviously need it to recognize the license key.
Regards,
Jake

Hi Jake,
I don't think the problem is getting Kodo to recognize the license outside
the web application (I am also working on a standalone application). I think
the problem is that the code still requires the "old" solarmetric license
key next to the bea license key. I actually run into the same problem if I
don't specify both keys. Since I still have several important bugs already
open for months and registering an issue requires writing complete testcases
including manuals how to use these test cases, I actually didnt even bother
to register this one.
kind regards,
Christiaan
<Jacob Bowers> wrote in message news:[email protected]...
Has anyone tried the JDO tutorial provided with Kodo 4.1.2? Everything
works fine until I try to create the mappings with 'mappingtool -p
jdo.properties package.jdo'. Then I get:
Exception in thread "main" com.solarmetric.license.LicenseException: No
product
license key was found. Please ensure that you either have a valid
"license.bea"
file in your CLASSPATH or in the directory specified by the "bea.home"
environme
nt variable, or else that you have a valid license key specified in the
"kodo.Li
censeKey" property of you Kodo configuration. If you need to request an
evaluati
on license, please go to http://commerce.bea.com or contact [email protected].
at com.solarmetric.license.License.<init>(License.java:67)
at kodo.conf.KodoCapabilities.newLicense(KodoCapabilities.java:133)
at kodo.conf.LicenseKey.getLicense(LicenseKey.java:38)
at kodo.conf.LicenseKey.getLicense(LicenseKey.java:22)
at
kodo.jdbc.meta.KodoClassMapping.validateMapping(KodoClassMapping.java
I'm running the tutorial using the kodocmd.bat and I changed the properties
to point to kodo's install directory and my jdk home directory.
I've downloaded the xml document at
'http://ftpmain.bea.com/download/pub/license/kodo/kodo40/license.bea', named
it license.bea and put it in kodo's install directory which is on the
classpath.
I think the problem is getting Kodo to recognize the license outside of a
web application. I am trying to use Kodo in a standalone application and
obviously need it to recognize the license key.
Regards,
Jake

Kodo class/resource loading approach will be a problem in managed environment.

Hello,
Kodo does not work with Apache Tomcat 3 and 4 unless Kodo jars and my
persistent classes loaded by the same class loader. Kodo uses
Class.forName() and class.getResources() on class loader which loaded Kodo
classes thus it is not able to find system.prefs or package.jdo (and even if
it was able to find system.prefs how would it handle multiple system.prefs
from multiple contexts each managed by its own class loader?)
The problem as I see it is that web containers usually have container
classloader(s) and a class loader per web context. Desired configuration
would be to share Kodo classes among all contexts and implement jndi factory
to provide PersistentManagerFactory lookup in each web container
environment. According to Tomcat specs I placed Kodo jars in
$tomcat_home/lib (class loader shared among all contexts) and deployed my
persistent classes along with system.prefs and *.jdo files to my context
WEB-INF/lib directory. As a result Kodo would not find system.prefs resource
and eventually fail with error - required resource db/url could not be
loaded. I tried to place Kodo jars into together with my persistent classes
in WEB-INF/lib it did not help (this was really strange since all classes
should have been loaded by the same context class loader) The only
configuration that works is when I put Kodo and my persistent classes in
tomcat's common directory or on system class path. Which is of course not a
right way to go as context specific classes such as my persistent classes
should be shared
Without source code it is hard to figure out what is going on and how
resources get loaded, so could somebody look into it. It is quite important
for us to resolve this issue as we are planning to use Kodo with tomcat.
Also I am not sure that system.prefs is a good idea. As I mentioned when
integrated with appserver/web container environment jndi it is up to jndi
factory to create and configure PersistentManagerFactories. Different
PersistentManagerFactories will be bound to different jndi names often in
different contexts under common or separate class loaders and they should
not be in my opinion dependent on common system.prefs
I would greatly appreciate your suggestion on proper use of Kodo in web
container environment
Thank you very much in advance
Alex Roytman

I want to add that even if we put both Kodo jars and persistent classes jar
in WEB-INF/lib to be loaded by context class loader it does not work due to
following piece of code in Prefs.java:
private static synchronized void loadSystem() {
try {
Enumeration enumeration =
(com.techtrader.util.app.Prefs.class).getClassLoader().getResources("system.
prefs");
Object obj = null;
Object obj1 = null;
InputStream inputstream;
for (; enumeration.hasMoreElements(); inputstream.close()) {
URL url = (URL)enumeration.nextElement();
inputstream = url.openStream();
_cache.parse(inputstream, url.toString(), "");
catch (Exception exception) {
throw new ParseException(exception);
however if we replace it with following it will work:
private static synchronized void loadSystem() {
try {
Object obj = null;
Object obj1 = null;
URL url =
(com.techtrader.util.app.Prefs.class).getClassLoader().getResource("system.p
refs");
InputStream inputstream = url.openStream();
_cache.parse(inputstream, url.toString(), "");
inputstream.close();
catch (Exception exception) {
throw new ParseException(exception);
"Alex Roytman" <[email protected]> wrote in message
news:[email protected]...
Hello,
Kodo does not work with Apache Tomcat 3 and 4 unless Kodo jars and my
persistent classes loaded by the same class loader. Kodo uses
Class.forName() and class.getResources() on class loader which loaded Kodo
classes thus it is not able to find system.prefs or package.jdo (and evenif
it was able to find system.prefs how would it handle multiple system.prefs
from multiple contexts each managed by its own class loader?)
The problem as I see it is that web containers usually have container
classloader(s) and a class loader per web context. Desired configuration
would be to share Kodo classes among all contexts and implement jndifactory
to provide PersistentManagerFactory lookup in each web container
environment. According to Tomcat specs I placed Kodo jars in
$tomcat_home/lib (class loader shared among all contexts) and deployed my
persistent classes along with system.prefs and *.jdo files to my context
WEB-INF/lib directory. As a result Kodo would not find system.prefsresource
and eventually fail with error - required resource db/url could not be
loaded. I tried to place Kodo jars into together with my persistentclasses
in WEB-INF/lib it did not help (this was really strange since all classes
should have been loaded by the same context class loader) The only
configuration that works is when I put Kodo and my persistent classes in
tomcat's common directory or on system class path. Which is of course nota
right way to go as context specific classes such as my persistent classes
should be shared
Without source code it is hard to figure out what is going on and how
resources get loaded, so could somebody look into it. It is quiteimportant
for us to resolve this issue as we are planning to use Kodo with tomcat.
Also I am not sure that system.prefs is a good idea. As I mentioned when
integrated with appserver/web container environment jndi it is up to jndi
factory to create and configure PersistentManagerFactories. Different
PersistentManagerFactories will be bound to different jndi names often in
different contexts under common or separate class loaders and they should
not be in my opinion dependent on common system.prefs
I would greatly appreciate your suggestion on proper use of Kodo in web
container environment
Thank you very much in advance
Alex Roytman

Some issues while testing EJB3 API

I'm running some EJB3 peristence test outside standalone and I'm running
into some issues that I did not see running the same code against the
Hibernate EntityManager implementation.
I'm currently using the Kodo 4.0EA3 download. Any help is appreciated.
I have the following table:
Table "public.beers"
Column | Type | Modifiers
id | integer | not null
brand | character varying(50) |
price | numeric(15,2) |
Indexes:
"beers_pkey" PRIMARY KEY, btree (id)
With the following class:
package com.springdeveloper.model;
import javax.persistence.*;
import java.io.Serializable;
@Entity
@Table(name="BEERS")
public class Beer implements Serializable {
private Long id;
private String brand;
private Double price;
public Beer() {
public Beer(Long id) {
this.id = id;
@Id(generate=GeneratorType.AUTO)
@Column(name="ID", nullable=false)
public Long getId() {
return id;
public void setId(Long id) {
this.id = id;
public String getBrand() {
return brand;
public void setBrand(String brand) {
this.brand = brand;
public Double getPrice() {
return price;
public void setPrice(Double price) {
this.price = price;
public String toString() {
return "[" + id + "] " + brand + " " + price;
Issues:
=======
1) If I don't have a column named type I get an error -
Exception in thread "main" <2|false|4.0.0EA3> kodo.util.StoreException:
ERROR: column t0.type does not exist {prepstmnt 14211340 SELECT t0.ID,
t0.TYPE, t0.brand, t0.price FROM BEERS t0 WHERE (t0.ID = ?) [reused=0]}
[code=0, state=42703]
Any way around this since there is no inheritance structure involved?
2) If I don't specify a fully qualified name for the first query I get
this error:
33 INFO [main] kodo.Runtime - Starting Kodo 4.0.0EA3
74 DEBUG [main] kodo.Runtime - License capabilities: "Kodo Standard
Edition,Kodo Community Edition,Kodo Evaluation Edition,Datacache Plug-
in,Custom Result Object Providers,Custom Mappings,Enterprise
Databases,Query Extensions,Performance Pack,Statement Batching,Kodo
Enterprise Edition,Managed Environment,Developer Tools,Custom
DBDictionaries" Expiration: "11/22/05 7:00 PM" Maintenance expiration:
"11/22/05 7:00 PM"
496 INFO [main] kodo.jdbc.JDBC - Using dictionary class
"kodo.jdbc.sql.PostgresDictionary".
1007 INFO [main] kodo.MetaData - Found 3 classes with metadata in 0
milliseconds.
Exception in thread "main" <4|false|4.0.0EA3>
kodo.persistence.ArgumentException: Could not resolve entity named "Beer".
     at kodo.query.ejbql.EJBQLParser.populate(EJBQLParser.java:61)
     at kodo.query.ExpressionStoreQuery.populateFromCompilation
(ExpressionStoreQuery.java:129)
     at kodo.query.QueryImpl.compileForCompilation(QueryImpl.java:682)
     at kodo.query.QueryImpl.compileForExecutor(QueryImpl.java:713)
     at kodo.query.QueryImpl.getOperation(QueryImpl.java:1624)
     at kodo.query.DelegatingQuery.getOperation(DelegatingQuery.java:136)
     at kodo.persistence.QueryImpl.execute(QueryImpl.java:231)
     at kodo.persistence.QueryImpl.getSingleResult(QueryImpl.java:258)
     at KodoTest.main(KodoTest.java:16)
If I specify a fully qualified name for the EJBQL the first time I query
then I can just use 'Beer' in subsequent queries. It doesn't help to
specify '@Entity(name="Beer")' in the persistent class either.
Here is my query:
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
Beer b = (Beer)em.createQuery(
"select object(o) from Beer o where o.id = :id")
.setParameter("id", new Long(2))
.getSingleResult();
System.out.println("Beer: " + b);
em.getTransaction().commit();
This works but is kind of ugly:
Beer b = (Beer)em.createQuery(
"select object(o) from com.springdeveloper.model.Beer o where
o.id = :id")
.setParameter("id", new Long(2))
.getSingleResult();
And here is my peristence.xml:
<?xml version="1.0"?>
<entity-manager>
<name>BeerDistributor</name>
<provider>kodo.persistence.PersistenceProviderImpl</provider>
     <properties>
          
          <property name="kodo.LicenseKey" value="????-????-????-????-????"/>
<property name="kodo.PersistentClasses"
value="com.springdeveloper.model.Beer,
com.springdeveloper.model.Customer,
com.springdeveloper.model.Order"/>

          <property name="kodo.ConnectionURL" value="jdbc:postgresql://
localhost/test"/>
          <property name="kodo.ConnectionDriverName"
value="org.postgresql.Driver"/>
          <property name="kodo.ConnectionUserName" value="trisberg"/>
          <property name="kodo.ConnectionPassword" value="????"/>
          
          <property name="kodo.Log" value="DefaultLevel=INFO, Runtime=DEBUG,
Tool=INFO"/>
     </properties>
</entity-manager>
Thanks,
Thomas Risberg

1) If I don't have a column named type I get an error -This, unfortunately, is something that we need to clarify in the spec
itself. Currently, the discriminator value and column for a class have
default values in the spec. So technically, every base class has a
discriminator column according to spec defaults.
Obviously this isn't practical. In fact Kodo already turns off
automatic discriminator columns for vertical and table-per-class
inheritance unless you explicitly give a discrimintor value or column.
So one way to not use a discriminator column in Kodo right now is to set
your inheritance type to JOINED or TABLE_PER_CLASS. Another way is to
use Kodo's kodo.persistence.jdbc.DiscriminatorStrategy annotation, which
allows you to name a non-standard or custom discriminator strategy.
Setting this annotation's value to "final" (an alias for Kodo's
kodo.jdbc.meta.strats.NoneDiscriminatorStrategy) will indicate that the
class doesn't need a discriminator because it won't be extended.
We will try to get this ironed out in future versions of the spec.
If I specify a fully qualified name for the EJBQL the first time I query
then I can just use 'Beer' in subsequent queries. It doesn't help to
specify '@Entity(name="Beer")' in the persistent class either.This sounds like a bug in our early access implementation. I have a
feeling it only occurs with property access entities -- if you change
your entity to use field access (which also means using Kodo
enhancement), I think you'd see the problem go away. I think it might
also go away if you performed some other persistence operation on a Beer
entity (such as a by-id lookup) before attempting the query. We'll make
sure to have this fixed for our next release. Thanks for the report.

Question about Kodo Savepoint

Hello,
I tried to use Kodo Savepoint, but met some problems. I think the issue was related to the configuration. Does anybody give some advices?
With the default Kodo configurations (kodo.SavepointManager=in-mem, kodo.FlushBeforeQueries=true), Kodo reports: “The configured SavepointManager does not support incremental flushing when a savepoint has been set. You must release your savepoints before flushing” while querying from DB after setting save point.
With Kodo configurations (kodo.SavepointManager=in-mem, kodo.FlushBeforeQueries=false), the save point could be set, rollback to, released successfully. But Kodo reports: “Queries with aggregates or projections using variables currently cannot be executed in-memory. Either set IgnoreCache to true, set the openjpa.FlushBeforeQueries property to true, or execute the query before changing any instances in the transaction” while loading DB schema.
With Kodo configurations (kodo.SavepointManager=jdbc, kodo.FlushBeforeQueries=true|false), Kodo reports: “An error occurred attempting to invoke JDBC 3 method. Your driver or database may not support JDBC 3 features” while setting save point. The save point was introduced since JDBC 3.0. I can use save point successfully via JDBC client with same oracle JDBC driver and database instance. Still don’t know why this issue reported by Kodo.
With Kodo configurations (kodo.SavepointManager=oracle, kodo.FlushBeforeQueries= true|false), Kodo reports: “could not set a Savepoint with auto-commit on” while setting save point. And we can’t use oracle SavepointManager because we should support multiple database platform.
Thanks,
Alan

Can someone please respond to the solution of this problem.
     at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:293)
     at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:306)
     at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:468)
     at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:357)
     at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:83)
     at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1476)
     at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1274)
     at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:440)
     at weblogic.jdbc.jta.DataSource.connect(DataSource.java:396)
     at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:359)
     at com.solarmetric.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:122)
     at com.solarmetric.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:73)
     at kodo.jdbc.runtime.JDBCStoreManager.connectInternal(JDBCStoreManager.java:906)
     at kodo.jdbc.runtime.JDBCStoreManager.connect(JDBCStoreManager.java:884)
     at kodo.jdbc.runtime.JDBCStoreManager.retainConnection(JDBCStoreManager.java:189)
     at kodo.jdbc.runtime.JDBCStoreManager.begin(JDBCStoreManager.java:114)
     at kodo.runtime.DelegatingStoreManager.begin(DelegatingStoreManager.java:95)
     at kodo.runtime.PersistenceManagerImpl.flush(PersistenceManagerImpl.java:1106)
     at kodo.runtime.PersistenceManagerImpl.flushSafe(PersistenceManagerImpl.java:1038)
     at kodo.runtime.PersistenceManagerImpl.flush(PersistenceManagerImpl.java:808)
     at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:429)
     at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:335)
     at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:291)
     at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4060)
     at weblogic.jms.client.JMSSession.execute(JMSSession.java:3953)
     at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4467)
     at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
,currentThread=Thread[[ACTIVE] ExecuteThread: '53' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],lastUser=null,currentError=null,currentErrorTimestamp=null,t
This fails in clustered environment but works fine in stand alone.
Edited by varchitect at 01/18/2008 9:59 AM

Kodo.rar in B5 has same problem as in B4

Hi guys,
The dereference issue in B4 (which is not in B3) is still in B5. The stack trace and my code (which
is a hacked version of your code) is below.
David Ezzio
My code that looks for CF:
private ConnectionFactory getConnectionFactory()
// this the the JNDI name for the Kodo Resource
// Adaptor that you will have configured in in
// your application server
String pmname = "java:/kodo";
try
MsgCenter.putMsg("Looking up jndi name: " + pmname);
Object ob = new InitialContext().lookup(pmname);
MsgCenter.putMsg("Casting to ConnectionFactory");
ConnectionFactory fac = (ConnectionFactory) ob;
MsgCenter.putMsg("ConnectionFactory type is: " + fac.getClass().getName());
return fac;
14:30:37,306 INFO [Server] JBoss (MX MicroKernel) [3.0.0 Date:200205311035] Started in 0m:46s:86ms
14:31:04,895 INFO [STDOUT] Stateless QuoteServerEJB: ejbCreate called
14:31:04,905 INFO [STDOUT] Looking up jndi name: java:/kodo
14:31:04,905 ERROR [STDERR] javax.naming.NamingException: Could not dereference object. Root
exception is
14:31:04,905 ERROR [STDERR] java.lang.IllegalAccessException:
com.solarmetric.kodo.impl.jdbc.ee.JDOObjectFactory
14:31:04,905 ERROR [STDERR] at java.lang.Class.newInstance0(Native Method)
14:31:04,905 ERROR [STDERR] at java.lang.Class.newInstance(Class.java:237)
14:31:04,905 ERROR [STDERR] at
javax.naming.spi.NamingManager.getObjectFactoryFromReference(NamingManager.java:149)
14:31:04,905 ERROR [STDERR] at
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:302)
14:31:04,915 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:538)
14:31:04,915 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:429)
14:31:04,915 ERROR [STDERR] at javax.naming.InitialContext.lookup(InitialContext.java:350)
14:31:04,915 ERROR [STDERR] at
com.ysoft.jdo.book.sayings.service.ejb.QuoteServerEJB.getConnectionFactory(QuoteServerEJB.java:423)
14:31:04,915 ERROR [STDERR] at
com.ysoft.jdo.book.sayings.service.ejb.QuoteServerEJB.ejbCreate(QuoteServerEJB.java:44)
14:31:04,915 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.StatelessSessionEnterpriseContext.<init>(StatelessSessionEnterpriseContext.java:52)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:61)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:208)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:63)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
14:31:04,936 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:705)
14:31:04,936 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
14:31:04,936 ERROR [STDERR] at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362)
14:31:04,936 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
14:31:04,936 ERROR [STDERR] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
14:31:04,936 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152)
14:31:04,946 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
14:31:04,946 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148)
14:31:04,946 ERROR [STDERR] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
14:31:04,946 ERROR [STDERR] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
14:31:04,946 ERROR [STDERR] at java.lang.Thread.run(Thread.java:484)

The next release of Kodo, which will be 2.3.0RC.
In article <[email protected]>, David Ezzio wrote:
Hi Marc,
In the next release of Kodo? or JBoss? And next release for Kodo means the 2.3.0RC?
David
Marc Prudhommeaux wrote:
David-
The JBoss final 3.0 release seems to have changed how it accesses the
ObjectFactory factory. This should be fixed in the next release.
Sorry for all the trouble.
In article <[email protected]>, David Ezzio wrote:
Hi guys,
The dereference issue in B4 (which is not in B3) is still in B5. The stack trace and my code (which
is a hacked version of your code) is below.
David Ezzio
My code that looks for CF:
private ConnectionFactory getConnectionFactory()
// this the the JNDI name for the Kodo Resource
// Adaptor that you will have configured in in
// your application server
String pmname = "java:/kodo";
try
MsgCenter.putMsg("Looking up jndi name: " + pmname);
Object ob = new InitialContext().lookup(pmname);
MsgCenter.putMsg("Casting to ConnectionFactory");
ConnectionFactory fac = (ConnectionFactory) ob;
MsgCenter.putMsg("ConnectionFactory type is: " + fac.getClass().getName());
return fac;
14:30:37,306 INFO [Server] JBoss (MX MicroKernel) [3.0.0 Date:200205311035] Started in 0m:46s:86ms
14:31:04,895 INFO [STDOUT] Stateless QuoteServerEJB: ejbCreate called
14:31:04,905 INFO [STDOUT] Looking up jndi name: java:/kodo
14:31:04,905 ERROR [STDERR] javax.naming.NamingException: Could not dereference object. Root
exception is
14:31:04,905 ERROR [STDERR] java.lang.IllegalAccessException:
com.solarmetric.kodo.impl.jdbc.ee.JDOObjectFactory
14:31:04,905 ERROR [STDERR] at java.lang.Class.newInstance0(Native Method)
14:31:04,905 ERROR [STDERR] at java.lang.Class.newInstance(Class.java:237)
14:31:04,905 ERROR [STDERR] at
javax.naming.spi.NamingManager.getObjectFactoryFromReference(NamingManager.java:149)
14:31:04,905 ERROR [STDERR] at
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:302)
14:31:04,915 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:538)
14:31:04,915 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:429)
14:31:04,915 ERROR [STDERR] at javax.naming.InitialContext.lookup(InitialContext.java:350)
14:31:04,915 ERROR [STDERR] at
com.ysoft.jdo.book.sayings.service.ejb.QuoteServerEJB.getConnectionFactory(QuoteServerEJB.java:423)
14:31:04,915 ERROR [STDERR] at
com.ysoft.jdo.book.sayings.service.ejb.QuoteServerEJB.ejbCreate(QuoteServerEJB.java:44)
14:31:04,915 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.StatelessSessionEnterpriseContext.<init>(StatelessSessionEnterpriseContext.java:52)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:61)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:208)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:63)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
14:31:04,925 ERROR [STDERR] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
14:31:04,936 ERROR [STDERR] at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
14:31:04,936 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:705)
14:31:04,936 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
14:31:04,936 ERROR [STDERR] at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362)
14:31:04,936 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)
14:31:04,936 ERROR [STDERR] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
14:31:04,936 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152)
14:31:04,946 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
14:31:04,946 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148)
14:31:04,946 ERROR [STDERR] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
14:31:04,946 ERROR [STDERR] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
14:31:04,946 ERROR [STDERR] at java.lang.Thread.run(Thread.java:484)--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code

Kodo tune-up

Abe, Patrick,
I was using Kodo for couple of months now. I think it is a very good product
and you are getting closer to complete feature set. I wonder if you could
share with us your plans for Kodo performance optimization.
In out discussion regarding extra roundtrips to database to resolve uncached
references you explained that it is due to the fact that you do not store
reference primary key in instance's filed store. If I understand correctly
it prevents you from issuing query on referenced table instead you have to
join referenced and referencing table which is slower. Also I noticed that
when running queries it does similar thing:
For example I have a Position which directly references OrgUnit, Role and
Member so org_unit_id, member_id and role_id are columns of position table.
I want to lookup all positions with particular role, member and org unit. I
would expect something like:
select ....
from position p
where p.org_unit_id = 100 and p.role_id=10 and p.member=133
instead I get
SELECT ....
FROM POSITION t0, MEMBER t2, ORG_UNIT t1, ROLE t3
WHERE t2.MEMBER_ID = 133 AND t0.MEMBER_ID = t2.MEMBER_ID AND
t1.ORG_UNIT_ID = 100 AND t0.ORG_UNIT_ID = t1.ORG_UNIT_ID AND
t3.ROLE_ID = 10 AND t0.ROLE_ID = t3.ROLE_ID
FOUR USELESS JOINS instead of select on single table
Another issue is updates. Right now it seems to me there is no update
tuuning - you always update all columns. It is not very efficient especially
when columns you update needlessly have indices, foreign keys constraints
etc. Also when people track changes to their data (for various data
exports/imports and synchronizations) it creates many extra transactions.
One case is particularly noticeable - when you need to update LOCK column
only you update every column. Specifically when I add to a collection of a
persistent class you would update all fields of the class itself (you only
need to update LOCK for concurrency purpose) even though I made no changes
to it
These are the most noticeable things.
Please let me know if you are interested in this kind of feedback. I will be
glad to dig-up more staff :-) as I will be comparing Kodo with another JDO
implementation which claims full support of JDO specs.
Alex

"Alex Roytman" <[email protected]> writes:
Abe, Patrick,
I was using Kodo for couple of months now. I think it is a very good product
and you are getting closer to complete feature set. I wonder if you could
share with us your plans for Kodo performance optimization.Thank you. We're pleased with the direction that Kodo is going in, and
are glad that you and others on this newsgroup seem happy as well.
From the beginning, we decided to put off optimizations until the
product reached a certain level of maturity. There were two main reasons
for this decision. First, we find it to be bad practice to optimize
while coding, as you often end up optimizing unnecessary 'cold spots'.
Second, we did not want to spend time optimizing code that would not end
up in the final version.
As of the last preview release (2.2.0), I think that Kodo has pretty
much reached that level of maturity. Most of the changes that we
anticipate making to reach spec compliance (obviously barring any major
spec changes) revolve around Kodo's current Extent implementation, which
does not currently behave according to the spec. So, we are just now
trying to identify what needs optimization, and prioritizing these
needs. Major items include our overly zealous use of joins and
memory-efficient large result sets. We are also doing some profiling to
root out any potential hot spots in our algorithms.
Please let me know if you are interested in this kind of feedback. I will be
glad to dig-up more staff :-) as I will be comparing Kodo with another JDO
implementation which claims full support of JDO specs.We are very interested in feedback both regarding other inefficiencies
that you see and any other comparisons to other JDO implementations.
-Patrick
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com

Kodo 4.0 & 4.1 License for projects created in Workshop ( =v3.3)

NOTE: The (kodo) trial license installed for creating new Kodo 4.0/4.1 project is expired (4/4/07). Please try the following steps to update the license file.
https://dev2devclub.bea.com/downloads/jarlib/kodo/4.0/license.bea
https://dev2devclub.bea.com/downloads/jarlib/kodo/4.1/license.bea
- "Save as Link" and download the respective license.bea file
- replace <project-root>/src/license.bea with the downloaded new license.bea file.
- Open license.bea file to make sure the expiry date is 05/15/08
- Project > Clean (&or Rebuild AppXray Database)
- Open EJB QL editor, and execute a query to confirm the usage of latest license file

Savepoints:
It would be very convinient if Kodo provided parameterless
rollbackSavepoint() and releaseSavepoint() - they should rollback/release
latest savepoin
Thanks
Alex
"Greg Campbell" <[email protected]> wrote in message
news:dbgseo$m66$[email protected]..
All,
Kodo 3.4.0 Beta 1 is now available. Feel free to download it at:
http://www.solarmetric.com/Software/beta/3.4.0b1/
There are a number of exciting new features in 3.4.0 Beta 1:
* Query cache now caches aggregates and projections, including queries
that use grouping
* Added support for savepoints, with both in-memory and JDBC3 plugins.
* Added support for Oracle Object fields through JDBC SQLData interfaces.
* Improved thread and socket support for TCP RemoteCommitProvider
* Better support for large transactions, including several optimizations
in the datastore cache when using large transactions
You can find the release notes at:
http://solarmetric.com/Software/Documentation/3.4.0b1/docs/relnotes.html
The full documentation can be found in the distribution, and also at:
http://solarmetric.com/Software/Documentation/3.4.0b1/docs/index.html
As this is a beta release, please report any issues that you find to the
Kodo beta newsgroup (solarmetric.kodo.beta).
Good luck, and enjoy!
-Greg
SolarMetric
www.solarmetric.com

My experience migrating Kodo 3.4 to 4.1

Hello Stefan,
I struggled with Kodo 4.0 and gave it up. Kodo 4.1 seems to be a much better
release. I migrated my app in a day. First I managed to run it against 3.4
metadata with some property file changes (migration docs are not very good
and miss few things but may be if you use Kodo automated migration tools it
will do for you what I was doing manually) . If you use lots of custom
filed mappings (especially non-trivial mappings) allocate much more time for
conversion - the whole thing has changed. I have not had chance to convert
my mapping and had to bandate it with externalizers and other things for
now. One thing you lose in kodo3.4 mode is ability to query by interface
since now it must be explicetly.
Couple of tips here
- kodo.Log: kodo(DefaultLevel=INFO, SQL=TRACE...) kodo is no longer valid
logger name
- kodo.jdbc.DBDictionary: oracle(BatchLimit=30) BatchLimit=30 is no longer a
valid option use
kodo.jdbc.SQLFactory: (BatchLimit=50) instead
- kodo.PersistentClasses= ... is no longer works use
kodo.MetaDataFactory: kodo3(Types=....) in kodo3 mode or
kodo.MetaDataFactory: (Types=...) in jdo2 mode
- Any SQL with DATE column is no longer batched leading to 2-3 times
performance drop. The decision swa made based on bugs in oracle 9 drivers in
batching mode. If you have latest drivers (and database) from my experience
you will not have any problems. So to reenable it you can register your own
instance of AdvancedSQL (now a factored out part of DatabaseDictionary):
kodo.jdbc.SQLFactory: (BatchLimit=50,
AdvancedSQL=com.peacetech.jdo.kodo.kodo4.patch.OracleAdvancedSQL)
where OracleAdvancedSQL could look like:
public class OracleAdvancedSQL extends kodo.jdbc.sql.OracleAdvancedSQL {
@Override public boolean canBatch(Column col) {
switch (col.getType()) {
case Types.DATE:
return true;
default:
return super.canBatch(col);
- I have not tested read performance much since I was concentrating on
writes. But write performance even with batch enabled does not seems to be
not up to 3.4 level I observed a consistent 30-40% decrease in performance
while persisting large graph complex of fairly small objects. I ran 3.4 and
4.1 versions side by side against a dedicated Oracle 10 server and noticed
performance decrease of 30-40%
SQL generated by both versions was very close if not identical (I only did
spotcheck) but incase of INSERT you would not expect it any different anyway
I tried profiling 4.1 version and found some significant hot spots but could
not dechipher them in any reasonable time because of huge depth of stacks
and lack of source code. I might try it again if I have time because
performance is critical for us.
- I have not tried any new/advanced features yet. including new mappings,
detachment, data cache, quality of eager fetch so I can not give you any
good feedback on that. At least I can say that this release worth trying -
after migration my application worked as expected except for lower
performance
I also have to say I do not know how well automated migration of kodo 3.4
metadata to jdo2 metadata works (if it exists) because I use my model driven
code generator and I just developed JDO2 plugin for it and regenerated my
metadata from the model (I did not have to gegenerate my java classes of
course)
Alex
Then I created native JDO2 mappings and everything

Denis,
Could you email it to me please shurik at peacetech dot com
Thanks
Alex
"Denis Sukhoroslov" <[email protected]> wrote in message
news:[email protected]...
Alex,
The issue was in version 3.4.1. BEA has provided a patch, no new version.
Denis.
"Alex Roytman" <[email protected]> wrote in message
news:[email protected]...
Denis,
In which version did you observe it and which version fixed it?
Thank you
Alex
"Denis Sukhoroslov" <[email protected]> wrote in message
news:[email protected]...
I don't know, I didn't tried 4.1 yet. It is possible that this issue
was'n exist in kodo 4.x at all.
"Christiaan" <[email protected]> wrote in message
news:[email protected]...
Nice! Is it also solved for 4.1?
regards,
Christiaan
"Denis Sukhoroslov" <[email protected]> wrote in message
news:[email protected]...
Finally, BEA has solved the issue I mentioned. Reading cached PCs
which have embedded objects become much faster (about 10 times in my
tests).
Thank you very much to all why was involved in this job.
Denis.
"Denis Sukhoroslov" <[email protected]> wrote in message
news:[email protected]...
Hi Alex,
I know about default-fetch-group, of course I marked these embedded
fields properly. You're right, it is not a cache miss but an
unnecessary fetch from DB. It's strange that nobody has found this
before. I managed to create a stanalone test case and send it to BEA
support. They agree that it is a bug, but still can't fix the issue.
The test is quite small, so if anyone interested I can send it here.
Denis.
"Alex Roytman" <[email protected]> wrote in message
news:[email protected]...
Hi Denis,
That's very strange. All custom fields such enums etc. are
essentially mapped onto regular JDO mandated types. I use it all the
time and have not observed this behavior but I might have missed it
of course. I have a suspicion that what you are seeing is not cache
misses but rather fetches outside of default fetch group. Keep in
mind that Kodo does not fetch any custom field as part of default
fetch group unless you explicetly specified it in your package.jdo
So, try to mark all your custom mapped fields with
default-fetch-group="true" and I suspect all your extra database
selects will disspear.
Read speed, inded, is always the critical part. I just have not had
chance to play with 4.1 reads enough to say if it is faster or
slower. There are more ways to optimize reads (various flavors of
eager fetches, cutom optimized mapping of collections including
embedding ...) but very few optimizations for updates
Alex
"Denis Sukhoroslov" <[email protected]> wrote in message
news:[email protected]...
Hi Alex.
My question is out of this topic, but it looks like you may have an
answer. BEA support did nothing for the last few months.
We still use kodo 3.4.1. DB is Sybase 12.5.x. In our app we're very
concerned on performance as well. But, we do have much more reads
then writes. So, we're trying to cache as much as possible. Kodo
distributed cache works quite good. At least, it presents better
performance then Gemfire and Tangosol, on the same use cases. But
we found a bug in its caching mechanism: when you have a persistent
class and this class has an embedded attribute of some
non-primitive type (like enum or just a simple complex type with
one or two attributes in it) kodo bypasses cache and performs a
select to DB each time. Have you seen this? Is it possible to solve
via custom mapping, what do you think?
Thanks. Denis.
"Alex Roytman" <[email protected]> wrote in message
news:[email protected]...
Hello Stefan,
I struggled with Kodo 4.0 and gave it up. Kodo 4.1 seems to be a
much better release. I migrated my app in a day. First I managed
to run it against 3.4 metadata with some property file changes
(migration docs are not very good and miss few things but may be
if you use Kodo automated migration tools it will do for you what
I was doing manually) . If you use lots of custom filed mappings
(especially non-trivial mappings) allocate much more time for
conversion - the whole thing has changed. I have not had chance to
convert my mapping and had to bandate it with externalizers and
other things for now. One thing you lose in kodo3.4 mode is
ability to query by interface since now it must be explicetly.
Couple of tips here
- kodo.Log: kodo(DefaultLevel=INFO, SQL=TRACE...) kodo is no
longer valid logger name
- kodo.jdbc.DBDictionary: oracle(BatchLimit=30) BatchLimit=30 is
no longer a valid option use
kodo.jdbc.SQLFactory: (BatchLimit=50) instead
- kodo.PersistentClasses= ... is no longer works use
kodo.MetaDataFactory: kodo3(Types=....) in kodo3 mode or
kodo.MetaDataFactory: (Types=...) in jdo2 mode
- Any SQL with DATE column is no longer batched leading to 2-3
times performance drop. The decision swa made based on bugs in
oracle 9 drivers in batching mode. If you have latest drivers (and
database) from my experience you will not have any problems. So to
reenable it you can register your own instance of AdvancedSQL (now
a factored out part of DatabaseDictionary):
kodo.jdbc.SQLFactory: (BatchLimit=50,
AdvancedSQL=com.peacetech.jdo.kodo.kodo4.patch.OracleAdvancedSQL)
where OracleAdvancedSQL could look like:
public class OracleAdvancedSQL extends
kodo.jdbc.sql.OracleAdvancedSQL {
@Override public boolean canBatch(Column col) {
switch (col.getType()) {
case Types.DATE:
return true;
default:
return super.canBatch(col);
- I have not tested read performance much since I was
concentrating on writes. But write performance even with batch
enabled does not seems to be not up to 3.4 level I observed a
consistent 30-40% decrease in performance while persisting large
graph complex of fairly small objects. I ran 3.4 and 4.1 versions
side by side against a dedicated Oracle 10 server and noticed
performance decrease of 30-40%
SQL generated by both versions was very close if not identical (I
only did spotcheck) but incase of INSERT you would not expect it
any different anyway :-)
I tried profiling 4.1 version and found some significant hot spots
but could not dechipher them in any reasonable time because of
huge depth of stacks and lack of source code. I might try it
again if I have time because performance is critical for us.
- I have not tried any new/advanced features yet. including new
mappings, detachment, data cache, quality of eager fetch so I can
not give you any good feedback on that. At least I can say that
this release worth trying - after migration my application worked
as expected except for lower performance
I also have to say I do not know how well automated migration of
kodo 3.4 metadata to jdo2 metadata works (if it exists) because I
use my model driven code generator and I just developed JDO2
plugin for it and regenerated my metadata from the model (I did
not have to gegenerate my java classes of course)
Alex
Then I created native JDO2 mappings and everything

Kodo 2.5.3 reversetutorial issue

Similar Messages

Maybe you are looking for