|
|
|
|
Welcome
Guest
| Register
| Login
|
| Index | Recent Threads | Unanswered Threads | Who's Online | User List | Help |
DataNucleus Forum
DataNucleus Support
Enhancement
Thread: Any thoughts on packaging enhanced and unenhanced classes?
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 6 |
|
| Author |
|
Handyman
Newbie US Joined: Jul 12, 2008 Post Count: 3 Status: Offline |
I'm trying to use jdo as a plugin to a development environment that I'm building but I've run into a hiccup with fitting enhancement into my distribution. In short, I've got a situation where I have an interface A and an implementation of that interface, B. I'd like B to be persistable with jdo when jdo is chosen as the persistence implementation but I'd also like B to be persistable with, say, Castor (not Castor JDO) when Castor is chosen. The user gets to select the choice. In order for B to be jpox-persistable, it needs the bytecode enhancement. This adds some problems: * Enhanced classes can confuse a system like Castor that uses reflection to tell what to write. JDO stuff gets added. * More importantly, if the user develops an application that doesn't use jdo, they still need to supply the jdo dependency or else the classloader will complain about B needing it. * I can't even wrap my head around the classloader issues behind having an instance of an enhanced class and a non-enhanced class in the same run. At a minimum, the classes can't be said to be of comparable run-time type. I've spent a lot of time thinking about how to handle this but I've come up with nothing appealing. Run-time enhancement looks like it might be a start but it would also impose a lot of limitations (for example, you still can't mix versions of B). Can anyone suggest a plan here? - David |
||
|
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
Why exactly is Castor getting confused by enhanced code? Also, does it really need to be Castor, e.g. you have existing code hard to migrate to something else that won't get confused? It's been a while since I last touched anything Castor related. It seems many people are using JAXB these days, and Java-XML binding using Eclipse Modeling Framework is also an option. Neither are likely to get confused by enhanced code. And last but not least, there is Datanucleus itself offering storage to XML, see the docs on XML Datastores. I'm not sure how mature that is, though. It uses JAXB for the actual Java-XML binding, by the way. |
||
|
|
Handyman
Newbie US Joined: Jul 12, 2008 Post Count: 3 Status: Offline |
Ignore the statement about Castor being confused. I was the one who was confused about Castor :-) Unfortunately, it was behaving as documented. I've gone back and forth with JAXB, XStream, JDO, Hibernate and a handful of other frameworks in trying to find a persistence or OXM mechanism that met my needs and JDO came pretty close but it looks like the enhancement process may be the killer. I had absurd requirements -- I'm writing an IDE basically, and it generates unsigned applets. The persistence mechanism needs to run untrusted (which excludes all reflection but bean-style reflection) AND needs to be fairly easily swapped-out if the user wants another persistence format. To use JDO, I'd need two versions of each of my libs that had anything persistable because of the byte-code enhancement and I couldn't find a way to make that acceptable to a user. What rules out your suggestions is the requirement that, regardless of the users choice, their 'applet' would need JDO to instantiate anything (even tho its not used!). EMF is a very good suggestion, however. I've been steering clear of it because its basically the last system that I *haven't* become an expert on by reading hundreds of pages of docs but... maybe I'm just so unlucky that its 'the last place I looked'. Yeah, that must be it. Thanks for the help, - David |
||
|
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
their 'applet' would need JDO to instantiate anything Do you mean that you need JDO APIs to instantiate objects from enhanced classes? I can't see why you'd need JDO this way or any other to instantiate objects from enhanced classes. |
||
|
|
Handyman
Newbie US Joined: Jul 12, 2008 Post Count: 3 Status: Offline |
Thanks for your message. This, I guess, fills in a hole in my understanding of how the enhanced classes were used by JDO. I assumed that things were added through the bytecode enhancement that required the jdo libraries at run time (perhaps an unreasonable guess although it still seems logical to me). Given that, maybe I'll come back to JDO some day but I've actually moved on to an easier solution so I won't be able to verify. Thanks again. On a completely different topic, the link in the email, notifying me of your reply, was this: http://www.datanucleus.org/forum/forum/viewthread_thread,5243 which doesn't work. Just an FYI. - David |
||
|
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
Per chance I just came across the relevant section of the spec, here it is: "5.5.1 Transient (Required) JDO instances created by using a developer-written or compiler-generated constructor that do not involve the persistence environment behave exactly like instances of the unenhanced class." |
||
|
|
|
Current timezone is GMT Dec 3, 2008 1:19:00 AM |
