[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider
[ https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikram Bhatia updated OPENJPA-230: -- Attachment: testcase.zip JUnit testcase. Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider --- Key: OPENJPA-230 URL: https://issues.apache.org/jira/browse/OPENJPA-230 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.0, 0.9.6, 0.9.7 Reporter: Vikram Bhatia Priority: Minor Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, soln.diff, testcase.zip When an application is commiting a transaction and then terminating, often not all events regarding Data Cache are dispatched by the TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. In this way some cache synchronization is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi Philippe,
It looks like your attachment was dropped by the mailing list so I'm
guessing a little here. I did try setting all of this up from scratch with
one of my Eclipse projects, here's what I did.
Downloaded openjpa-project-0.9.7-incubating-source.zip and
openjpa-project-0.9.7-incubating-binary.zip and extract them (directory
/home/mikedd/downloads in my case).
Add the openjpa-* jar to my Eclipse project's classpath as an external jar.
I'm cheating a bit and picking up the other dependencies from my maven
repository, but that shouldn't matter.
Create a run definition for your application. Add
-javaagent:/home/mikedd/download/openjpa-project-0.9.7-incubating/openjpa-
0.9.7-incubating.jar as a vm arg. On the source tab add the source
directories for each OpenJPA subproject (ie /home/mikedd/downloads/openjpa-
project-0.9.7-incubating-source/openjpa-persistence/src/main/java ).
I think that's about it then you should be able to run your application,
debug OpenJPA or your entities if you want, etc. The mailing list has
rejected my message whenever I attach screenshots so I'll send them directly
to you instead.
Hope this helps,
-Michael Dick
On 5/20/07, Philippe Alexis [EMAIL PROTECTED] wrote:
Hi Everyone,
Not meaning to hi-jack it, I'll piggy-back on this thread because I've
made some progress setting up
OpenJPA as an Eclipse project thanks to some tips below from Michael. It's
been a long arduous road
over the whole weekend...
I went for compile-time enhancement via an Ant script as a user-defined
builder because as per the
attached screenshot, Eclipse-VM-params.PNG, (I hope having that is not
against the list's policy)
dynamic enhancement via -javaagent:${path_to_openjpa-*.jar} hasn't worked
so far and yields the error
message as shown in Eclipse's Console window. Is it working? I doubt it.
There's no [openjpac] output by Ant.
At least, the end of it says Build Successful.
The other screenshot, Eclipse-BrokerFactory-not-found.png, is where I've
reached stepping through the project
this far, running the Main.java of the Deity example.
You did not name the factory class with the required property
openjpa.BrokerFactory.
Normally this property defaults appropriately; have you forgotten to
include all the OpenJPA jars in your classpath?
Where would that be defined by default?
Would anyone be so kind as to post a similar screenshot of what's required
as Source folders to successfully debug
OpenJPA under Eclipse? I'm probably not too far but it's... late.
J-Philippe.
On 5/17/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in
Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer . With no other
classpath tweaking it enhances the entities in the output directory and
I'm
up and running.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs
-
either one should be able to enhance your entities. I have never used
IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a
cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what
I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use
from
an end users perspective and I don't think this should be the case;
plus I
don't think it'll take much time to fix. While the pain is still fresh
in
my
mind I thought I'd post on how much more painful openjpa is to use in
a
project. If you're short on time, the basic idea is its that bytecode
post
processing stuff thats to blame :). Yes I know its probably faster
that
way
- its just so painful for Java programmers to work with. (And yes I
know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to
get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little
(as
it did me). I don't know about folks on this list but the whole idea
of
having to mess with my maven build gives me the jitters :). When you
get
that far the maven planets are aligned with openjpa, the next hurdle
you
hit is how do you run stuff in your IDE. If like me you use IDEA and
maven
2, the project gets auto-created by default for all projects you work
on.
However
RE: Exception while retrieving the data from database
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
The discriminator type is CHAR but the value is a String. How about
declaring the type as STRING of length 1?
@DiscriminatorColumn(discriminatorType=DiscriminatorType.STRING,
length=1)
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Praveen G [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 19, 2007 8:37 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Exception while retrieving the data from database
Hi,
I am having following two classes, modified the code as follows
@Entity
@Table(name = LOG_DB2)
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
public class A {
@Column(name = LOG_ID)
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private long id;
@Column(name = TAG)
private String tag;
@Column(name = SUBTAG)
private String subtag;
@Column(name = HOST_NAME)
private String hostName;
@Entity
@Table(name = LOG_DB2)
@DiscriminatorValue(value=C)
public class B extends A {
@Column(name = INSTANCE_NAME)
private String instanceName;
@Column(name = DB2_TIMESTAMP)
private Timestamp db2Timestamp;
@Column(name = DB_ALIAS)
private String dbAlias;
@Column(name = DB_PARTITION)
private int partitionNum;
I am facing the problem while retriveing the data from the database, the
following is the code and highlighted the problem area in the code
em=ServiceLocator.getOpenJPASession(audit);
em.getTransaction().begin();
Query q = em.createQuery(select ad from B ad); ListB logs =
q.getResultList(); for (B l : logs) { System.out.println(Host Name is :
+l.getHostName()+ Instance Name is +l.getInstanceName());
em.remove(l); }
em.getTransaction().commit();
em.close();
The following error occurs
0.9.7-incubating nonfatal general error
org.apache.openjpa.persistence.PersistenceException: [IBM][CLI Driver]
CLI0112E Error in assignment. SQLSTATE=22005 at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.
java:3784)
at
org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionar
y.java:373)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59
)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreMana
ger.java:260)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingSt
oreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.jav
a:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:876)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:834)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.ja
va:776)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:257)
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java
:2152)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:251)
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObj
ect(InstanceResultObjectProvider.java:59)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:3
6)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:5
17)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:26
9)
at
com.vormetric.server.dao.audit.hibernate.AuditDAOImpl.purgeDebugMessages
(AuditDAOImpl.java:195)
at
com.vormetric.server.messageanalyzer.MessageAnalyzerManager.purgeDebugMe
ssages(MessageAnalyzerManager.java:113)
at
com.vormetric.server.mgmt.ConsoleManagement.purgeDebugMessages(ConsoleMa
nagement.java:675)
at
com.vormetric.server.mgmt.console.log.LogAnalyzerAction.execute(LogAnaly
zerAction.java:217)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
ocessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:252)
at
[jira] Resolved: (OPENJPA-237) Value.setAliases does not copy alias strings
[ https://issues.apache.org/jira/browse/OPENJPA-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Prud'hommeaux resolved OPENJPA-237. Resolution: Fixed Fix Version/s: 0.9.8 Committed patch. Value.setAliases does not copy alias strings Key: OPENJPA-237 URL: https://issues.apache.org/jira/browse/OPENJPA-237 Project: OpenJPA Issue Type: Bug Components: lib Affects Versions: 0.9.7 Reporter: David Ezzio Fix For: 0.9.8 Attachments: Value.diff The org.apache.openjpa.lib.conf.Value.setAliases method does not copy the array of strings passed as a parameter. As a result, later operations on the Value object's aliases can change the array that the caller is using. This method should be pass by value rather than by reference -- in other words, the method should copy the array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Marc Prud'hommeaux wrote: I think this is a very worthwhile project. James and a few others excoriated me about this issue over beers after JavaOne last week, and, while the bruises from their rhetorical assault are still healing, their observations about the comparative out of the box ease of use OpenJPA compared to other systems definitely bears attention. I hope the bruises heal soon btw :) -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10722953 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
djencks wrote: James, Could extract from this verbiage the scenarios you'd like supported? The simplest scenario is, take any maven 2 project which is using hibernate. Switch the hibernate jars to openjpa jars edit the bits of the persistence.xml that are required and have things work properly in your IDE and maven build without having to resort to explicit bytecode post processing in your build. djencks wrote: Do you need to run tests inside IDEA and have you classes enhanced after IDEA compiles them for you? Do you need to run in a separate jvm, e.g. from maven, and have the classes enhanced as they are loaded? Yes to both djencks wrote: I think the second of these can probably be made to work without any openjpa code changes by doing the same thing geronimo does, running with an enhancer agent that delegates to the openjpa enhancer as appropriate. The enhancer is a good workaround for now, thanks. Though I still think it should be easier for users; things should just work out of the box like they do with hibernate without any secret ninja jvm tweaking, magic class loaders or whatnot. djencks wrote: I'd imagine that if IDEA creates a new classloader for running the tests, and we can get some access to something about it, it ought to be possible to do on the fly enhancement there also. What exactly are the problems with looking at an enhanced class in IDEA? I haven't run into thembut I may not have been trying to debug the enhanced classes but rather openjpa + geronimo. Mostly when you navigate into stack traces, or traverse class relationships in the IDE you end up hitting the 'bytecode' (decompiled view) rather than the source view. -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10723042 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Patrick Linskey-2 wrote: How hard is it to add a reflection/cglib type alternative to the upfront bytecode generation (like hibernate does) to save us from the development-time pain? Not particularly hard. There are a few APIs that would break for some cases, but it's even pretty straightforward to do a subclassing approach for property-based access type without losing much performance -- the only cost in that configuration is with persistent-new instances. -Patrick Awesome - can't wait for it to be supported :) Should I raise a JIRA? -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10723139 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Exception while retrieving the data from database
Hi,
There are semi-related problems with the Discriminator support documented in
OPENJPA-143. It seems that if we veer away from the string-based
discriminators, then we still have a few problems... Sorry, no answers at
the moment. Just sharing the pain...
Kevin
On 5/21/07, Pinaki Poddar [EMAIL PROTECTED] wrote:
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
The discriminator type is CHAR but the value is a String. How about
declaring the type as STRING of length 1?
@DiscriminatorColumn(discriminatorType=DiscriminatorType.STRING,
length=1)
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Praveen G [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 19, 2007 8:37 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Exception while retrieving the data from database
Hi,
I am having following two classes, modified the code as follows
@Entity
@Table(name = LOG_DB2)
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(discriminatorType=DiscriminatorType.CHAR)
@DiscriminatorValue(value=S)
public class A {
@Column(name = LOG_ID)
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private long id;
@Column(name = TAG)
private String tag;
@Column(name = SUBTAG)
private String subtag;
@Column(name = HOST_NAME)
private String hostName;
@Entity
@Table(name = LOG_DB2)
@DiscriminatorValue(value=C)
public class B extends A {
@Column(name = INSTANCE_NAME)
private String instanceName;
@Column(name = DB2_TIMESTAMP)
private Timestamp db2Timestamp;
@Column(name = DB_ALIAS)
private String dbAlias;
@Column(name = DB_PARTITION)
private int partitionNum;
I am facing the problem while retriveing the data from the database, the
following is the code and highlighted the problem area in the code
em=ServiceLocator.getOpenJPASession(audit);
em.getTransaction().begin();
Query q = em.createQuery(select ad from B ad); ListB logs =
q.getResultList(); for (B l : logs) { System.out.println(Host Name is :
+l.getHostName()+ Instance Name is +l.getInstanceName());
em.remove(l); }
em.getTransaction().commit();
em.close();
The following error occurs
0.9.7-incubating nonfatal general error
org.apache.openjpa.persistence.PersistenceException: [IBM][CLI Driver]
CLI0112E Error in assignment. SQLSTATE=22005 at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.
java:3784)
at
org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionar
y.java:373)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59
)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreMana
ger.java:260)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingSt
oreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.jav
a:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:876)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:834)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:756)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.ja
va:776)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:257)
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java
:2152)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:251)
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObj
ect(InstanceResultObjectProvider.java:59)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:3
6)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:5
17)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:26
9)
at
com.vormetric.server.dao.audit.hibernate.AuditDAOImpl.purgeDebugMessages
(AuditDAOImpl.java:195)
at
com.vormetric.server.messageanalyzer.MessageAnalyzerManager.purgeDebugMe
ssages(MessageAnalyzerManager.java:113)
at
com.vormetric.server.mgmt.ConsoleManagement.purgeDebugMessages(ConsoleMa
nagement.java:675)
at
com.vormetric.server.mgmt.console.log.LogAnalyzerAction.execute(LogAnaly
zerAction.java:217)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
ocessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
236)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
Re: Historical Session
Sorry to show my ignorance, but what are historical objects? Thanks! Kevin On 5/18/07, Ricardo Andere de Mello [EMAIL PROTECTED] wrote: ok, I'm sending this message to netmind list too, so they can answer my next question too: * Maybe this is a silly question, but is it possible to place netmind's beankeeper historical structure between OpenJPA and the database backstore? I dont think *any* serious commercial application can avoid historical objects. I think netmind's beankeeper is a great thing, and JPA is a good standard. Mixing both projects would be very cool. ;-) []s, gandhi 2007/5/18, Marc Prud'hommeaux [EMAIL PROTECTED]: Sadly, no. We don't have any built-in support for historical support at this time, although we have thought for a long time that this would be a great feature to have. You can, of course, do it yourself manually with a bunch of persistent Date fields, but I agree that this is pretty cumbersome to have to manage yourself. On May 18, 2007, at 11:27 AM, Ricardo Andere de Mello wrote: Does OpenJPA have something similar to TopLink's AsOfClause ? I've been working for some time with OJB and Hibernate, and I'm work a lot with historical objects. It really sucks to manage lots of classes to build a historical structure of objects and object relations. Netminds beankeeper does a great job about this, but I'd like to adhere to JPA... Any idea of implementing historical objects AND RELATIONS, inside JPA? -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722
Re: [jira] Created: (OPENJPA-240) Persistent field mappings to database supported XML columns
OpenJPA Community, So, is this XML Mapping support interesting to the community? Catalina has been working on a solution for this O/Xml Mapping support and is looking for interest from the community for discussion purposes before possibly contributing it to OpenJPA. We can provide more detail when asked. But, in a nutshell, here's the proposal... We planned to use the JAXB support for doing the XML Mapping. We wanted the programming model to be as close to what is provided by JPA (and OpenJPA) as possible. That is, we were trying to keep the basic idea of O/R Mapping, but apply it to O/XML Mapping. With the XML column support, the embedded class would use XML marshaling to write the data to XML columns and unmarshaling to retrieve the data from XMLcolumns. The path expressions and predicates over the embedded class is converted to XML predicates and XPATH and/or XQuery expressions and pushed down to database. This pushdown would be accomplished by adding to and modifying the DBDictionaries for DB2, Oracle, and SQL Server. At this time, these are the database players (that we know of) that provide the required level of support. A persistent property that maps to an XML column would be annotated by @Persistent, @Column, and @Strategy. The embedded classes would be annotated with JAXB XML binding annotations. In addition, the class that maps to the root of the XML document needs to be annotated by @XmlRootElement. @Strategy annotation requires a value handler to be specified for XMLmarshaling and unmarshaling. OpenJPA would provide a default XML Value Handler. A customer could provide their own XML value handler. Comments and/or suggestions would be appreciated to kickstart this activity. Thanks! Kevin On 5/16/07, Catalina Wei (JIRA) [EMAIL PROTECTED] wrote: Persistent field mappings to database supported XML columns --- Key: OPENJPA-240 URL: https://issues.apache.org/jira/browse/OPENJPA-240 Project: OpenJPA Issue Type: New Feature Components: jdbc Reporter: Catalina Wei Many database systems such as DB2 version 9, Oracle 10g, and SQLServer 2005 have support for XML column types. XML documents can be stored natively in the XML columns in the database. What is OpenJPA's position of supporting the XML columns ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I hope the bruises heal soon btw :) Time heals all wounds. At least, that's what I'm told. On May 21, 2007, at 10:09 AM, James.Strachan wrote: Marc Prud'hommeaux wrote: I think this is a very worthwhile project. James and a few others excoriated me about this issue over beers after JavaOne last week, and, while the bruises from their rhetorical assault are still healing, their observations about the comparative out of the box ease of use OpenJPA compared to other systems definitely bears attention. I hope the bruises heal soon btw :) -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of- post-processing-bytecode-%28another-beg-for-a-simple-reflection- cglib-alternative-like-hibernate%29-tf3770760.html#a10722953 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Nudge on OPENJPA-148 patch 2
I'd really appreciate it if a committer could take a look at the second patch I supplied for openjpa-148. The first patch introduced frequent NPEs which the second patch fixes. The second patch also handles some cases in which a directory to scan is supplied as a file URL. I think that geronimo might be able to ship with openjpa + the 2nd patch and would like to start checking that in using a more official build. many thanks david jencks
[jira] Commented: (OPENJPA-148) Parsing exception while using an exploded archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497575 ] Marc Prud'hommeaux commented on OPENJPA-148: I've gone ahead and applied OPENJPA-148-2.patch. If this works for you, please go ahead and mark this issue as resolved. Parsing exception while using an exploded archive --- Key: OPENJPA-148 URL: https://issues.apache.org/jira/browse/OPENJPA-148 Project: OpenJPA Issue Type: Bug Components: jpa Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 Reporter: Florent BENOIT Priority: Minor Fix For: 0.9.8 Attachments: debug_traces_directorymode.txt, debug_traces_filemode_working.txt, OPENJPA-148-2.patch, OPENJPA-148.patch, stacktrace-error.txt, steps.txt This happens when using OpenJPA as persistence provider for the EasyBeans ObjectWeb container. The error is happening with exploded archive. Exploded means that there is a directory, named entitybean.jar with a folder META-INF which contains a file named persistence.xml, and other directories/files for the classes. It seems that when using this mode, OpenJPA is trying to parse the directory inputstream (which is failing). This exception is not occuring if a jar file is used instead of the exploded mode, but the exploded mode is the default mode for EasyBeans. Note also that this exception don't occur by using Hibernate Entity Manager or Oracle TopLink Essentials as persistence provider. I will attach to this issue a stack trace (with the exploded directory) which fails and at the end with a jar file (which work) And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-130) Streaming LOB support
[
https://issues.apache.org/jira/browse/OPENJPA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497601
]
Patrick Linskey commented on OPENJPA-130:
-
Ignacio Andreu will be working on this issue for the Google Summer of Code
project. It would seem that JIRA only allows me to assign issues to committers,
so I'm assigning it to myself to keep it out of the unassigned queue.
Streaming LOB support
-
Key: OPENJPA-130
URL: https://issues.apache.org/jira/browse/OPENJPA-130
Project: OpenJPA
Issue Type: New Feature
Components: datacache, jdbc, jpa, kernel
Reporter: Patrick Linskey
Assigned To: Patrick Linskey
Fix For: 1.1.0
BLOB and CLOB fields can only be mapped in their entirety in OpenJPA. It
would be nice to support fields of type java.io.InputStream (for BLOBs) and
java.io.Reader (for CLOBs).
The usage pattern could look like so:
@Entity
public class Employee {
...
private InputStream photoStream;
public void setPhotoStream(InputStream in) {
photoStream = in;
}
public InputStream getPhotoStream() {
return photoStream;
}
}
So, when the user wants to provide a stream, she will set the InputStream
field, and when the user wants to obtain a stream, she will use the field.
The behavior of such an implementation would be a bit different than how
other fields work, in that if the user set the stream and then consumed it
within a single transaction, presumably no data would be written out to the
database at commit time. But that is the nature of streams.
(FTR, I think that I stole this idea from an email Craig Russell sent out
years ago.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Historical Session
yes this look something simple, but it is not... see, objects exists in time, so for example, they are not deleted, they are finalized. the worst part are the relationships, because they are historical too... basically you have a start and end date for that object, and the object with end date null is the actual object. everytime you modify an object you clone it, set the end date of the old, and set the start date of the new. imagine now that A points to B. both are historical objects. if B is modified, a new historical object is created. A should point to the new B, not the old one. so you must have a historical id or a historical id object to point at, that is common to all B. []s, gandhi 2007/5/21, Marc Prud'hommeaux [EMAIL PROTECTED]: Something like: select x from Employee x as x was on January 1, 2002 On May 21, 2007, at 11:01 AM, Kevin Sutter wrote: Sorry to show my ignorance, but what are historical objects? Thanks! Kevin On 5/18/07, Ricardo Andere de Mello [EMAIL PROTECTED] wrote: ok, I'm sending this message to netmind list too, so they can answer my next question too: * Maybe this is a silly question, but is it possible to place netmind's beankeeper historical structure between OpenJPA and the database backstore? I dont think *any* serious commercial application can avoid historical objects. I think netmind's beankeeper is a great thing, and JPA is a good standard. Mixing both projects would be very cool. ;-) []s, gandhi 2007/5/18, Marc Prud'hommeaux [EMAIL PROTECTED]: Sadly, no. We don't have any built-in support for historical support at this time, although we have thought for a long time that this would be a great feature to have. You can, of course, do it yourself manually with a bunch of persistent Date fields, but I agree that this is pretty cumbersome to have to manage yourself. On May 18, 2007, at 11:27 AM, Ricardo Andere de Mello wrote: Does OpenJPA have something similar to TopLink's AsOfClause ? I've been working for some time with OJB and Hibernate, and I'm work a lot with historical objects. It really sucks to manage lots of classes to build a historical structure of objects and object relations. Netminds beankeeper does a great job about this, but I'd like to adhere to JPA... Any idea of implementing historical objects AND RELATIONS, inside JPA? -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722
Re: Historical Session
As I've had it explained to me, you would not choose the time in a user-generated or user-visible query. Instead, the user would set the time and associate it with an EntityManager. The time is invisible to normal entity operations, including queries. For each query for a temporal object (the terminology I've heard) the EntityManager would include the appropriate WHERE clauses into the SQL that would select the proper instances based on the time. So a find by primary key, navigation, or query would have the appropriate WHERE clauses generated with no action on the part of the user. In the example below, the A instance doesn't need to worry about which B it refers to, because the B instances corresponding to A's time are also selected automatically, in that both A and B have corresponding temporal WHERE clauses based on the same time. Craig On May 21, 2007, at 3:16 PM, Ricardo Andere de Mello wrote: yes this look something simple, but it is not... see, objects exists in time, so for example, they are not deleted, they are finalized. the worst part are the relationships, because they are historical too... basically you have a start and end date for that object, and the object with end date null is the actual object. everytime you modify an object you clone it, set the end date of the old, and set the start date of the new. imagine now that A points to B. both are historical objects. if B is modified, a new historical object is created. A should point to the new B, not the old one. so you must have a historical id or a historical id object to point at, that is common to all B. []s, gandhi 2007/5/21, Marc Prud'hommeaux [EMAIL PROTECTED]: Something like: select x from Employee x as x was on January 1, 2002 On May 21, 2007, at 11:01 AM, Kevin Sutter wrote: Sorry to show my ignorance, but what are historical objects? Thanks! Kevin On 5/18/07, Ricardo Andere de Mello [EMAIL PROTECTED] wrote: ok, I'm sending this message to netmind list too, so they can answer my next question too: * Maybe this is a silly question, but is it possible to place netmind's beankeeper historical structure between OpenJPA and the database backstore? I dont think *any* serious commercial application can avoid historical objects. I think netmind's beankeeper is a great thing, and JPA is a good standard. Mixing both projects would be very cool. ;-) []s, gandhi 2007/5/18, Marc Prud'hommeaux [EMAIL PROTECTED]: Sadly, no. We don't have any built-in support for historical support at this time, although we have thought for a long time that this would be a great feature to have. You can, of course, do it yourself manually with a bunch of persistent Date fields, but I agree that this is pretty cumbersome to have to manage yourself. On May 18, 2007, at 11:27 AM, Ricardo Andere de Mello wrote: Does OpenJPA have something similar to TopLink's AsOfClause ? I've been working for some time with OJB and Hibernate, and I'm work a lot with historical objects. It really sucks to manage lots of classes to build a historical structure of objects and object relations. Netminds beankeeper does a great job about this, but I'd like to adhere to JPA... Any idea of implementing historical objects AND RELATIONS, inside JPA? -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
[ https://issues.apache.org/jira/browse/OPENJPA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497624 ] Patrick Linskey commented on OPENJPA-243: - The plugin as of r540340 integrates the OpenJPA enhancer with IntelliJ IDEA's build process. It requires IntelliJ IDEA 7.0M1 or more recent. It also requires a recent build of OpenJPA, due to classloader issues in the PCEnhancer. The plugin does not currently validate that it has a satisfactory OpenJPA version. The plugin does not bundle OpenJPA jars inside it; this is intentional. In order to use the plugin, you must have OpenJPA in your module's classpath (which is already a requirement for running any tests with OpenJPA). The plugin will pick up the OpenJPA version in your module and use it. If OpenJPA is not available in the classpath, the plugin should gracefully short-circuit. The plugin will run the enhancer on all persistent types (@Entity, @MappedSuperclass, @Embeddable) in certain of the persistence units in the module being compiled. It will only run on persistence units that either do not define a persistence provider or specify the OpenJPA persistence provider. IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process - Key: OPENJPA-243 URL: https://issues.apache.org/jira/browse/OPENJPA-243 Project: OpenJPA Issue Type: New Feature Components: kernel, third-party Affects Versions: 0.9.0, 0.9.6, 0.9.7 Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT Reporter: Patrick Linskey Assigned To: Patrick Linskey Fix For: 0.9.8 Attachments: OpenJPA-0.1.zip It would be nice if OpenJPA's enhancer could be automatically invoked when compiling persistent types in IntelliJ IDEA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
[ https://issues.apache.org/jira/browse/OPENJPA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497626 ] Patrick Linskey commented on OPENJPA-243: - One missing instruction from the previous comment: the 0.1 plugin piggy-backs on top of the IntelliJ IDEA 7 JPA facet. So, you must have your module set up to use a JPA facet in order for the OpenJPA plugin to run on the classes in the module. IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process - Key: OPENJPA-243 URL: https://issues.apache.org/jira/browse/OPENJPA-243 Project: OpenJPA Issue Type: New Feature Components: kernel, third-party Affects Versions: 0.9.0, 0.9.6, 0.9.7 Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT Reporter: Patrick Linskey Assigned To: Patrick Linskey Fix For: 0.9.8 Attachments: OpenJPA-0.1.zip It would be nice if OpenJPA's enhancer could be automatically invoked when compiling persistent types in IntelliJ IDEA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
