[OT]-ish Reading Annotation Data

[RogerV]

Is there a way of retrieving annotation data from an entity? Specifically I'm using the @Column(length=) annotation in a Struts 2 web app. It would be useful if I could read this data and use it to validate the incoming field length and to use it on the result to set the width of the input field.

Regards

[Vackar]

I'm not an expert in this area, but here's some pseudo code that should work

Class entityClass = entity.getClass();
Method m = c.getMethod("getter", typeOfVal.class);
Column annotation = m.getAnnotation(Column .class);
int len = annotation.intValue();

Give it a go and lemme know if it works.

Thanks,
Vackar

>>> RogerV <roger.varley@...> 28/09/2009 14:16 >>>

Is there a way of retrieving annotation data from an entity? Specifically I'm
using the @Column(length=) annotation in a Struts 2 web app. It would be
useful if I could read this data and use it to validate the incoming field
length and to use it on the result to set the width of the input field.

Regards
--
View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25645176.html 
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

The University of Dundee is a registered Scottish charity, No: SC015096
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[tch]

You need to use reflection, there is no built in "JPA Annotation
Reflection Helper" provided by eclipselink, I asked once in an
eclipselink chat and everyone thought I was nuts, but good to see I'm
not the only one looking for something like that.

Now, I have some classes I developed, but they're too integrated with
other unrelated things to share here, but here are some snippets that
will help you.

private  void readAnnotations(Class pClass, Map<Class,Map<String,
Map<Class<? extends Annotation>, Annotation>>> pPropertyAnnotationMap)
{
                if(!Object.class.equals(pClass)) {
               
                        Map<String, Map<Class<? extends Annotation>, Annotation>>
myClassAnnotationMap = new HashMap<String, Map<Class<? extends
Annotation>, Annotation>>();

                        Field myFields[]=pClass.getDeclaredFields();
                        for(Field myField: myFields) {
                                myField.setAccessible(true);
                                Annotation myAnnotations[] = myField.getAnnotations();
                                Map<Class<? extends Annotation>,Annotation> myAnnotationMap = new
HashMap<Class<? extends Annotation>,Annotation>();
                                for(Annotation myAnnotationElement: myAnnotations) {
                                        myAnnotationMap.put( myAnnotationElement.annotationType(),
myAnnotationElement);

                                       
                                }
                                myClassAnnotationMap.put(myField.getName(), myAnnotationMap);
                               
                        }
                        //Get the current map or create a new if it doesn't exist.
                        Map<String, Map<Class<? extends Annotation>, Annotation>>
myCurrentClassAnnotationMap = pPropertyAnnotationMap.get(pClass);
                        if(myCurrentClassAnnotationMap==null) {
                                myCurrentClassAnnotationMap = myClassAnnotationMap;
                        } else {
                                myCurrentClassAnnotationMap.putAll(myClassAnnotationMap);
                        }
                       
                        //Store the annotations.
                        pPropertyAnnotationMap.put(pClass, myCurrentClassAnnotationMap);
                       
                        //Read the superclass's annotation.
                        Class myClass = pClass.getSuperclass();
                        if(myClass!=null) {
                                readAnnotations(myClass,pPropertyAnnotationMap );
                        }
                }
               
        }

@SuppressWarnings("unchecked")
        public Set<Property> findPropertiesWithAnnotation(Class<? extends
Annotation> pAnnotationClass, Class pTargetClass) {
                Set<Property> myResults = new HashSet<Property>();
                Field myFields[] = pTargetClass.getDeclaredFields();
                for(int i=0; i<myFields.length; ++i) {
                        myFields[i].setAccessible(true);
                        Annotation myAnnotation=myFields[i].getAnnotation(pAnnotationClass);
                        if(myAnnotation!=null) {
                                //log.info("Located Primary key  = " + myFields[i].getName());
                                myResults.add(new Property(myFields[i].getName()));
                        }
                       
                }
                return myResults;
               
        }


Now per validation, if you're planning on implementing your own
validation framework at the entity level, it'd be prudent to implement
JSR 303 instead of making up your own annotations, this will save you
time in the future when more frameworks support bean validation.

http://jcp.org/en/jsr/detail?id=303



./tch



On Mon, Sep 28, 2009 at 9:16 AM, RogerV <roger.varley@...> wrote:

>
> Is there a way of retrieving annotation data from an entity? Specifically I'm
> using the @Column(length=) annotation in a Struts 2 web app. It would be
> useful if I could read this data and use it to validate the incoming field
> length and to use it on the result to set the width of the input field.
>
> Regards
> --
> View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25645176.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[RogerV]

On Monday 28 September 2009 16:26:00 Tim Hollosy wrote:
> You need to use reflection, there is no built in "JPA Annotation
> Reflection Helper" provided by eclipselink, I asked once in an
> eclipselink chat and everyone thought I was nuts, but good to see I'm
> not the only one looking for something like that.
>
The only reason that I think why people would think you mad for what, to me,
seems a perfectly reasonable idea, is that people have been there, done that
and it has been shown to be A Bad Idea(Tm). I'd be interested in comments
before I attempt to go down this route.

