[EJB 3.0] - Entity subquery
by msduk
Sean 1.2.1, AS 4.0.5, Mysql5
Basically after loading an entity I want to be able to do a 'subquery' inside a transient method or something that achieves the same thing.
The motivation is that the state of the entity is made up of many many sub table joins and lines. I want to replace the VERY heavy code that must load and iterate 100's of lines for each of my top level entities before deciding on its state.
We have tried caching the states which does work sort of but we are spending most of our lives chasing around state updates which is not fantastic.
Is there a sanctioned way of doing this sort of thing? It has to crop up a fair amount of times.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066253#4066253
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066253
18Â years, 9Â months
[JBoss Portal] - Re: how can i get current PortalNode
by chris.laprunï¼ jboss.com
"k3nnymusic" wrote : I read CatalogPortlet.java sources and i saw lines
| PortalNode current = req.getPortalNode();
| for JBossRenderRequest req; definition.
| In new api there isn't class org.jboss.portlet.JBossRenderRequest but newest javax.portlet.RenderRequest whitch don't have method getPortalNode();
|
PortalNode is a JBoss Portal specific class used for things like Inter-Portlet Communication (IPC). Using it will tie your portlet to JBoss Portal (i.e. any portlet using the Portal API will not work on other portal solutions). RenderRequest is a JSR-168 interface. This is therefore normal that it doesn't give access to JBoss Portal's API.
That said, I am not quite sure what your problem is. Could you please provide more details?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066250#4066250
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066250
18Â years, 9Â months
[JBoss Seam] - Seam-gen build corrupts images
by trickyvail
Seam 1.2.1.GA
I have experienced corrupt image files when creating new seam-gen projects in a Linux environment (Debian & Ubuntu) for some time. When creating a new seam-gen project in a WindowsXP environment the file corruption does not occur.
There are only 3 files that are effected by this problem:
/view/img/cal-next.png
/view/img/cal-prev.png
/view/img/dtpick.gif
So it has not been a big deal to copy the files over manually.
I've done a little research into the problem and I think it is related to the use of a filterset in the ant copy task on lines 602-605 of the seam-gen build file $SEAM_HOME/seam-gen/build.xml
|
|
| <copy todir="${project.home}/view">
| <fileset refid="view"/>
| <filterset refid="project"/>
| </copy>
The ANT documentation (http://ant.apache.org/manual/CoreTasks/copy.html) says:
anonymous wrote : Note: If you employ filters in your copy operation, you should limit the copy to text files. Binary files will be corrupted by the copy operation. This applies whether the filters are implicitly defined by the filter task or explicitly provided to the copy operation as filtersets. See encoding note.
|
When copying the contents of the image directory within a copy task (without any filters) the file corruptions do not occur.
Would it be appropriate to post a JIRA issue with a patch?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066241#4066241
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066241
18Â years, 9Â months
[JBoss AOP] - (AopC) Compiled AOP in signed jars/applet.
by cranphin
Hi!
I'm using JBoss AOP (1.5.5 GA) in a signed applet. And am encountering some security problems.
I expect this to be due to runtime generated classes (which ofcourse don't come from any of the signed jars).
In debugging this leads to the 'default' ProtectionDomain ending up in the AccessControlContext, which makes the security manager deny my code any rights other then default applet rights.
I'm using the JavaBean aspect from here:
http://www.damnhandy.com/?page_id=17
And the class in the stacktrace I suspect is causing trouble is:
PropertyChangeAspect34
I'd like to know why/how/where the PropertyChangeAspect## classes are generated when I'm using the AOP compiler (so no loadtime weaving).
And I'd like to know if there's any way to work around this problem.
Help? :)
I'll very happily provide any additional details if needed/requested.
Full trace:
Exception in thread "AWT-EventQueue-2" com.jgoodies.binding.beans.PropertyAccessException: Failed to set an adapted Java Bean property.
cause=java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
bean=nl.vda.icr.coworker.CoWorker@7d8bb
bean type=nl.vda.icr.coworker.CoWorker
value=nl.vda.icr.role.Role@25
value type=nl.vda.icr.role.Role
property name=role
property type=nl.vda.icr.role.Role
property setter=public void nl.vda.icr.coworker.CoWorker.setRole(nl.vda.icr.role.Role)
at com.jgoodies.binding.beans.PropertyAccessException.createWriteAccessException(PropertyAccessException.java:133)
at com.jgoodies.binding.beans.BeanUtils.setValue(BeanUtils.java:627)
at com.jgoodies.binding.beans.BeanAdapter.setValue0(BeanAdapter.java:1157)
at com.jgoodies.binding.beans.BeanAdapter.access$600(BeanAdapter.java:284)
at com.jgoodies.binding.beans.BeanAdapter$SimplePropertyAdapter.setValue(BeanAdapter.java:1337)
at com.jgoodies.binding.list.SelectionInList$SelectionIndexChangeHandler.propertyChange(SelectionInList.java:1163)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at com.jgoodies.binding.beans.ExtendedPropertyChangeSupport.firePropertyChange(ExtendedPropertyChangeSupport.java:200)
at com.jgoodies.binding.beans.ExtendedPropertyChangeSupport.firePropertyChange(ExtendedPropertyChangeSupport.java:156)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at com.jgoodies.binding.beans.ExtendedPropertyChangeSupport.firePropertyChange(ExtendedPropertyChangeSupport.java:235)
at com.jgoodies.binding.beans.Model.firePropertyChange(Model.java:455)
at com.jgoodies.binding.value.AbstractValueModel.fireValueChange(AbstractValueModel.java:129)
at com.jgoodies.binding.value.ValueHolder.setValue(ValueHolder.java:233)
at com.jgoodies.binding.value.ValueHolder.setValue(ValueHolder.java:181)
at com.jgoodies.binding.list.SelectionInList.setSelectionIndex(SelectionInList.java:680)
at com.jgoodies.binding.list.SelectionInList.setSelection(SelectionInList.java:616)
at com.jgoodies.binding.list.SelectionInList.setValue(SelectionInList.java:781)
at com.jgoodies.binding.adapter.ComboBoxAdapter.setSelectedItem(ComboBoxAdapter.java:262)
at javax.swing.JComboBox.setSelectedItem(Unknown Source)
at javax.swing.JComboBox.setSelectedIndex(Unknown Source)
at javax.swing.plaf.basic.BasicComboPopup$Handler.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at javax.swing.plaf.basic.BasicComboPopup$1.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkMemberAccess(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredMethods(Unknown Source)
at org.hibernate.reflection.java.JavaXClass.getDeclaredMethods(JavaXClass.java:110)
at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:213)
at org.hibernate.validator.ClassValidator.(ClassValidator.java:134)
at org.hibernate.validator.ClassValidator.(ClassValidator.java:105)
at nl.vda.icr.applet.apppanel.views.propertiespanel.PropertiesPanelPresentationModel.updateValidationResult(PropertiesPanelPresentationModel.java:91)
at nl.vda.icr.applet.apppanel.views.propertiespanel.PropertiesPanelPresentationModel.access$200(PropertiesPanelPresentationModel.java:23)
at nl.vda.icr.applet.apppanel.views.propertiespanel.PropertiesPanelPresentationModel$ValidationUpdateHandler.propertyChange(PropertiesPanelPresentationModel.java:109)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at com.damnhandy.aspects.bean.JavaBeanMixin.firePropertyChange(JavaBeanMixin.java:81)
at nl.vda.icr.coworker.CoWorker.nl$vda$icr$coworker$CoWorker$firePropertyChange$aop(CoWorker.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.aop.ClassAdvisor.invokeMethod(ClassAdvisor.java:1720)
at org.jboss.aop.ClassAdvisor.invokeMethod(ClassAdvisor.java:1704)
at nl.vda.icr.coworker.CoWorker.firePropertyChange(CoWorker.java)
at com.damnhandy.aspects.bean.PropertyChangeAspect.firePropertyChange(PropertyChangeAspect.java:109)
at com.damnhandy.aspects.bean.PropertyChangeAspect.fieldChangeAdvice(PropertyChangeAspect.java:50)
at org.jboss.aop.advice.com.damnhandy.aspects.bean.PropertyChangeAspect34.invoke(PropertyChangeAspect34.java)
at nl.vda.icr.coworker.CoWorker$role_Set.invokeNext(CoWorker$role_Set.java)
at nl.vda.icr.coworker.CoWorker.role_w_$aop(CoWorker.java)
at nl.vda.icr.coworker.CoWorker.setRole(CoWorker.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.jgoodies.binding.beans.BeanUtils.setValue(BeanUtils.java:621)
... 42 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066239#4066239
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066239
18Â years, 9Â months