Grokbase Groups Cayenne dev July 2015
Yes, that would be optimal and I attempted to make it a static inner class for precisely that reason, but it didn’t work. The BeanInfo class must reside within the same package as the class it’s supplementing and be called [ClassName]BeanInfo.

The best documentation I found on this is here:

It mentions you can specify a search path for BeanInfo classes using Introspector.setSearchPath() but I wasn’t able to get it to work with inner classes.

- hugi

On 24. júl. 2015, at 17:01, John Huss wrote:

It would be pretty easy to generate it as a static inner class using the
entity template, then all the code is generated. Do the BeanInfo classes
have to be registered somewhere?
On Fri, Jul 24, 2015 at 11:32 AM Hugi Thordarson wrote:

Thanks John, implementing a BeanInfo class for eaach entity specifying
method names actually works fine!
The BeanInfo class can be associated with the superclass and placed in
it’s package so it’s mostly out of the way, here’s an example
implementation for an entity called “Product” containing a single property
called “name”.

Something of a hassle to have to do this for the entire object graph,

- hugi

On 24. júl. 2015, at 14:15, John Huss wrote:

In theory the bean spec allows you to specify a BeanInfo object that can
allow you to use different naming conventions, but in practice most
libraries cut corners and just assume "get" and "set". I'm not sure if it
works with Cayenne's Property and PropertyUtils however. For myself I
found it easier to just add the "get" prefix.


On Fri, Jul 24, 2015 at 9:11 AM Andrus Adamchik <>
Hi Hugi,

1. I can't think of anything inside Cayenne that would rely on a getter
(Property.getFrom(..) is user-facing API that is not directly related to
persistence). So you should be safe otherwise.

2. I am with Mike - if you can, better switch to JavaBean getters.
avoid lots of pain integrating with anything else in Java.

On Jul 24, 2015, at 3:32 PM, Michael Gentry <> wrote:
Hi Hugi,

I don't know offhand everywhere in Cayenne that get* is required, but
Cayenne's default templates and expectations are that the JavaBeans
notation (get/set/is) prefixes will be used. Many other frameworks,
as Apache Tapestry, work flawlessly with Cayenne because of the
notation, but would fail if get* were missing.

I used to use EOF/Objective-C, too, and at first the get* seemed annoying,
but now within Eclipse it is easy to type "get" and let the
popup show me my options, which you can't do without that prefix. Overall,
I think get* is a win because it is easier to find your getters and it
makes Cayenne work with other frameworks that expect the standard prefixes.

On Fri, Jul 24, 2015 at 7:37 AM, Hugi Thordarson <>
Hi all.

I don’t use “get" prefixes on the accessors for attributes on my
DataObjects. This has worked flawlessly until now, but I just stumbled
a case where it will cause a failure inside Cayenne’s world, i.e. when
attempting to access property values on objects using
org.apache.cayenne.exp.Property.getFrom( someObject ).

The method documentation explicitly states that a bean-style
required, so this was to be expected. But I’m wondering if there are
places where Cayenne depends on it and if the requirement for the
prefix should be eliminated entirely within Cayenne’s universe? (I’m
I’m not the only one who is not fond of using it)

I got around this particular case by implementing my own “poor man’s
KeyValueCoding” (for those of you familiar with EOF), but it would be
not having to do something of that ilk.

- hugi

// Hugi Thordarson
// s. 895-6688

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 8 | next ›
Discussion Overview
groupdev @
postedJul 24, '15 at 11:37a
activeJul 24, '15 at 5:10p



site design / logo © 2021 Grokbase