I'm talking specifically about using entities in a web-app where I need to
validate the length of  fields returned before trying to insert/update the
database. I'd also like to make the column length available to the web
framework (in this instance Struts 2) so I can set the size of the
input/display elements to match their definition where appropriate.

Regards
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[mobrien]

Roger, Tim, Vackar,
    Hi, providing runtime API functionality to inspect the both JPA annotation API and the XML mapping API is very useful functionality that I find particularly interesting.  There is work in the JPA 2.0 specification that exposes non-native JPA annotations via the Metamodel or Criteria API.
    For details on this work, you may take a look at JSR-317 (JPA 2.0) where an implementation of this API is in development by this team.
    See the upcoming PFD of the specification to be released at http://jcp.org/aboutJava/communityprocess/edr/jsr317/index.html

    Also, I just talked with Chris about this issue and we should be able to use native EclipseLink API to access the DatabaseField just like we do when leveraging the metadata API for metamodel processing.

Roger wrote:

On Monday 28 September 2009 16:26:00 Tim Hollosy wrote:
  

You need to use reflection, there is no built in "JPA Annotation
Reflection Helper" provided by eclipselink, I asked once in an
eclipselink chat and everyone thought I was nuts, but good to see I'm
not the only one looking for something like that.

    

An API like you mention is being released with EclipseLink 2.0.
See the RI for EJB 3.1/JPA 2.0 where the Metamodel API exposes the entity annotation API and the XML mapping API as one unified "metadata" type-safe API - this model is used both by the canonical processor to dynamically generate metamodel classes from source at design time, and by the Criteria API used to query the metamodel at runtime.
All of these tools are available on the EclipseLink 2.0 trunk and will be released as part of the RI for EJB 3.1/JPA 2.0.
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0


In answer to the @Column length annotation field - i think this would be a very good extension of the API once the specification has been finalized.
The granularity of the JPA Metamodel may not capture all available JPA annotation details.
We could add more annotation details on the elementType field of the JPA 2.0 Attribute - but outside of the JPA specification, more details are available via the mapping or descriptor.

computersAttribute    SetAttributeImpl<X,V>  (id=194)   
    elementType    EntityTypeImpl<X>  (id=121)   
        javaClass    Class<T> (org.eclipse.persistence.testing.models.jpa.metamodel.Computer) (id=80)   
    managedType    EntityTypeImpl<X>  (id=131)   
        javaClass    Class<T> (org.eclipse.persistence.testing.models.jpa.metamodel.Manufacturer) (id=88)   
    mapping    OneToManyMapping  (id=203)   


We welcome any suggestions on extending the JPA 2.0 API implementation.
I will add extended annotation access to the design page at
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api

RogerV roger.varley@... 28/09/2009 14:16 >>>

Is there a way of retrieving annotation data from an entity? Specifically I'm
using the @Column(length=) annotation in a Struts 2 web app. It would be
useful if I could read this data and use it to validate the incoming field
length and to use it on the result to set the width of the input field.

thank you
michael

The only reason that I think why people would think you mad for what, to me, 
seems a perfectly reasonable idea, is that people have been there, done that 
and it has been shown to be A Bad Idea(Tm). I'd be interested in comments 
before I attempt to go down this route.

I'm talking specifically about using entities in a web-app where I need to 
validate the length of  fields returned before trying to insert/update the 
database. I'd also like to make the column length available to the web 
framework (in this instance Struts 2) so I can set the size of the 
input/display elements to match their definition where appropriate.

Regards
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
  

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[RogerV]

mobrien wrote:

We welcome any suggestions on extending the JPA 2.0 API implementation.
I will add extended annotation access to the design page at
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api

Hi Michael

I'm coming from being a long term developer on IBM S/38's, AS/400's and latterly on SAP R/3 systems. These systems all had a "meta layer" that sat between the application and the database - a definition repository or a data dictionary if you like. This allowed you to define your data elements once and once only. So you could define your customer number for example as a 9 digit integer field. You could then define other fields in terms of them being a "Customer Number" type. Not only could you define the type & size, you could set default values, display/print formatting rules, text that would be used as labels when displaying/printing, text that would be used as help text (tooltips would, I guess, be the java equivalent). The "disadvantage" I see with JPA & Java, at the moment is that this information (for example element length) is often defined in multiple locations - it's in the DB table definitions, it's in the entity annotation, it's in the validation code/framework and it's often in the html/css definitions as well.

So I'm wondering if the idea of a "data dictionary" would be of more use. I've no idea whether this concept would be a welcome addition to EclipseLink, or even if it's physically possible.  All I can say having used such systems, that it brings consistancy to displays and reports, eliminates definition duplication, makes data changes simple to implement application wide and generally makes life easier.



Regards
 

[tch]

The idea of having a POJO based entity layer like we have in JPA is
that those same entities that you define once for JPA can and should
be used for other things -- like holding form values in a web
framework, etc.

./tch



