[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3278) seam-gen generate-ui problem - entity in a different package
by Guido Simone (JIRA)
seam-gen generate-ui problem - entity in a different package
-------------------------------------------------------------
Key: JBSEAM-3278
URL: https://jira.jboss.org/jira/browse/JBSEAM-3278
Project: Seam
Issue Type: Bug
Components: Tools
Reporter: Guido Simone
Here is an example:
The entity class PersonAddress has a ManyToOne relationship with Address which happens to be in a different package. The seam generate-ui command will generate (among other things) an EntityHome class named PersonAddressHome.
//==================================
// PersonAddress
package com.domain.model.person;
import com.domain.model.location.Address;
@Entity
public class PersonAddress
{
private Address address;
private PersonAddressTypeLookup addressTypeLookup;
private Person person;
@ManyToOne @NotNull
public Address getAddress() {return address;}
@ManyToOne @NotNull
public PersonAddressTypeLookup getAddressTypeLookup()
{ return addressTypeLookup; }
@ManyToOne @NotNull
public Person getPerson() {return person;}
// setters omitted
}
which generates:
//==================================
// PersonAddressHome
package com.domain.action;
import com.domain.model.person.*;
import org.jboss.seam.annotations.In;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.framework.EntityHome;
@Name("personAddressHome")
public class PersonAddressHome extends EntityHome<PersonAddress>
{
// code omitted...
public void wire()
{
getInstance();
Address address = addressHome.getDefinedInstance();
if (address != null)
{
getInstance().setAddress(address);
}
PersonAddressTypeLookup addressTypeLookup = addressTypeLookupHome
.getDefinedInstance();
if (addressTypeLookup != null)
{
getInstance().setAddressTypeLookup(addressTypeLookup);
}
Person person = personHome.getDefinedInstance();
if (person != null)
{
getInstance().setPerson(person);
}
}
The generated code imports all entities in com.domain.model.person, but does not import anything from com.domain.model.location so the compilation fails in the second line of the wire() method (Address cannot be resolved to a type).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3297) DB2 error on search with seam-gen restriction
by Valerie Griffin (JIRA)
DB2 error on search with seam-gen restriction
----------------------------------------------
Key: JBSEAM-3297
URL: https://jira.jboss.org/jira/browse/JBSEAM-3297
Project: Seam
Issue Type: Bug
Components: Tools
Affects Versions: 2.0.3.CR1
Environment: JBoss 4.2, Seam 2.0.3.CR1, Linux, DB2
Reporter: Valerie Griffin
The generated action/TblList.java code contains RESTRICTIONS like:
"lower(channel.channelType) like concat(lower(#{channelList.channel.channelType}),'%')"
which Hibernate turns into a prepared statement containing: "lower(?)"
DB2 doesn't like this. It does not permit use of an undefined type in the lower function. This feature is documented on the hibernate web site. If the nesting order is changed to "lower(concat(" DB2 is happy and the function is still standard.
I've changed EntityList.java.ftl to fix this problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3030) Don't be so hostile to alternate JPA providers when attempt is made to use manual flush mode
by Dan Allen (JIRA)
Don't be so hostile to alternate JPA providers when attempt is made to use manual flush mode
--------------------------------------------------------------------------------------------
Key: JBSEAM-3030
URL: http://jira.jboss.com/jira/browse/JBSEAM-3030
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.0.A1, 2.0.2.GA
Reporter: Dan Allen
Assigned To: Dan Allen
Fix For: 2.0.2.SP1, 2.1.0.BETA1
Attachments: JBSEAM-3030-branch20-v1.txt, JBSEAM-3030-trunk-v1.txt
Right now, alternate JPA providers (such as TopLink) are *unusable* in Seam. This is because, prior to the render response phase, Seam attempts to put the touched persistence contexts into manual flush mode. This trickles down to a call to setManualFlushMode() on the component returned by PersistenceProvider.instance(). The generic implementation (PersistenceProvider) throws an exception when this method is called.
Throwing an exception here is overkill and hostile. I propose a log warning message, which would allow the developer to tune the log settings to hush it, or if they really don't like the log message, they can provide their own implementation. But at least the damn thing will be usable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3034) EJB Stateless Session Bean Injection using @In Glassfish server
by Senthilkumar Muthusamy (JIRA)
EJB Stateless Session Bean Injection using @In Glassfish server
----------------------------------------------------------------
Key: JBSEAM-3034
URL: http://jira.jboss.com/jira/browse/JBSEAM-3034
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.1.GA
Environment: Glassfish Application Server V2ur2
Reporter: Senthilkumar Muthusamy
Priority: Critical
I have 2 stateless ejbs, from ejb1, i am trying inject ejb2 using @In annotation. I got below exception
Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: slave
at org.jboss.seam.Component.newInstance(Component.java:1970)
at org.jboss.seam.Component.getInstance(Component.java:1873)
at org.jboss.seam.Component.getInstance(Component.java:1840)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2182)
at org.jboss.seam.Component.getValueToInject(Component.java:2134)
at org.jboss.seam.Component.injectAttributes(Component.java:1598)
at org.jboss.seam.Component.inject(Component.java:1416)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:45)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke(EntityManagerProxyInterceptor.java:26)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke(HibernateSessionProxyInterceptor.java:27)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:118)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:579)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:483)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:205)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3978)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
... 53 more
Caused by: javax.naming.NameNotFoundException: No object bound to name java:comp/env/evolve/SlaveBean/local
at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:834)
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:173)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:396)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.seam.Component.instantiateSessionBean(Component.java:1287)
at org.jboss.seam.Component.instantiate(Component.java:1273)
at org.jboss.seam.Component.newInstance(Component.java:1966)
... 78 more
Please look at the below link for more details and how to reproduce.
http://www.seamframework.org/Community/AuthenticationUsingSeamRemoting
http://www.seamframework.org/Community/EJBSLSBInjectionIssues
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2209) Improve ways to transfer state information from a nested conversation to the parent conversation context
by Wolfgang Schwendt (JIRA)
Improve ways to transfer state information from a nested conversation to the parent conversation context
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-2209
URL: http://jira.jboss.com/jira/browse/JBSEAM-2209
Project: JBoss Seam
Issue Type: Bug
Components: Core
Reporter: Wolfgang Schwendt
Priority: Critical
When a nested conversation ends, it is difficult to transfer an ending result back to the parent conversation. The following approach is currently not viable with Seam: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. So once the nested conversation scope gets destroyed at the end of the nested conversation, the saved wrappers for the component from the parent conversation get destroyed as well.
Scenario:
Suppose that we have a component AA in the conversation context with a field reference named 'bb' to an another component Q. At some point of time this reference is moved by the ManagedEntityIdentityInterceptor to a conversation-scoped context variable with the name "AA.bb". Then we start a nested conversation. While the nested conversation is in progress, we can call a method of component AA and successfully access the field bb because at the time of the method invocation, the ManagedEntityIdentityInterceptor can retrieve the saved wrapper for field bb from the parent conversation context and put the contained reference into the component AA.
But then we call a method of component AA which changes the field bb. At the end of this method invocation, the ManagedEntityIdentityInterceptor moves the new value of reference field bb to a wrapper saved in the nested (!) conversation context. Afterwards we end the nested conversation and the parent conversation resumes again. When we then call a method of component AA again, the ManagedEntityIdentityInterceptor retrieves the wrapper for field bb from the conversation context. But this wrapper contains the old value for field bb, not the new value. Note that the wrapper with the new value for field bb got destroyed already at the time when the nested conversation context was destroyed.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118936&start=30
Feature request regarding nested conversations
Tue Sep 18, 2007 00:28 AM
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121852
Nested Conversations (tricky interceptor)
Mon Oct 22, 2007 11:03 AM
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2082) JMS Topic subscriptions never released
by Scott McNab (JIRA)
JMS Topic subscriptions never released
--------------------------------------
Key: JBSEAM-2082
URL: http://jira.jboss.com/jira/browse/JBSEAM-2082
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 2.0.0.CR2, 2.0.0.CR1, 1.2.1.GA, 1.2.0.GA, 2.0.0.GA
Environment: JBossAS 4.2.0.GA, All platforms.
Reporter: Scott McNab
Assigned To: Shane Bryzak
In the current Seam remoting implementation, there is no mechanism to clean up and release JMS topic subscriptions for clients that may have subscribed to a JMS topic, but who do not explicitly unsubscribe() (e.g. due to a coding error or if the client simply disappears)
Unless a web-client specifically calls Seam.Remoting.unsubscribe(), the RemoteSubscriber object is never released, and the corresponding TopicSession and TopicSubscriber resources will be held open indefinitely. This will cause the JMS provider to store an ever-growing list of undelivered topic messages, which will eventually result in an out of memory crash.
Seam Remoting needs to be able to correctly identify situations whereby a RemoteSubscriber is no longer in use, and release resources accordingly.
One possible solution might be to periodically check all subscriptions in the SubscriptionRegistry and release any which have not had a recent poll request beyond a certain time limit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months