Using Grails 2.0.x without the new GORM API - possible?

[Roshan Dawrani]

Hi,

"What's new in Grails 2.0" [1] says: "The GORM API has been formalized into a set of classes (GormStaticApi, GormInstanceApi and GormValidationApi) that get statically wired into every domain class at the byte code level."

If I remember it right, earlier it was the "hibernate" plugin that used to add GORM API to domain classes. Can someone please tell how it happens in Grails 2.0.x? Is it possible to skip adding the new GORM API (GormStaticApi, GormInstanceApi and GormValidationApi) to a particular application's domain classes? Can I avoid wiring of these GORM API methods into domain classes at bytecode level?

[1] - http://www.dzone.com/links/r/whats_new_in_grails_20.html

--
Roshan

http://roshandawrani.wordpress.com/

[Jeff Brown-3]

On Fri, Mar 23, 2012 at 7:04 AM, Roshan Dawrani <[hidden email]> wrote:
> Hi,
>
> "What's new in Grails 2.0" [1] says: "The GORM API has been formalized into
> a set of classes (GormStaticApi, GormInstanceApi and GormValidationApi) that
> get statically wired into every domain class at the byte code level."
>
> If I remember it right, earlier it was the "hibernate" plugin that used to
> add GORM API to domain classes. Can someone please tell how it happens in
> Grails 2.0.x?

Much of the interesting relevant work is related to the
HibernateGormEnhancer.  That class is used by HibernatePluginSupport.

See:
https://github.com/grails/grails-core/blob/master/grails-hibernate/src/main/groovy/org/codehaus/groovy/grails/orm/hibernate/HibernateGormEnhancer.groovy
https://github.com/grails/grails-core/blob/master/grails-hibernate/src/main/groovy/org/codehaus/groovy/grails/plugins/orm/hibernate/HibernatePluginSupport.groovy

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi) to a particular application's domain
> classes? Can I avoid wiring of these GORM API methods into domain classes at
> bytecode level?
>

Why is it that you might want to do that?  The answer to that question
will help answer your question and/or provide suggestions that might
be a better way to accomplish whatever you are after.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani]

On Fri, Mar 23, 2012 at 6:29 PM, Jeff Brown <[hidden email]> wrote:

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi)

Why is it that you might want to do that? 

Thanks for getting back.

On 1.3.x line, we replaced GORM stuff provided by Hibernate plugin and wired our own components for our own data-store (xyz).

Although a good idea will probably be to plug-in the new data-store based implementation for our xyz datastore, I am trying to see if I can avoid it in the round 1 of Grails 2.0 migration and re-use the existing data access layer. For now, we would like to focus on migrating the rest of the application, if possible.

Would you like me to provide any more details, or is it clearer what I am after? Is it possible to avoid hard-wiring of new Grails 2 GORM API into my app's domain classes? What do you suggest?

Regards,

Roshan

[Roshan Dawrani]

Hi,

Ping!

Can anyone comment on if it is still possible to plug-in a 1.3.7 like custom GORM implementation (persistence layer) for an application bypassing the wiring of new GORM API methods into the domain classes?

Or, the only approach that would work with 2.0.1 is to plug-in an implementation of new GORM api for our own custom datastore?

Cheers.

http://roshandawrani.wordpress.com/ 

On Fri, Mar 23, 2012 at 6:40 PM, Roshan Dawrani <[hidden email]> wrote:

On Fri, Mar 23, 2012 at 6:29 PM, Jeff Brown <[hidden email]> wrote:

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi)

Why is it that you might want to do that? 

Thanks for getting back.

On 1.3.x line, we replaced GORM stuff provided by Hibernate plugin and wired our own components for our own data-store (xyz).

Although a good idea will probably be to plug-in the new data-store based implementation for our xyz datastore, I am trying to see if I can avoid it in the round 1 of Grails 2.0 migration and re-use the existing data access layer. For now, we would like to focus on migrating the rest of the application, if possible.

Would you like me to provide any more details, or is it clearer what I am after? Is it possible to avoid hard-wiring of new Grails 2 GORM API into my app's domain classes? What do you suggest?

Regards,

Roshan

--
Roshan

http://roshandawrani.wordpress.com/

[Jeff Brown-3]

On Mon, Mar 26, 2012 at 8:35 AM, Roshan Dawrani <[hidden email]> wrote:

> Hi,
>
> Ping!
>
> Can anyone comment on if it is still possible to plug-in a 1.3.7 like custom
> GORM implementation (persistence layer) for an application bypassing the
> wiring of new GORM API methods into the domain classes?
>
> Or, the only approach that would work with 2.0.1 is to plug-in an
> implementation of new GORM api for our own custom datastore?
>

In general, the runtime metaprogramming techniques used in 1.3.x will
still work in Grails 2.  There are some things that could potentially
go wrong but if you take care, you should be ok.  For example, methods
added at runtime via the metaclass are only available to calls made
from Groovy.  Consider a methodA calls methodB and methodB calls
methodC and all of those are Java methods added at compile time.  If
you metaprogram your own version of methodA and methodC and your
methodA calls the original methodB, that could be problematic since
your dynamic methodA will call the statically compiled methodB and
that code will be calling the statically compiled methodC, not your
runtime metaprogrammed methodC.

I hope that makes sense.

Best of luck.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email