[
https://issues.apache.org/jira/browse/ISIS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-651:
-----------------------------
Description:
Make JDO PersistenceManagerFactory accessible so can be interacted with outside
of Isis runtime
Invalidate Isis spec cache by way of class (not just by object).
~~~
need to be able to do similar with the DN metadata:
http://www.datanucleus.org/servlet/jira/browse/NUCCORE-1104
Assuming that there's auto-enhancement within the IDE, this means that JRebel
picks up each class twice: once for the unenhanced class, then almost
immediately for the enhanced class. Therefore, I think that all that may be
required is to remove the ClassMetaData whenever an unenhanced class is
reloaded DN's will lazily recreate metadata as required.
An enhancement might be to do the enhancement within the JRebel plugin (and not
in the IDE). This would require the enhancement is done in a separate
classloader; it (obviously!) isn't allowed to reference the java.lang.Class
being loaded within the plugin itself. As enhancement does cause this to
occur, it must be namespaced off to a separate classloader.
resources:
- http://www.datanucleus.org/servlet/wiki/pages/viewpage.action?pageId=6619188
(Metadata Generation, programmatic running of Enhancement)
- http://markmail.org/message/xn6fowrxqeucac26 (useful forum messages hinting
on the classloader stuff)
- http://www.datanucleus.org/products/accessplatform/jpa/enhancer.html#api
(background notes)
was:
Make JDO PersistenceManagerFactory accessible so can be interacted with outside
of Isis runtime
Invalidate Isis spec cache by way of class (not just by object).
~~~
further notes:
- the main issue to tackle is bytecode enhancement of the changed files; the
Eclipse DN plugin does *not* enhance the bytecode before JRebel picks it up.
- though have seen double loading, so perhaps just ignore any classes not
enhanced?
- do the enhancement in a separate classloader.
resources:
- http://www.datanucleus.org/servlet/wiki/pages/viewpage.action?pageId=6619188
(Metadata Generation, programmatic running of Enhancement)
- http://markmail.org/message/xn6fowrxqeucac26 (useful forum messages hinting
on the classloader stuff)
- http://www.datanucleus.org/products/accessplatform/jpa/enhancer.html#api
(background notes)
> Prereqs to possible JRebel support
> ----------------------------------
>
> Key: ISIS-651
> URL: https://issues.apache.org/jira/browse/ISIS-651
> Project: Isis
> Issue Type: Improvement
> Components: Core, Objectstore: JDO
> Affects Versions: objectstore-jdo-1.3.0, core-1.3.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: objectstore-jdo-1.4.0, core-1.4.0
>
>
> Make JDO PersistenceManagerFactory accessible so can be interacted with
> outside of Isis runtime
> Invalidate Isis spec cache by way of class (not just by object).
> ~~~
> need to be able to do similar with the DN metadata:
> http://www.datanucleus.org/servlet/jira/browse/NUCCORE-1104
> Assuming that there's auto-enhancement within the IDE, this means that JRebel
> picks up each class twice: once for the unenhanced class, then almost
> immediately for the enhanced class. Therefore, I think that all that may be
> required is to remove the ClassMetaData whenever an unenhanced class is
> reloaded DN's will lazily recreate metadata as required.
> An enhancement might be to do the enhancement within the JRebel plugin (and
> not in the IDE). This would require the enhancement is done in a separate
> classloader; it (obviously!) isn't allowed to reference the java.lang.Class
> being loaded within the plugin itself. As enhancement does cause this to
> occur, it must be namespaced off to a separate classloader.
> resources:
> -
> http://www.datanucleus.org/servlet/wiki/pages/viewpage.action?pageId=6619188
> (Metadata Generation, programmatic running of Enhancement)
> - http://markmail.org/message/xn6fowrxqeucac26 (useful forum messages
> hinting on the classloader stuff)
> - http://www.datanucleus.org/products/accessplatform/jpa/enhancer.html#api
> (background notes)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
