javax.servlet.ServletException: Annotated methods must follow the JavaBeans naming convention. __odbHidden_getPropertyName

Type: BugVersion: 2.2.6Priority: HighStatus: FixedReplies: 9
#1

NB: the following issue only happens with ObjectDB, it does not happen with EclipseLink.

 Glassfish3.0.1

objectdb-2.2.5_10

JavaEE6 web app

The error reports as:

javax.servlet.ServletException: Annotated methods must follow the JavaBeans naming convention. __odbHidden_getWidthPxSideBarLeft

Where getWidthPxSideBarLeft() is an annotated getter of an entity ViewConfiguration:

private int widthPxSideBarLeft = 250;
    @Min(150)
    @Max(400)
    public int getWidthPxSideBarLeft() {
        return widthPxSideBarLeft;
    }
    public void setWidthPxSideBarLeft(int widthPxSideBarLeft) {
        this.widthPxSideBarLeft = widthPxSideBarLeft;
    }

It appears in part of a JSF template with dynamic CSS style parameters:

style="min-width:#{viewConfigurationManager.viewConfiguration.widthPxSideBarLeft}px"

Where ViewConfigurationManager is a @SessionScoped @ManagedBean backing bean that pulls the 1st (default) ViewConfiguration object via a @Stateless facade session bean using em.find(entityClass, id).

The strange thing is that it works perfectly fine for all JSF pages, I can move from page to page each with both a "main" h:form and a "secondary" h:form in the sidebar (see FYI only attached XHTML composite expertise_level.xhtml), until i submit the  "secondary" h:form in the sidebar. I don't expect you of course to examine JSF pages in detail, and I can assure you that there is no substantial difference between the h:forms anyway, and they both perform a full submit.

There is nothing wrong with the property name 'widthPxSideBarLeft', and I think this is a genuine ObjectDB problem that has something to do with the way ObjectDB handles __odbHidden_getWidthPxSideBarLeft.

 

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#2

The ObjectDB Enhancer modifies the names of persistent property get and set methods by adding __odbHidden_ prefix - in order to add new proxy methods with the original method names.

Apparently, this violates some rules about names of methods with some annotations.

Maybe just replacing the prefix to something like getOdbHidden can solve the problem.

Please try build 2.2.6_01 that tries exactly that.

If this doesn't help maybe the Enhancer has to move the annotations to the proxy methods, but that would be more difficult.

Could you please post a full stack trace of the exception?

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#3

I replaced widthPxSideBarLeft with explicit 250 constant in every XHTML, it made no difference.

The only references to widthPxSideBarLeft in all Java files are those given above.

I am convinced this is an ObjectDB bug.

Also, of all other issues/help requests I've made, this one has for me the highest priority, it is inconveniencing my work the most.

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#4

Have you tried version 2.2.6_01 that might fix it (see #2)?

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#5

I tried version 2.2.6_01 and it did NOT fix it.

The Glassfish3.01 log stacktrace is:

WARNING: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
javax.validation.ValidationException: Annotated methods must follow the JavaBeans naming convention. __odbHidden_getWidthPxSideBarLeft() does not.
        at org.hibernate.validator.metadata.MetaConstraint.<init>(MetaConstraint.java:75)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.createMetaConstraint(BeanMetaDataImpl.java:435)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.initMethodConstraints(BeanMetaDataImpl.java:376)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.initClass(BeanMetaDataImpl.java:244)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.createMetaData(BeanMetaDataImpl.java:238)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.<init>(BeanMetaDataImpl.java:117)
        at org.hibernate.validator.metadata.BeanMetaDataImpl.<init>(BeanMetaDataImpl.java:106)
        at org.hibernate.validator.engine.ValidatorImpl.getBeanMetaData(ValidatorImpl.java:735)
        at org.hibernate.validator.engine.ValidatorImpl.collectMetaConstraintsForPath(ValidatorImpl.java:681)
        at org.hibernate.validator.engine.ValidatorImpl.validateValue(ValidatorImpl.java:578)
        at org.hibernate.validator.engine.ValidatorImpl.validateValue(ValidatorImpl.java:146)
        at javax.faces.validator.BeanValidator.validate(BeanValidator.java:306)
        at javax.faces.component.UIInput.validateValue(UIInput.java:1149)
        at javax.faces.component.UISelectOne.validateValue(UISelectOne.java:146)
        at javax.faces.component.UIInput.validate(UIInput.java:967)
        at javax.faces.component.UIInput.executeValidate(UIInput.java:1233)
        at javax.faces.component.UIInput.processValidators(UIInput.java:698)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIForm.processValidators(UIForm.java:253)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214)
        at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1172)
        at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
        at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:680)

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#6

Upgraded issue tracking version to 2.2.6_01

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#7

This is strange, since the string "odbHidden" that is shown in the new stack trace doesn't exist anymore in build 2.2.6_01.

Please verify that:

  • You are using only the new ObjectDB jar and the old jar is not anywhere in the classpath.
  • You are not using classes that have been enhanced by an older ObjectDB version (since the change is in ObjectDB Enhancer) - a full Clean and Build is required.

In addition, please notice that this attempt to fix the problem was done without the ability to reproduce the problem - if it doesn't work please upload a project that demonstrates the problem.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#8

Yes, after complete library reassignment and rebuild 2.2.6_01 did fix it.

Sorry, i did this check quickly in between other work; for previous build checks I was only working on ObjectDB evaluation and did very careful install, library reassignment and rebuild, which I seemed to have skipped over this time.

Thanks for fixing this bug.

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#9

That's ok. No problem.

Build 2.2.6_01 included a dirty and quick fix that used get as a prefix for both get and set persistent property methods that are being hidden by the Enhancer. This could cause future problems with annotations that can only be used with set methods.

Build 2.2.6_02 improves the fix by hiding the enhanced property methods using a suffix rather than a prefix. Hopefully this fix should work as well.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#10

Starting build 2.6.4_03 Enhancer generated hidden methods will have a __odbHidden_ prefix again (as was until version 2.2.6 and fixing this issue). This is required due to another issue.

However, the issue described here is not expected to happen again, since the annotations are now moved from the Enhancer generated hidden methods to the property get/set methods. If it does happen again then please report.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply

To post a reply and/or subscribe to update notifications - please login