Kodo 3.0.0 Released
Hello All,
SolarMetric is happy to announce the general availability of Kodo JDO 3.0.0.
The latest version of Kodo JDO is the most powerful ever. Full release notes
can be found at http://docs.solarmetric.com/relnotes.html. A list of the
major changes can be found at the bottom of this email. If you have a valid
and up-to-date maintenance and support contract, you can download the latest
release at http://www.solarmetric.com/Software/Purchase/download.php.
If you don't, please contact your sales representative
([email protected]) to determine how to upgrade.
Major changes in Kodo JDO 3.0.0 include:
- Kodo now supports direct SQL queries and stored procedure calls through
the javax.jdo.Query interface.
- Technology preview of Kodo Management / Monitoring capability.
- JRun 4 is now supported.
- Built-in support for Borland JDataStore, as well as Microsoft Access and
Microsoft Visual FoxPro (using a JDBC-ODBC server bridge like DataDirect,
but not the Sun JDBC-ODBC bridge).
- Refactored data caching to not lock the cache as a whole when loading data
from it or storing data into it. This change improves the concurrency of the
cache.
- Support for detaching and attaching instances from a persistence manager,
allowing applications to more easily use a "data transfer object" pattern.
- Support for collection and map fields that are backed by large result
sets.
- Support for additional settings to control the handling of large result
sets.
- Better exception messages when mappings can't be found or fail validations
against the schema.
- Expanded smart proxies to include change-tracking for lists.
- New externalization system for storage of field types not supported by JDO
without resorting to serializing or requiring custom mappings. Replaces the
old stringification mapping.
- Support for aggregates and projections in queries. See the Query
Aggregates and Projections documentation for more details.
- New mapping system, providing more flexible mapping options.
- Pluggable system for storing mapping information, with built-in options
for storing mapping information in the database, in JDO metadata extensions,
and in a separate mapping file. See the section on the Mapping Factory for
more information.
- Support for embedded 1-1 mappings, including nested embedded mappings with
no limit on nesting depth. See the section on Embedded One-to-One Mapping
for more information.
- Support for timestamp and state-based optimistic lock versioning, and for
custom versioning systems. See the section on Version Indicators for more
information.
- 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.
- Improved documentation and error messaging.
Enjoy,
-Greg
Hi,
This plug in will it works with Kodo 4.0.1 and maven 1.0.2?
Thanks
Guy
Similar Messages
-
All,
Kodo 3.1.5 is now available! Get your copy while supplies last!
Available only direct from SolarMetric at
http://www.solarmetric.com/jdo/Evaluate/
There are a number of bug fixes in this patch release. You can find the
release notes at:
http://www.solarmetric.com/jdo/Documentation/latest/docs/relnotes.html
Enjoy,
-Greg
Greg Campbell
SolarMetric Inc.Stephen Kim wrote:
Did you set the StoreCharsAsNumbers=false in your DBDictionary setting?
kodo.jdbc.DBDictionary: StoreCharsAsNumbers=false
Jaime De La Jara F. wrote:
Yes, but it seems we did something wrong, fortunely, after defining the
correct CLASSPATH, we've got the mapping files with the right db
structure, however there are some details to correct since when we execute
the application, kodo complains about an int field not being compatible
with a
char column in the db, but the field is defined as char. Here is the error
message :
Caused by: kodo.jdbc.meta.MappingInfoNotFoundException: The "column"
attribute/extension for field "cl.eclac.sca.modelo.Vertice.letter" names a
column "LETTERX" in table "VERTICEX" whose type (CHAR) is not compatible
with the type of the field (INTEGER).
We are using Sybase adaptive Server 12.5. Any hint about this problem
would
be appreciated.
No, we didn't try that option, however since the error was restricyed to
only one class, we converted the field to a String and everything worked
just fine. Thanks for the hint, we'll try it. -
All,
Kodo 3.4.0 Release Candidate 3 is now available. Feel free to download
it at:
http://www.solarmetric.com/Software/beta/3.4.0RC3/
There are a number of exciting new features in 3.4.0 RC3:
* 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
* Improvements to reverse mapping
* Improvements to unicode support for Oracle
* Improvements to performance of attaching of object graphs
* Improvements to exception handling and reporting
* Tangosol plugin supports query cache
You can find the release notes at:
http://www.solarmetric.com/Software/Documentation/3.4.0RC3/docs/relnotes.html
The full documentation can be found in the distribution, and also at:
http://www.solarmetric.com/Software/Documentation/3.4.0RC3/docs/index.html
As this is a release candidate, please report any issues that you find
to the Kodo beta newsgroup (solarmetric.kodo.beta).
Good luck, and enjoy!
-Greg
SolarMetric
www.solarmetric.comSavepoints:
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 -
KODO Disgrace - Newgroup Quality
KODO Newsgroup Quality
We are planning to use KODO as the underlying persistence mechanism for an already implemented system. We have updated our persistency wrapper with the JPA compliant KODO since we wanted to be JPA compliant. Everything were fine till we started to use the wrarpper in the real system. We had some problems during the migration.
That shall be disgrace. There is no reply to our posts even more than a month. Maybe this place is not to write such questions, maybe there is a bug, maybe we couldnt clearly explain the problem etc etc.. however our posts does not have even a single negative/positive reply. We are almost on the edge of giving up the decision to use KODO. If the problem is the money, we planned to use it with the end of a successful migration.
Congratulations dear KODO team, and thank you.
SiyamedWe are reading these forums.
Unfortunately, our response times have not been good because we had not set up a responsibility for creating responses. But we do care very much about the concerns raised here, and I am as disturbed as you to find that our Support is not hitting the mark. Rest assured, I’m taking action on this.
Marc Logemann does hit the nail on the head when he identifies these problems as stemming mainly from the transition. Kodo developers used to monitor these user groups, but we’ve assigned the Kodo developers to new product development. In their place, we are training a new Kodo Support Team, but it does take time to put infrastructure in place—which is why our responses… even this one… may seem sluggish in this transition phase. Once people are in place with the expertise needed, I think you’ll find our responses to be both swift and knowledgeable.
However, that isn’t an excuse. The truth is, it was never our intention to ignore developers, even during this transition period. We do still have support structures in place for Kodo. Our support team is not quite up to the level of the original Kodo engineers, it is true, but we expected them to meet the need during this transition.
I think the major disconnect here is that Kodo users have been used to receiving support in a different way than we anticipated, and in a different way than we are used to providing it. However, we should have done a better job of familiarizing long-time Kodo users like you with the processes BEA has in place for customers to raise and escalate concerns and get issue resolution. We should have been more prepared for the culture you already have in place.
Luckily, that is easily remedied. We are working to get everyone educated about our Support channels. We are also in the process of building a strong infrastructure to provide Kodo users with BEA’s normal level of comprehensive support. And we expect to be able to regularly review forums such as this one.
As for our support of Kodo as a stand-alone product: it is absolutely not in question. BEA’s resource commitment to Kodo is very strong. We do not intend to change the things that make Kodo most successful. I’ve copied and pasted a few bullet points below to indicate how we are working internally to bring Kodo support up to date.
Here are some of the commitments BEA is making to Kodo:
a. More BEA Support engineers assigned to Kodo (and currently coming up to speed) than the size of the entire original SolarMetric engineering team prior to acquisition.
b. Kodo Support engineers training in all regions worldwide. This enables us to provide business hour support including phone support in EMEA and APAC as well as in the Americas.
c. 24x7 Production Support, another first for Kodo customers. Previous SolarMetric support was email-only and on a 12x5 basis (10 AM – 10 PM EST).
d. We have been focusing the expertise of the Kodo Engineers on product development: This year, the BEA Kodo team delivered a major release for EJB3 (Kodo 4.0) and released that technology to the open source community via Open JPA. We are also nearing the release for JDO2 (Kodo 4.1).
e. Adding staff and additional trainings in preparation for future releases of Kodo.
I hope this answers some of the questions raised here. I encourage you to contact me if you have concerns about the support you are receiving from BEA.
Thanks for offering us feedback and for your support of Kodo.
Terry Clearkin
WW SVP, BEA Support -
JDOHelper cannot be used in place of KodoHelper
Environment: _
kodo-jdo-3.0.0RC1 on Windows XP Pro SP1
Hi all,
I think we have found a bug regarding Kodo licensing and JDOHelper. I have a test case, based on Kodo's tutorial, which demonstrates this, available on demand.
As far as we can see, you have no other choice than using KodoHelper class, which will pick-up kodo.properties properly.
If you use JDOHelper class instead you get a license error - See stack below.
We feel this is a regression since using JDOHelper was working fine with Kodo 3.0 beta release.
Could you please confirm there is a bug here ?
I have modified the JDOFactory class in the tutorial to either use KodoHelper or use JDOHelper, based on a parameter:
PersistenceManager pm _ JDOFactory.getPersistenceManager (JDOFactory.KODO_HELPER);
or
PersistenceManager pm _ JDOFactory.getPersistenceManager (JDOFactory.JDO_HELPER);
In JDOFactory.java:
if ( mode __ KODO_HELPER ) {
/* Solution 1 : use KodoHelper.
* This is currently the only working solution._
factory _ KodoHelper.getPersistenceManagerFactory("kodo.properties");
} else if ( mode __ JDO_HELPER ) {
/* Solution 2 : use JDOHelper.
* This is the standard solution. But it does not work._
Properties properties _ new Properties();
properties.setProperty(
"javax.jdo.PersistenceManagerFactoryClass",
"kodo.versant.ObjectPersistenceManagerFactory");
properties.setProperty("javax.jdo.option.ConnectionURL", "jdodb");
properties.setProperty("javax.jdo.option.ConnectionUserName",
System.getProperty("user.name"));
factory _ JDOHelper.getPersistenceManagerFactory(properties);
Using KodoHelper we get the following:
[c:\myarea\dev\jdo\tutorial kodo]java tutorial.SeedDatabase
Created 5 new dogs.
Using JDOHelper we get the following:
Exception in thread "main" javax.jdo.JDOFatalUserException: Exception thrown by getPersistenceManagerFactory(Properties)
NestedThrowables:
java.lang.reflect.InvocationTargetException
at javax.jdo.JDOHelper.getPersistenceManagerFactory(Unknown Source)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(Unknown Source)
at tutorial.JDOFactory.getPersistenceManagerFactory(JDOFactory.java:49)
at tutorial.JDOFactory.getPersistenceManager(JDOFactory.java:64)
at tutorial.SeedDatabase.main(SeedDatabase.java:30)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
.... 5 more
Caused by: com.solarmetric.license.LicenseException: No product license key was found. Please ensure that your license key is specified in y
our kodo.properties file (or in the "General" tab of your IDE's configuration dialog), that the key has not expired, and that it is the corr
ect key for the version of the product that you are running. If you need to request an evaluation key, please go to http://www.solarmetric.c
om, or contact [email protected].
at com.solarmetric.license.License.<init>(License.java:43)
at kodo.conf.JDOConfigurationImpl.getLicense(JDOConfigurationImpl.java:311)
at kodo.runtime.PersistenceManagerFactoryImpl.<init>(PersistenceManagerFactoryImpl.java:79)
at kodo.versant.ObjectPersistenceManagerFactory.<init>(ObjectPersistenceManagerFactory.java:35)
at kodo.versant.ObjectPersistenceManagerFactory.getPersistenceManagerFactory(ObjectPersistenceManagerFactory.java:47)
.... 9 more
Thanks,
P@trick
Patrick Guillot Versant France Support Technique
tel.: 0 810 810 664 http://www.versant.fr [email protected]Patrick-
Excuse the interruption, and if I am stating the obvious, but I don't
see a "kodo.LicenseKey" property in the Properties object that you create:
Properties properties = new Properties();
properties.setProperty(
"javax.jdo.PersistenceManagerFactoryClass",
"kodo.versant.ObjectPersistenceManagerFactory");
properties.setProperty("javax.jdo.option.ConnectionURL", "jdodb");
properties.setProperty("javax.jdo.option.ConnectionUserName",
System.getProperty("user.name"));
factory = JDOHelper.getPersistenceManagerFactory(properties);
Are you expecting Kodo to pick it up from a kodo.properties file in the
CLASSPATH? If so, then that isn't the way it works: Kodo will only use
the kodo.properties file if you maually specify it. You need to include
the license key in your properties object.
In article <[email protected]>, Guillot wrote:
This is exactly what I did! I reproduce the issue not only with Versant,
but also with JDBC, using MySQL.
If you allow, I can send you the very simple test case and all information
you'll ask me to send.
Thanks,
Stephen Kim wrote:
My guess is that Versant's ObjectPersistenceManagerFactory creates a new
JDOConfiguration with the loadDefaults option set to false. If you can
replicate this with JDBCPersistenceManagerFactory, we can continue
discussing this problem here. Otherwise, I would point you to Versant's
internal Kodo support system.
Guillot wrote:
But my classpath does not change between my test using KodoHelper and
the one using JDOHelper. I use the same command window and run one test
after the other. So, why does KodoHelper find kodo.properties while
JDOHelper does not?
More over, kodo.properties is located in the directory where I have the
tutorial package. So, if it was a classpath issue, I would get a
ClassNotFound Exception when using tutorial.SeedDatabase. Which is not the
case.
I agree that using FileInputStream to load kodo.properties is a working
work-around. But the method I use should also work - and it used t work.
In the past, we have never been setting the license key in a property, in
the source code. It has always been picked up by kodo in kodo.properties.
Cheers,
P@trick
Stephen Kim wrote:
This is not a bug as we use JDOHelper for most of our internal tests for
JDO compliance. My guess is that you do not have kodo.properties at the
root of your system classpath, and thus when you initialize your
properties object, there is no license key. Instead of setting
properties (in which case you should be setting the kodo.LicenseKey
property), try using a FileInputStream to load kodo.properties.
support.versant wrote:
Environment:
kodo-jdo-3.0.0RC1 on Windows XP Pro SP1
Hi all,
I think we have found a bug regarding Kodo licensing and JDOHelper. I
have a test case, based on Kodo's tutorial, which demonstrates this,
available on demand.
As far as we can see, you have no other choice than using KodoHelper
class, which will pick-up kodo.properties properly.
If you use JDOHelper class instead you get a license error - See stack
below.
We feel this is a regression since using JDOHelper was working fine with
Kodo 3.0 beta release.
Could you please confirm there is a bug here ?
I have modified the JDOFactory class in the tutorial to either use
KodoHelper or use JDOHelper, based on a parameter:
PersistenceManager pm = JDOFactory.getPersistenceManager
(JDOFactory.KODO_HELPER);
or
PersistenceManager pm = JDOFactory.getPersistenceManager
(JDOFactory.JDO_HELPER);
In JDOFactory.java:
if ( mode == KODO_HELPER ) {
/* Solution 1 : use KodoHelper.
* This is currently the only working solution.
factory = KodoHelper.getPersistenceManagerFactory("kodo.properties");
} else if ( mode == JDO_HELPER ) {
/* Solution 2 : use JDOHelper.
* This is the standard solution. But it does not work.
Properties properties = new Properties();
properties.setProperty(
"javax.jdo.PersistenceManagerFactoryClass",
"kodo.versant.ObjectPersistenceManagerFactory");
properties.setProperty("javax.jdo.option.ConnectionURL", "jdodb");
properties.setProperty("javax.jdo.option.ConnectionUserName",
System.getProperty("user.name"));
factory = JDOHelper.getPersistenceManagerFactory(properties);
Using KodoHelper we get the following:
=====================================
[c:myareadevjdotutorial kodo]java tutorial.SeedDatabase
Created 5 new dogs.
Using JDOHelper we get the following:
=====================================
Exception in thread "main" javax.jdo.JDOFatalUserException: Exception
thrown by getPersistenceManagerFactory(Properties)
NestedThrowables:
java.lang.reflect.InvocationTargetException
at javax.jdo.JDOHelper.getPersistenceManagerFactory(Unknown Source)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(Unknown Source)
at tutorial.JDOFactory.getPersistenceManagerFactory(JDOFactory.java:49)
at tutorial.JDOFactory.getPersistenceManager(JDOFactory.java:64)
at tutorial.SeedDatabase.main(SeedDatabase.java:30)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
... 5 more
Caused by: com.solarmetric.license.LicenseException: No product license
key was found. Please ensure that your license key is specified in y
our kodo.properties file (or in the "General" tab of your IDE's
configuration dialog), that the key has not expired, and that it is thecorr
ect key for the version of the product that you are running. If you need
to request an evaluation key, please go to http://www.solarmetric.c
om, or contact [email protected].
at com.solarmetric.license.License.<init>(License.java:43)
at
kodo.conf.JDOConfigurationImpl.getLicense(JDOConfigurationImpl.java:311)
at
kodo.runtime.PersistenceManagerFactoryImpl.<init>(PersistenceManagerFactoryImpl.java:79)
at
kodo.versant.ObjectPersistenceManagerFactory.<init>(ObjectPersistenceManagerFactory.java:35)
at
kodo.versant.ObjectPersistenceManagerFactory.getPersistenceManagerFactory(ObjectPersistenceManagerFactory.java:47)
... 9 more
Thanks,
P@trick
Patrick Guillot Versant France SupportTechnique
tel.: 0 810 810 664 http://www.versant.fr
[email protected] <mailto:[email protected]>
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
Offline synchronisation design issues
Hi all,
I want to develop an application with JDO and MS SQL server which supports
offline synchronisation (briefcase model). Users should be able to choose if
they want to work locally, storing the data for instance using the MSDE.
When they reconnect to the central sql server, data should be synchronised
(possibly informing the user that some data cannot by synchronised if
someone else modified the data at a later time) For this application it will
be feasible, because most of the data wont be used / modified concurrently.
I wonder if someone has experience / suggestions on the design /
implementation issues for this type of application. For instance should I
arrange things at the level of the domain classes, or should I use sql
server to synchronize data and letting persistence manager either connect to
SQL server or the local MSDE?
suggestions much appreciated,
ChristiaanThanks Marc,
It would be interesting indeed to know how other developers have dealt with
this, so I hope I get some more reactions on this thread!
"Marc Prud'hommeaux" <[email protected]> schreef in bericht
news:[email protected]...
Christiaan-
We are considering implementing this as a feature in Kodo for an
upcoming release. If you are interested in it, please send a mail to
[email protected] (and reference this newsgroup posting).
In the meantime, you may want to consider using the attach/detach
feature to detach persistent instances from a SQLServer
PersistenceManager, and then re-attach them into some PersistenceManager
using a stand-alone database (like Hypersonic, JDataStore, Pointbase,
etc). This will get you part of the way there, but you will have some
other hurdles to overcome, such as automatic change determination
(possibly by having a "lastModified" timestamp in all your objects), as
well as managing some sort of conflict resolution system for when
multiple changes on the same data cause optimistic locking exceptions.
I know that a number of other Kodo users have been looking into
implementing this sort of this; hopefully they will chime in with their
experiences and insights.
In article <[email protected]>, Christiaan wrote:
Hi all,
I want to develop an application with JDO and MS SQL server which
supports
offline synchronisation (briefcase model). Users should be able tochoose if
they want to work locally, storing the data for instance using the MSDE.
When they reconnect to the central sql server, data should besynchronised
(possibly informing the user that some data cannot by synchronised if
someone else modified the data at a later time) For this application itwill
be feasible, because most of the data wont be used / modifiedconcurrently.
I wonder if someone has experience / suggestions on the design /
implementation issues for this type of application. For instance shouldI
arrange things at the level of the domain classes, or should I use sql
server to synchronize data and letting persistence manager eitherconnect to
SQL server or the local MSDE?
suggestions much appreciated,
Christiaan
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
Now that JDO2 has successfully passed the final ballot is
there any planned date for full JDO2 support in Kodo 4 ?
Thanks in advance,
GuidoChristiaan wrote:
Hi,
I just came across this link
http://weblog.infoworld.com/techwatch/archives/005738.html
Specifically:
"BEA is delaying the release of Kodo 4.0 until the EJB 3 (Enterprise
JavaBeans) specification is finalized, McBride said. That is expected in the
June timeframe. Version 4.0 features support for EJB 3 and JDO 2."
Would have been nice if this was also on the Solarmetric site or did I miss
it?
kind regards,
Christiaan
Yes, I have read some days ago.
And I didn't like it.
At this point, I don't think that BEA has a great commitment/interest on
its JDO2 implementation and on the JDO technology tout-court.
The facts are that the JPA implementation will be open source while JDO2
implementation, i.e. Kodo 4, will "wait" even if JDO2 spec have been
finally approved.
With BEA vote.
Guido. -
[ANN] Maven Kodo Plugin 4.0.0 Released
The maven-kodo-plugin team is pleased to announce the Kodo Plugin 4.0.0-EA2
release!
http://maven-plugins.sourceforge.net/maven-kodo-plugin/
Maven plugin for Solarmetric's Kodo JDO implementation
Changes in this version include:
New Features:
o This version requires Kodo 4.0.0-EA2 jars. Please note that this version is
in an early stage.
To automatically install the plugin, type the following on a single line:
maven plugin:download
-DgroupId=maven-kodo-plugin
-DartifactId=maven-kodo-plugin
-Dversion=4.0.0-EA2
For a manual installation, you can download the plugin here:
http://www.ibiblio.org/maven,http://maven-plugins.sourceforge.net/repository/maven-kodo-plugin/plugins/maven-kodo-plugin-4.0.0-EA2.jar
Have fun!
-The maven-kodo-plugin teamThanks! We'll add a link in our documentation.
-
[ANN] Kodo Plugin 3.2.4 Released
The maven-kodo-plugin team is pleased to announce the Kodo Plugin 3.2.4
release!
http://maven-plugins.sourceforge.net/maven-kodo-plugin/
Maven plugin for Solarmetric's Kodo JDO implementation
Changes in this version include:
New Features:
o This version requires Kodo 3.2.4 jars.
For a manual installation, you can download the plugin here:
http://prdownloads.sourceforge.net/maven-plugins/maven-kodo-plugin-3.2.4.jar?download
Have fun!
-The maven-kodo-plugin teamNono-
Thix comes from a faulty interaction between the MySQL JDBC Driver
and the JBoss DataSource. All reports are that this warning has no
effect, and can be ignored.
Please let us know if it is causing serious problems for you. Also,
ensure that you are using the latest version of Kodo.
In article <bnqv0k$9p5$[email protected]>, Nono Garc__a wrote:
>
We are evaluating Kodo but we have various problems and a few information
to solve them.
For example: JBoss log: WARN [Runtime] java.sql.SQLException: You cannot
rollback with autocommit set!
I don't know set autocommit off. It's kodo configuration? It's mysql
configuration? How i configure it?
Thanks.--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
!! Open-source extension to Kodo released !!
Hello fellow Kodo users,
You guys that are bold enough to want the cutting edge in Kodo software
are my target audience here... (repost from main news group)
I've been working with Kodo since it was created, and my employer has been
generous enough to allow me to open-source my work. My goal was to make
Kodo / JDO easy to use for the other developers on my team, without
sacrificing any of the power of the JDO spec. The result is
http://jstomp.sourceforge.net/. Here you will find a robust bytecode
enhancer which makes working with Kodo a breeze. You think your code is
clean now? Wait until you see what you can do with Stomp.
We've been using this enhancer in production internally for over a year,
with great results. We're using Stomp in an appserver (JBoss), connecting
to multiple legacy databases, and everything is running smoothly. I
convinced my employer to open this code up to the Kodo community, in the
hope that one or two quality developers on this list will adopt this
technology and contribute to it's success.
So... if you are new to Kodo, forget this. If you've been using Kodo for
a while, check this out. It rocks. I'm always open to questions /
comments.
Eric Lindauer
[email protected]Sorry Romu, but this against the CoC and [Terms of use|http://www.sun.com/termsofuse.jsp#g2_1] here.
-
Error while configuring kodo to lookup a datasource
We had a working application using EEPersistenceManagerFactory
I changed the kodo.properties to lookup a non XA JDBC datasource.
After that the application is working fine (it creates
,updates,deletes,finds record in the DB)
but SystemOut.log has the following error for every operation
We are using Kodo 2.5.0, Websphere 5.0 and Oracle 8
How can we avoid getting this error ?.
We tried to find any property on the Websphere datasource which can be
altered to avoid this error but no luck.
Thanks
Paresh
[10/7/03 15:30:45:467 IST] 3d8b2d1a MCWrapper E J2CA0081E: Method
destroy failed while trying to execute method destroy on ManagedConnection
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl@437f6d23 from resource
<null>. Caught exception: com.ibm.ws.exception.WsException: DSRA0080E: An
exception was received by the Data Store Adapter. See original exception
message: Cannot call 'cleanup' on a ManagedConnection while it is still in
a transaction..
at
com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:222)
at
com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:172)
at
com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(AdapterUtil.java:182)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(WSRdbManagedConnectionImpl.java:1826)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.destroy(WSRdbManagedConnectionImpl.java:1389)
at com.ibm.ejs.j2c.MCWrapper.destroy(MCWrapper.java:1032)
at
com.ibm.ejs.j2c.poolmanager.FreePool.returnToFreePool(FreePool.java:259)
at com.ibm.ejs.j2c.poolmanager.PoolManager.release(PoolManager.java:777)
at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:1304)
at
com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEventListener.java:195)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionClosedEvent(WSRdbManagedConnectionImpl.java:843)
at
com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnection.java:569)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:132)
at
com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.close(SQLExecutionManagerImpl.java:814)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java(Inlined
Compiled Code))
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java(Compiled
Code))
at
com.solarmetric.kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.java(Compiled
Code))
at
com.solarmetric.kodo.runtime.StateManagerImpl.preSerialize(StateManagerImpl.java:784)
at com.paresh.core.vo.Release.jdoPreSerialize(Release.java)
at com.paresh.core.vo.Release.writeObject(Release.java)
at java.lang.reflect.Method.invoke(Native Method)
at
com.ibm.rmi.io.IIOPOutputStream.invokeObjectWriter(IIOPOutputStream.java:703)
at com.ibm.rmi.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:671)
at
com.ibm.rmi.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:146)
at
com.ibm.rmi.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:217)
at com.ibm.rmi.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:144)
at com.ibm.rmi.iiop.CDROutputStream.write_value(CDROutputStream.java:1590)
at com.ibm.rmi.iiop.CDROutputStream.write_value(CDROutputStream.java:1107)
at
com.paresh.core.interfaces._EJSRemoteStatelessValidation_da16513c_Tie.findCorrectionAction(_EJSRemoteStatelessValidation_da16513c_Tie.java:309)
at
com.paresh.core.interfaces._EJSRemoteStatelessValidation_da16513c_Tie._invoke(_EJSRemoteStatelessValidation_da16513c_Tie.java:104)
at
com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:582)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:437)
at com.ibm.rmi.iiop.ORB.process(ORB.java:320)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1544)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2063)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:592)
kodo.properties
com.solarmetric.kodo.LicenseKey=
#com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=java:/TransactionManager
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=TransactionFactory
TransactionManagerMethod=com.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager
#com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.InvocationManagedRuntime
com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.AutomaticManagedRuntime
#javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory
javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.ee.EEPersistenceManagerFactory
javax.jdo.option.ConnectionFactoryName=ds/kodo/DataSource1
javax.jdo.option.Optimistic=true
javax.jdo.option.RetainValues=true
javax.jdo.option.NontransactionalRead=true
#com.solarmetric.kodo.DataCacheClass=com.solarmetric.kodo.runtime.datacache.plugins.CacheImpl
# Changing these to a non-zero value will dramatically increase
# performance, but will cause in-memory databases such as Hypersonic
# SQL to never exit when your main() method exits, as the pooled
# connections in the in-memory database will cause a daemon thread to
# remain running.
javax.jdo.option.MinPool=5
javax.jdo.option.MaxPool=10We do have a makeTransientAll() before the object returns from Session
Bean.
We also tried the JCA path
After installing the JCA RAR and doing a lookup for
PersistenceManagetFactory the same code is not throwing any exception.
The exception is thrown only if datasource is used.
Thanks
Paresh
Marc Prud'hommeaux wrote:
Paresh-
It looks like you are returning a collection of instances from an EJB,
which will cause them to be serialized. The serialization is happening
outside the context of a transaction, and Kodo needs to obtain a
connection. Websphere seems to not like that.
You have a few options:
1. Call makeTransientAll() on all the instances before you return them
from your bean methods
2. Manually instantiate all the fields yourself before sending them
back. You could use a bogus ObjectOutputStream to do this.
3. In 3.0, you can use the new detach() API to detach the instances
before sending them back to the client.
In article <[email protected]>, Paresh wrote:
We had a working application using EEPersistenceManagerFactory
I changed the kodo.properties to lookup a non XA JDBC datasource.
After that the application is working fine (it creates
,updates,deletes,finds record in the DB)
but SystemOut.log has the following error for every operation
We are using Kodo 2.5.0, Websphere 5.0 and Oracle 8
How can we avoid getting this error ?.
We tried to find any property on the Websphere datasource which can be
altered to avoid this error but no luck.
Thanks
Paresh
[10/7/03 15:30:45:467 IST] 3d8b2d1a MCWrapper E J2CA0081E: Method
destroy failed while trying to execute method destroy on ManagedConnection
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl@437f6d23 from resource
<null>. Caught exception: com.ibm.ws.exception.WsException: DSRA0080E: An
exception was received by the Data Store Adapter. See original exception
message: Cannot call 'cleanup' on a ManagedConnection while it is still in
a transaction..
at
com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:222)
at
com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:172)
at
com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(AdapterUtil.java:182)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(WSRdbManagedConnectionImpl.java:1826)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.destroy(WSRdbManagedConnectionImpl.java:1389)
at com.ibm.ejs.j2c.MCWrapper.destroy(MCWrapper.java:1032)
at
com.ibm.ejs.j2c.poolmanager.FreePool.returnToFreePool(FreePool.java:259)
at com.ibm.ejs.j2c.poolmanager.PoolManager.release(PoolManager.java:777)
at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:1304)
at
com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEventListener.java:195)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionClosedEvent(WSRdbManagedConnectionImpl.java:843)
at
com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnection.java:569)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:132)
at
com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.close(SQLExecutionManagerImpl.java:814)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.release(JDBCStoreManager.java(Inlined
Compiled Code))
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java(Compiled
Code))
at
com.solarmetric.kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.java(Compiled
Code))
at
com.solarmetric.kodo.runtime.StateManagerImpl.preSerialize(StateManagerImpl.java:784)
at com.paresh.core.vo.Release.jdoPreSerialize(Release.java)
at com.paresh.core.vo.Release.writeObject(Release.java)
at java.lang.reflect.Method.invoke(Native Method)
at
com.ibm.rmi.io.IIOPOutputStream.invokeObjectWriter(IIOPOutputStream.java:703)
at com.ibm.rmi.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:671)
at
com.ibm.rmi.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:146)
at
com.ibm.rmi.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:217)
at com.ibm.rmi.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:144)
at com.ibm.rmi.iiop.CDROutputStream.write_value(CDROutputStream.java:1590)
at com.ibm.rmi.iiop.CDROutputStream.write_value(CDROutputStream.java:1107)
at
com.paresh.core.interfaces._EJSRemoteStatelessValidation_da16513c_Tie.findCorrectionAction(_EJSRemoteStatelessValidation_da16513c_Tie.java:309)
at
com.paresh.core.interfaces._EJSRemoteStatelessValidation_da16513c_Tie._invoke(_EJSRemoteStatelessValidation_da16513c_Tie.java:104)
at
com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:582)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:437)
at com.ibm.rmi.iiop.ORB.process(ORB.java:320)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1544)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2063)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:592)
kodo.properties
com.solarmetric.kodo.LicenseKey=
#com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=java:/TransactionManager
>>
>
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=TransactionFactory
>>
>
TransactionManagerMethod=com.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager
>>
>>
>
#com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.InvocationManagedRuntime
>>
>
com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.AutomaticManagedRuntime
>>
>>
>
#javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory
>>
>
javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.ee.EEPersistenceManagerFactory
>>
javax.jdo.option.ConnectionFactoryName=ds/kodo/DataSource1
javax.jdo.option.Optimistic=true
javax.jdo.option.RetainValues=true
javax.jdo.option.NontransactionalRead=true
#com.solarmetric.kodo.DataCacheClass=com.solarmetric.kodo.runtime.datacache.plugins.CacheImpl
>>
>>
# Changing these to a non-zero value will dramatically increase
# performance, but will cause in-memory databases such as Hypersonic
# SQL to never exit when your main() method exits, as the pooled
# connections in the in-memory database will cause a daemon thread to
# remain running.
javax.jdo.option.MinPool=5
javax.jdo.option.MaxPool=10
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com -
Kodo and tangosol integration: ClassCastException in TangosolQueryCache
Hello.
I have tried to prepare my weblogic environment to work with kodo jdo 3.4.0 and tangosol coherence.
So, i prepare kodo's ra.xml as
<config-property>
<description>DataCache.</description>
<config-property-name>DataCache</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>tangosol(TangosolCacheName=dist-kodo)</config-property-value>
</config-property>
<config-property>
<description>Plugin used to cache query results loaded from the data store. Must implement kodo.datacache.QueryCache.</description>
<config-property-name>QueryCache</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>tangosol(TangosolCacheName=dist-kodo)</config-property-value>
</config-property>
<config-property>
<description>Remote Commit Provider.</description>
<config-property-name>RemoteCommitProvider</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>sjvm</config-property-value>
</config-property>
When i start weblogic 8.1 i have found in STDOUT
* Tangosol Coherence(tm): Enterprise Edition is licensed by Tangosol, Inc.
* License details are available at: http://www.tangosol.com/license.jsp
* Licensed for evaluation use with the following restrictions:
* Effective Date : 1 Sep 2006 00:00:00 GMT
* Termination Date : 1 Nov 2006 00:00:00 GMT
* A production license is required for production use.
* Copyright (c) 2000-2006 Tangosol, Inc.
Tangosol Coherence Version 3.2/357 (Pre-release)
2006-09-11 17:43:49.303 Tangosol Coherence 3.2/357 (Pre-release) <Info> (thread=main, member=n/a): sun.misc.AtomicLong is not supported on this JVM; using a syncrhonized counter.
but when i trying to use datacache=tangosol, have ClassCastException
2006-09-11 17:45:57.253 Tangosol Coherence 3.2/357 (Pre-release) <Error> (thread=DistributedCache:EventDispatcher, member=4): An exception occurred while dispatching the following event:
CacheEvent: MapListenerSupport$FilterEvent{DistributedCache$BinaryMap deleted: key=Binary(length=141, value=0x0BACED00057372000C6B6F646F2E7574696C2E4964DDFCC3A1DB13765D0300024A000269644C00095F747970654E616D657400124C6A6176612F6C616E672F537472696E673B78700000000000000001740039636F6D2E626561722E66692E74726164656875622E646F6D61696E2E627573696E6573732E436C656172616E6365437573746F6D65724A444F78), value=null, filters=[MapEventFilter(mask=DELETED)]}
2006-09-11 17:45:57.253 Tangosol Coherence 3.2/357 (Pre-release) <Error> (thread=DistributedCache:EventDispatcher, member=4): The following exception was caught by the event dispatcher:
2006-09-11 17:45:57.253 Tangosol Coherence 3.2/357 (Pre-release) <Error> (thread=DistributedCache:EventDispatcher, member=4):
java.lang.ClassCastException
at kodo.datacache.TangosolQueryCache.entryDeleted(TangosolQueryCache.java:291)
at com.tangosol.util.MapEvent.dispatch(MapEvent.java:199)
at com.tangosol.util.MapEvent.dispatch(MapEvent.java:164)
at com.tangosol.util.MapListenerSupport.fireEvent(MapListenerSupport.java:550)
at com.tangosol.coherence.component.util.SafeNamedCache.translateMapEvent(SafeNamedCache.CDB:7)
at com.tangosol.coherence.component.util.SafeNamedCache.entryDeleted(SafeNamedCache.CDB:1)
at com.tangosol.util.MapEvent.dispatch(MapEvent.java:199)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$ViewMap$ProxyListener.dispatch(DistributedCache.CDB:22)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.DistributedCache$ViewMap$ProxyListener.entryDeleted(DistributedCache.CDB:1)
at com.tangosol.util.MapEvent.dispatch(MapEvent.java:199)
at com.tangosol.coherence.component.util.CacheEvent.run(CacheEvent.CDB:18)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service$EventDispatcher.onNotify(Service.CDB:14)
at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:35)
at java.lang.Thread.run(Thread.java:534)
2006-09-11 17:45:57.253 Tangosol Coherence 3.2/357 (Pre-release) <Error> (thread=DistributedCache:EventDispatcher, member=4): (The service event thread has logged the exception and is continuing.)
When i have a look to TangosolQueryCache.jad (kodo part, decompiled from .class with jad) i found
public void entryDeleted(MapEvent evt)
QueryKey queryKey = (QueryKey)evt.getKey();
boolean isExpired = true;
keyRemoved(queryKey, isExpired);
but in com.tangosol.util.MapEvent (tangosol.jar)
public Object getKey()
return m_oKey;
So, in TangosolQueryCache tries to classcast Object to QueryKey.
Any ideas how to resolve that problem?
And in general, where i can find example of integration kodo datacache with tangosol coherence?
At http://edocs.bea.com/kodo/docs40/full/html/ref_guide_caching.html examples is not so full.
Thanks for answer.Hi Pavel,
Key in this event is an instance of kodo.util.Id:
00: 0B AC ED 00 05 73 72 00 0C 6B 6F 64 6F 2E 75 74 .’..sr..kodo.ut
10: 69 6C 2E 49 64 DD FC C3 A1 DB 13 76 5D 03 00 02 il.Id�?üáÛ.v]...
20: 4A 00 02 69 64 4C 00 09 5F 74 79 70 65 4E 61 6D J..idL.._typeNam
30: 65 74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 et..Ljava/lang/S
40: 74 72 69 6E 67 3B 78 70 00 00 00 00 00 00 00 01 tring;xp........
50: 74 00 39 63 6F 6D 2E 62 65 61 72 2E 66 69 2E 74 t.9com.bear.fi.t
60: 72 61 64 65 68 75 62 2E 64 6F 6D 61 69 6E 2E 62 radehub.domain.b
70: 75 73 69 6E 65 73 73 2E 43 6C 65 61 72 61 6E 63 usiness.Clearanc
80: 65 43 75 73 74 6F 6D 65 72 4A 44 4F 78 eCustomerJDOx so, either kodo.datacache.TangosolQueryCache is listening to a wrong cache, or application attempts to remove something which is not removeable - did you try asking BEA support about this ?
Anyway, this exception doesn't affect anything - The service event thread has logged the exception and is continuing.
Regards,
Dimitri -
11g Release 1 Patch Set 3 (WLS 10.3.4)
Hi.
While creating new server in OEPE Helios(11.1.1.6) I found that WLS 10.3.4 is available for selection. However I didnt find any information neither links to download it. Only 10.3.3 is available.
When and where it is\would be available for download?
Thanksfrf,
Hello, as part of the WebLogic 10.3.4 release on friday - we verified JPA 2.0 functionality for enterprise users using JPA as their persistence pattern. The main issues were JPA 2.0 XSD validation and JPA 2.0 container managed persistence unit injection.
The details of the following post outline what happens out of the box and how JPA 2.0 can be officially enabled on JEE5 compliant WebLogic 10.3.4 install +(with or without the QWG8 patch)+
In 10.3.3.0 you were required to use the FilteringClassLoader via the *<wls:prefer-application-packages>* addition to your application managed persistence unit - this workaround is now deprecated and not required in 10.3.4.0 for both application and container managed persistence contexts.
Specifically we will start retesting EE applications using a SSB injected @PersistenceContext container managed JTA transactional JPA 2.0 persistence units with/without JPA 2.0 XSD elements.
I verified the server and it is using SVN rev# *8635 from 6 Dec 2010* https://fisheye2.atlassian.com/changelog/eclipselink/?cs=8635
Essentially in order to enable JPA 2.0 functionality on WebLogic 10.3.4 shipped on 14 Jan 2011 - you apply the QWG8 patch below or manually edit your server classpath to put the JPA 2.0 persistence specification API jar and the com.oracle.jpa2support_1.0.0.0_2-0.jar ahead of the other liibraries on the classpath.
commEnv.cmd: line 67
@rem Set BEA Home
set BEA_HOME=C:\opt\wls1034r20110115
@rem Enable JPA 2.0 functionality on WebLogic Server 10.3.4 with the following patch line for commEnv.cmd:67
set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jarEverything is shipped with WebLogic 10.3.4 but JPA 1.0 is enabled by default so that this JEE5 capable server is backwards compatible with JEE5/JPA1 out of the box. Without the above patch you will see the following.
<15-Jan-2011 5:58:40 o'clock PM EST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 10.3.4.0 Fri Dec 17 20:47:33 PST 2010 1384255 >
[EL Info]: 2011-01-15 18:06:38.082--ServerSession(48997950)--Thread(Thread[[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--EclipseLink, version: Eclipse Persistence Services - 2.1.2.v20101206-r8635
[EL Info]: 2011-01-15 18:06:38.082--ServerSession(48997950)--Thread(Thread[[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--Server: 10.3.4.0
We have the required bundles in the modules directory...
javax.persistence_1.0.0.0_2-0-0.jar (upgraded from 1-0-2)
org.eclipse.persistence_1.0.0.0_2-1.jar (upgraded from 2-0)
A very quick test of a JPA 2.0 container managed app with the following persistence.xml in the ejb.jar works as detailed below.
There are 3 issues we must check.
1) JPA 2.0 XSD parsing errors: as expected there are no more JPA 2.0 schema parsing issues.
2) New JPA 2.0 schema elements like the *<shared-cache-mode>NONE</shared-cache-mode>* element - this passes validation but we need to verify runtime functionality
3) JPA 2.0 runtime API like a entityManager.getMetamodel(); call on the Servlet or Statless session bean
4) JPA 2.0 weaving/instrumentation - Again we need to verify something like weaving of Entities contaiing lazy IndirectLists are weaved properly by the container.
Note: All testing in this post is on a WebLogic 10.3.4.0 install out-of-the-box. The only modification I made was in creating a derby 10.5.3.0 JTA global datasource "localJTA" on the server - and drop a container managed JPA 2.0 app as an EAR in the autodeploy directory on the default user domain.
<persistence version="2.0" 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_2_0.xsd">
<persistence-unit name="example" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <!-- we will default to Kodo without specifying the provider -->
<jta-data-source>localJTA</jta-data-source>
<shared-cache-mode>NONE</shared-cache-mode><!-- shared-cache-mode must come after any class definitions (usually SE only) - the JPA schema is ordered -->
<properties>
<property name="eclipselink.target-server" value="WebLogic_10"/>
<property name="eclipselink.target-database" value="Derby"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<!-- new for 10.3.4.0 http://wiki.eclipse.org/EclipseLink/Examples/JPA/Logging#Server_Logging -->
<property name="eclipselink.logging.logger" value="DefaultLogger"/>
<!-- turn off DDL generation after the model is stable -->
<!-- property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="database"/-->
</properties>
</persistence-unit>For 3) we get the following exception out of the box on a servlet if we do not apply the above mentioned patch below - because the container defaults to Java EE 5 functionality - or JPA 1.0
http://download.oracle.com/docs/cd/E18476_01/doc.220/e18480/weblogicchap.htm
java.lang.NoSuchMethodError: javax/persistence/EntityManager.getMetamodel()Ljavax/persistence/metamodel/Metamodel;
at org.eclipse.persistence.example.jpa.server.weblogic.enterprise.presentation.FrontController.processGliderComm
and(FrontController.java:346)
or 3) The same exception if we try to run JPA 2.0 on the DI entityManager from the SSB in the EJB container classLoader
javax.ejb.EJBException: EJB Exception: : java.lang.NoSuchMethodError: javax/persistence/EntityManager.getMetamodel()Ljavax/persistence/metamodel/Metamodel;
+ at org.eclipse.persistence.example.jpa.server.business.ApplicationService.insertObjects(ApplicationService.java:66)+
+ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)+
+ at java.lang.reflect.Method.invoke(Method.java:597)+
+ at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)+
+..+
+ at $Proxy74.insertObjects(Unknown Source)+
+ at org.eclipse.persistence.example.jpa.server.business.ApplicationService_5ptwty_ApplicationServiceLocalImpl.__WL_invoke(Unknown Source)+
We also get the Kodo/OpenJPA provider when we attempt to weave.
+<openjpa-1.1.1-SNAPSHOT-r422266:965591 fatal user error> org.apache.openjpa.util.MetaDataException: "org.eclipse.persistence.example.jpa.server.business.Cell.id" declares generator name "EL_SEQUENCE_CELL", but uses the AUTO generation type. The only valid generator names under AUTO are "uuid-hex" and "uuid-string".+
+ at org.apache.openjpa.persistence.AnnotationPersistenceMetaDataParser.getGeneratedValueStrategy(AnnotationPersistenceMetaDataParser.java:1226)+
Therefore there is still a little bit of configuration required.
Enabling JPA2 support
1) install the QWG8 patch, or
2) manually add the com.oracle.jpa2support_1.0.0.0_2-0.jar ahead of the server classpath by following the instructions in the documentation at
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309
or doing it manually by modifying the following line
C:\opt\wls10340_pub110115\wlserver_10.3\common\bin\commEnv.cmd
set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jar
Results
The following code
@Local
@Stateless
public class ApplicationService implements ApplicationServiceLocal {
@PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION)
private EntityManager entityManager;
public boolean insertObjects(List<Cell> classes) {
try {
for(int i=0; i< classes.size(); i++) {
entityManager.persist(classes.get(i));
System.out.println("JPA 2.0 Metamodel: " + entityManager.getMetamodel()); ...prints out the JPA 2.0 EntityManager dependency injected into the SSB proxy for the life of the transaction in the function
JPA 2.0 Metamodel: MetamodelImpl@34817119 [ 5 Types: , 2 ManagedTypes: , 2 EntityTypes: , 0 MappedSuperclassTypes: , 0 EmbeddableTypes: ]+
+[EL Finer]: 2011-01-15 22:36:00.33--UnitOfWork(34913451)--Thread(Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--TX beforeCompletion callback, status=STATUS_ACTIVE+
You can see that when we debug the stateless session bean $Proxy that has our injected EntityManager...
this ApplicationService_5ptwty_Impl (id=11616)
__WL_EJBContext SessionEJBContextImpl (id=11654)
entityManager $Proxy73 (id=11639)
h TransactionalEntityManagerProxyImpl (id=11638)
appName "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEAR" (id=11513)
closeMethod Method (id=11663)
moduleName "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB.jar" (id=11515)
persistenceUnit PersistenceUnitInfoImpl (id=11665)
persistenceUnitName "org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEAR#org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB.jar#example" (id=11666)
queryMethods HashSet<E> (id=11668)
transactionAccessMethod Method (id=11669)
transactionalMethods HashSet<E> (id=11670)
txHelper TransactionHelperImpl (id=11523)
txRegistry ServerTransactionManagerImpl (id=11524)
unqualifiedPersistenceUnitName "example" (id=11672) ...no longer complains about an unknown getMetamodel() JPA 2.0 method signature
Oracle WebLogic Server 11gR1 PatchSet 3 r20110115 at localhost [Oracle WebLogic Server]
Java HotSpot(TM) Client VM[localhost:8453]
Daemon Thread [[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'] (Running)
Daemon Thread [[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'] (Suspended)
TransactionalEntityManagerProxyImpl.invoke(Object, Method, Object[]) line: 18
$Proxy59.getMetamodel() line: not available [local variables unavailable]
ApplicationService_5ptwty_Impl(ApplicationService).insertObjects(List<Cell>) line: 60
.. JdkDynamicAopProxy.invoke(Object, Method, Object[]) line: 204
$Proxy71.insertObjects(List) line: not available
ApplicationService_5ptwty_ApplicationServiceLocalImpl.__WL_invoke(Object, Object[], int) line: not available
SessionLocalMethodInvoker.invoke(BaseLocalObject, MethodDescriptor, Object[], int, String, Class<?>) line: 39
ApplicationService_5ptwty_ApplicationServiceLocalImpl.insertObjects(List) line: not available
FrontController.generateGlider(PrintWriter) line: 252
.. FrontController(HttpServlet).service(ServletRequest, ServletResponse) line: 820
StubSecurityHelper$ServletServiceAction.run() line: 227
.. ExecuteThread.run() line: 176
arg1 Method (id=11511)
clazz Class<T> (javax.persistence.EntityManager) (id=8312)
name "getMetamodel" (id=11543)
returnType Class<T> (javax.persistence.metamodel.Metamodel) (id=11545) For 4) Weaving is occuring as expected on either the JPA 1.0 or JPA 2.0 entities. We check this by either checking that our Entity is an instanceof org.eclipse.persistence.internal.weaving.PersistenceWeaved interface, or debug into the Entity and look for our bytcode instrumented weaved fields that start with _persistence*. The question is - we need a weaved field or weaved function that was introduced for JPA 2.0
[4] Cell (id=11571)
_persistence_fetchGroup null
_persistence_primaryKey null
_persistence_session null
_persistence_shouldRefreshFetchGroup false
aCellAttribute null
id null
left null
peers HashSet<E> (id=11572)
map HashMap<K,V> (id=11575)
com.oracle.jpa2support_1.0.0.0_2-0.jar forensicsI had a look at the patch jar com.oracle.jpa2support_1.0.0.0_2-0.jar that WebLogic 10.3.4 ships with that allows installers to enable JPA 2.0 (JSR-317) support to superceed the default JPA 1.0 (JSR-220) support. It looks like the container proxy code for container managed EntityManagerFactory and EntityManager $Proxy objects has been updated so that a JPA 2.0 EntityManager $Proxy object get injected with the proper API level object via the InvocationHandlerFactory, FactoryInterceptor. The Query proxy has been updated as well. There is a fix for Kodo(OpenJPA) and OpenJPA related to the recent change and deprecation of certain functions of those providers. The EclipseLink JPA 2.0 provider (as the provider for TopLink) did not need weblogic changes beyond placing the JPA javax.peristence 2.0 specification jar higher on the classpath.
The root EclipseLink tracking bug is 334468
https://bugs.eclipse.org/bugs/show_bug.cgi?id=334468
OTN downloadhttp://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html
Patching
http://download.oracle.com/docs/cd/E18476_01/doc.220/e18480/weblogicchap.htm
Documentationhttp://download.oracle.com/docs/cd/E17904_01/web.1111/e13852/toc.htm
Supported Oracle WebLogic Server Versionshttp://download.oracle.com/docs/cd/E15315_06/help/oracle.eclipse.tools.weblogic.doc/html/SupportedServerVersions.html
TopLink JPA 2.0 Specifichttp://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309
see related
JPA 2: Reverify JPA 2.0 XSD support in persistence.xml on AM/CM app on WebLogic 10.3.3.0
http://bugs.eclipse.org/331569
JPA 2.0: Add WebLogic 10.3 configuration process to enable the JPA 2.0 library functionality - updated
http://bugs.eclipse.org/296271
http://en.wikipedia.org/wiki/Oracle_WebLogic_Server - updated
JPA: Add downloadable 60k weblogic.EAR to wiki page (outside of SVN) - reopened
http://bugs.eclipse.org/294745
JPA: support WebLogic 10.3.4.0 introduction of new JPA MBean that changes the default JPA provider
http://bugs.eclipse.org/312824
JPA: Update tutorial wiki for WebLogic 10.3 to match the Oracle WebLogic 11g 10.3.3.0 - assigned
http://bugs.eclipse.org/310849
To be answered
OTN Post: WebLogic 10.0 + JPA 2.0 = errors - updated
Re: WebLogic 10.0 + JPA 2.0 = errors
Deploy Hibernate based EAR file on Weblogic 10.3.3?
OTN Post: Default JPA provider for Weblogic Server 10.3.2 (11g) - updated
Default JPA provider for Weblogic Server 10.3.2 (11g)
OTN Post: Hibernate 3.6 Final (JPA 2.0) + WL 10.3.x :Unable to deploy sample appn - updated
Hibernate 3.6 Final (JPA 2.0) + WL 10.3.x :Unable to deploy sample appn
WebLogic 10.0 + JPA 2.0 = errors
OTN Post: EJB with Hibernate On Weblogic - updated
Re: EJB with Hibernate On Weblogic
OTN Post: OEPE 1.6 - Oracle WebLogic Server 11gR1 PatchSet 3 requres WLS 10.3.4 - answered
OEPE 1.6 - Oracle WebLogic Server 11gR1 PatchSet 3 requres WLS 10.3.4
OTN Post: EJB with Hibernate On Weblogic - updated
Re: EJB with Hibernate On Weblogic
OTN Post: OpenJPA_2.0 NoSuchMethod error (getValidationMode()) - updated
OpenJPA_2.0 NoSuchMethod error (getValidationMode())
JPA 2.0 features used on WebLogic even if they are not available at runtime - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189205
Option to enable JPA 2.0 for dev WebLogic - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189348
False-positive error badge on project with JPA targeting WebLogic - notified
http://netbeans.org/bugzilla/show_bug.cgi?id=189626
Giving up on Hibernate (for now), trying EclipseLink...
http://forums.netbeans.org/post-94817.html
http://blogs.sun.com/arungupta/entry/which_java_ee_6_app
Eclipselink 2.0 + WebLogic 10 => No joy (Unable to get Eclipse link 2.0 working with WebLogic 10) - answered
http://www.eclipse.org/forums/index.php?t=msg&goto=644000&S=40e13288641c0af5dc8489343b896348#msg_644000
eclipselink-users Problem of eclipselink upgrade (2.0.2) - WebLogic 10.3.3.0 - answered
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04631.html
Re: EclipseLink + JPA 2 in Weblogic 10.3.0
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04375.html - answered below
Re: eclipselink-users Problems with Eclipselink 2 (JPA 2.0) & WebLogic 10,
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05609.html
[eclipselink-users] Problems with Eclipselink 2 (JPA 2.0) & WebLogic 10 - answered
http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05639.html
To be Deprecated
JPA 2: Reverify JPA 2.0 XSD support in persistence.xml on AM/CM app on WebLogic 10.3.3.0
http://bugs.eclipse.org/331569
JPA 2.0: Add WebLogic 10.3 configuration process to enable the JPA 2.0 library functionality
http://bugs.eclipse.org/296271
WebLogic 10.3 availability?
/ Michael O'Brien
http://www.eclipselink.org -
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,
AlanCan 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
Maybe you are looking for
-
on my itunes library my albums are all sorted but when i put onto my ipod touch (4th Gen) it seems to duplicate i have checked everything and there are no spaces in the information my question is how do isort it because these things drive me mad i w
-
Could not find .java and .class files...
I am working on Windows Vista operating system. I am able to access the .java which I created and also .class files from the command prompt. But I am not able to find those files in the bin folder in Windows Explorer. I want to delete some .java and
-
Oracle 11g R2 on Windows 7 - OUI Error 10150
Hi, I installed oracle 11g r2 on windows 7. Then I wanted to add Label security and Database vault to existing installation. OUI from installed location raised error 10150. Other threads indicated running OUI from installation media. But only have Se
-
No P4040L statement account type is defined in chart of accounts 4040
Hello, I have maintained account group P & L in SPRO>Financial Accounting>General Ledger accounting>Preparation>Defined Account Group. When trying to create G/L account FS00 it throws error message No P4040L statement account type is defined in chart
-
Hi All, Is there a way to block caller-id on ephone-dn level for external calls and keep it for internal calls (i.e. dialing other extensions on the same site) as the caller-id block command hide it for all calls (external & internal). Please note th