"obrien" wrote : but it was unexpected - considering experience with other annotation based frameworks.
Yup.
Most of them are keen on doing complete lookup - private fields, ...
Which imho breaks the pojo encapsulation,
hence we only use that as a last resort.
If this really turns out to be a common use case, we could easily add it.
But I rather see "clean" pojo interaction - java beans style. :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209850#4209850
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209850
The last of your messages is strange:
anonymous wrote : vfsfile:/C:/jboss5/server/default/deploy/management/console-mgr.sar/ -> java.lang.NoSuchMethodError: org.jboss.system.server.ServerConfigLocator.locate()Lorg/jboss/system/server/ServerConfig;
Seems a JBoss integrated app does not work. Do your own apps (ReportsWeb.war, crystaljsp.war) contain JBoss system classes from 4.2? Is your JBoss installation a plain new version, or did you add e.g. JARs to /common/lib or other directories?
Best regards
Wolfgang
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209849#4209849
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209849
"alesj" wrote :
| Where?
| Some MC dev forum post - hard to find with this crappy forum software.
|
| Why?
| If there is a public setter it should be used.
| As this keeps the bean/pojo integrity less hackish.
|
| What can be done?
| It's very trivial to extend BeanAccessMode.
| See its Creator interface.
| So, if there are very legit reasons to do so, I'm wiling to listen. ;-)
|
got it now, followed your @Inject and created different plugins. I can live the default bean access mode behaviour, but it was unexpected - considering experience with other annotation based frameworks.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209848#4209848
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209848
The logs you sent do not show how GlobalTransaction::43 tries to acquire locks on /Parameters/ISchmParam/4686570, only how to first one succeeds. They seem incomplete.
Is it possible for you to do the following:
log this : CachePrinter.printCacheLockingInfo(c) immediately after suspending the first tx and immediately before committing the second one?
Also, can I have the full jbosscache log (full meaning everything logged by org.jboss.cache in time frame before starting the first tx and after the second one successfully commits.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209844#4209844
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209844
"obrien" wrote :
| but to get FieldAnnotationPlugin to work, I had to delete/comment out setter in my class, like:
|
Yes, it's the same issue ALR had.
"obrien" wrote :
| Is this correct behaviour? And if it is, can you point me in the right direction where to look for explanation why?
|
This is expected.
Where?
Some MC dev forum post - hard to find with this crappy forum software.
Why?
If there is a public setter it should be used.
As this keeps the bean/pojo integrity less hackish.
What can be done?
It's very trivial to extend BeanAccessMode.
See its Creator interface.
So, if there are very legit reasons to do so, I'm wiling to listen. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209842#4209842
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209842