On Tue, Sep 29, 2009 at 6:41 AM, RogerV <roger.varley@...> wrote:

>
>
>
> mobrien wrote:
>>
>> We welcome any suggestions on extending the JPA 2.0 API implementation.
>> I will add extended annotation access to the design page at
>> http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api
>>
>
> Hi Michael
>
> I'm coming from being a long term developer on IBM S/38's, AS/400's and
> latterly on SAP R/3 systems. These systems all had a "meta layer" that sat
> between the application and the database - a definition repository or a data
> dictionary if you like. This allowed you to define your data elements once
> and once only. So you could define your customer number for example as a 9
> digit integer field. You could then define other fields in terms of them
> being a "Customer Number" type. Not only could you define the type & size,
> you could set default values, display/print formatting rules, text that
> would be used as labels when displaying/printing, text that would be used as
> help text (tooltips would, I guess, be the java equivalent). The
> "disadvantage" I see with JPA & Java, at the moment is that this information
> (for example element length) is often defined in multiple locations - it's
> in the DB table definitions, it's in the entity annotation, it's in the
> validation code/framework and it's often in the html/css definitions as
> well.
>
> So I'm wondering if the idea of a "data dictionary" would be of more use.
> I've no idea whether this concept would be a welcome addition to
> EclipseLink, or even if it's physically possible.  All I can say having used
> such systems, that it brings consistancy to displays and reports, eliminates
> definition duplication, makes data changes simple to implement application
> wide and generally makes life easier.
>
>
>
> Regards
>
>
>
> --
> View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25660646.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[Vackar]

Now that you mention it, seam (from jboss) provides something similar to this.
You define your constraints once, and these constraints are mirrored in domain,view and DB checks.
We used it for a project, but had to eventually scrap it because it wasn't portable onto our AS.
But that was a while back, I think the latest version is a massive improvement over the version we used.

Vackar


>>> RogerV <roger.varley@...> 29/09/2009 11:41 >>>



mobrien wrote:
>
> We welcome any suggestions on extending the JPA 2.0 API implementation.
> I will add extended annotation access to the design page at
> http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api 
>

Hi Michael

I'm coming from being a long term developer on IBM S/38's, AS/400's and
latterly on SAP R/3 systems. These systems all had a "meta layer" that sat
between the application and the database - a definition repository or a data
dictionary if you like. This allowed you to define your data elements once
and once only. So you could define your customer number for example as a 9
digit integer field. You could then define other fields in terms of them
being a "Customer Number" type. Not only could you define the type & size,
you could set default values, display/print formatting rules, text that
would be used as labels when displaying/printing, text that would be used as
help text (tooltips would, I guess, be the java equivalent). The
"disadvantage" I see with JPA & Java, at the moment is that this information
(for example element length) is often defined in multiple locations - it's
in the DB table definitions, it's in the entity annotation, it's in the
validation code/framework and it's often in the html/css definitions as
well.

So I'm wondering if the idea of a "data dictionary" would be of more use.
I've no idea whether this concept would be a welcome addition to
EclipseLink, or even if it's physically possible.  All I can say having used
such systems, that it brings consistancy to displays and reports, eliminates
definition duplication, makes data changes simple to implement application
wide and generally makes life easier.



Regards
 


--
View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25660646.html 
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

The University of Dundee is a registered Scottish charity, No: SC015096
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[RogerV]

tch wrote:

The idea of having a POJO based entity layer like we have in JPA is
that those same entities that you define once for JPA can and should
be used for other things -- like holding form values in a web
framework, etc.

I totally agree. The "problem" is with the "metadata" in that if, for example, I have a column definition specifying a text field as being 32 characters long on an entity annotation, unless I'm missing something, I have to repeat that definition elsewhere. I can specify it in html/css to control the number of characters the user can enter into the field in a webform. I still have to specify it on the server as part of the validation process in case I've got some smart alec trying to beat the system from the client end or if I don't check it anywhere, I've got to handle truncation errors when I try to update the database.

Regards

[Vackar]

Yeah you're right - but I think seam does solve a lot of the duplicated validation issues.

>>> RogerV <roger.varley@...> 29/09/2009 13:25 >>>



tch wrote:
>
> The idea of having a POJO based entity layer like we have in JPA is
> that those same entities that you define once for JPA can and should
> be used for other things -- like holding form values in a web
> framework, etc.
>

I totally agree. The "problem" is with the "metadata" in that if, for
example, I have a column definition specifying a text field as being 32
characters long on an entity annotation, unless I'm missing something, I
have to repeat that definition elsewhere. I can specify it in html/css to
control the number of characters the user can enter into the field in a
webform. I still have to specify it on the server as part of the validation
process in case I've got some smart alec trying to beat the system from the
client end or if I don't check it anywhere, I've got to handle truncation
errors when I try to update the database.

Regards

--
View this message in context: http://www.nabble.com/-OT--ish-Reading-Annotation-Data-tp25645176p25662090.html 
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

The University of Dundee is a registered Scottish charity, No: SC015096
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users