[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1619) support for Glassfish in seam-gen
by Dan Allen (JIRA)
support for Glassfish in seam-gen
---------------------------------
Key: JBSEAM-1619
URL: http://jira.jboss.com/jira/browse/JBSEAM-1619
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 2.0.0.BETA1
Environment: Glassfish V2
Reporter: Dan Allen
I believe that adding support for Glassfish will help promote the adoption of Seam. In my mind, Tomcat is not nearly as important because it is not a Java EE-compliant environment and seam-gen is all about creating compliant projects.
Supporting Glassfish is actually quite straightforward. There are a couple of assumptions that are made by seam-gen that render it incompatible with a generic Java EE-compliant application server. Here is what needs to change:
1. The java:/ prefix on the data source causes problems with other servers. This can be easily brought into compliance by adding <use-java-context>false</use-java-context> to the *-ds.xml files and removing the java:/ prefix from the persistence-*.xml files in the seam-gen/resources/META-INF directory
2. Glassfish does not use Hibernate EntityManager as the default JPA provider, and therefore does not have any of its jar files. Of course, we could just make everyone copy necessary hibernate jar files into the glassfish installation directory, but that just isn't going to go over well. I think a better approach is to modify the build.xml file to copy the following three libraries if the property hibernate.needed=true is set:
hibernate-all.jar
thirdparty-all.jar
jboss-archive-browsing.jar (not currently in the seam distribution, but stuck inside the jboss-embedded-all.jar file)
3. Make the hibernate.transaction.manager_lookup_class parameterized, perhaps asking during setup
4. Removing the .war suffix on the exploded archive directory (so that Glassfish can deploy the directory using asadmin deploydir)
That's it! Then you can have Glassfish working.
--
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
15 years, 1 month
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1206) improve i18n in seam-gen
by Pierre Raoul (JIRA)
improve i18n in seam-gen
------------------------
Key: JBSEAM-1206
URL: http://jira.jboss.com/jira/browse/JBSEAM-1206
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 1.2.1.GA
Reporter: Pierre Raoul
It would be great that seam-gen will generate crud pages and classes for an existing Entity class:
- with all the literals replaced with #{messages['key']}
- and i18n default messages generated
Herewith files of a draft version.
I used the jpaconfiguration propositions from JBSEAM-843.
It works under Eclipse: the target "updatecrud" in the project build.xml can be run from Eclipse.
Nota: to translated Enum type, test of this type had to be added. I did it through file inclusion. So it can be used with any other project specific types, e.g. in the attached zip with joda-time type.
--
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
15 years, 1 month
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1712) Allow options for SMPC per Nested Conversation
by Andy Gibson (JIRA)
Allow options for SMPC per Nested Conversation
----------------------------------------------
Key: JBSEAM-1712
URL: http://jira.jboss.com/jira/browse/JBSEAM-1712
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: Windows XP, Seam 2.0 Beta, JBoss 4.2
Reporter: Andy Gibson
I'd like to request the option to specify that a nested conversation gets it's own entity manager instance as opposed to sharing it with it's parent conversation and other nested conversations.
The problem with nested conversations is that you can't actually use them to edit multiple entities since when you flush the PC, you flush it for all conversations. This makes nested conversations only really useful for browsing data, and creating new top level conversation to edit items to isolate the flushes.
The only alternative is to use a non-Seam managed PC, and make use of the "PC per stateful bean" rule to map a single PC to a single backing bean, but you lose the benefits of a seam managed PC.
What might be nice is something like :
@Begin(nested=true, newPC=true)
and
<begin-conversation nested="true" newPC="true"/>
which would indicate that this new nested conversation gets it's own entity manager instance. The attribute would be ignored if this wasn't a nested conversation, and obviously, by default, the attribute is set to false, and a shared PC would be used in the nested conversation in such cases.
I'm already using one PC per conversation by using top level conversations to edit items, I'd just like to use one PC per nested conversation (where applicable) to get the benefits of nested conversations.
There are a couple of posts in the forums where I've touched on some of my problems with this issue :
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113362
--
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
15 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1498) inject JBoss service EJB with @In
by koen handekyn (JIRA)
inject JBoss service EJB with @In
---------------------------------
Key: JBSEAM-1498
URL: http://jira.jboss.com/jira/browse/JBSEAM-1498
Project: JBoss Seam
Issue Type: Feature Request
Components: EJB3
Reporter: koen handekyn
Priority: Minor
to inject a Service EJB into a seam component, for consistency it would certainly be very nice to be able to inject it within SEAM with @In and optionally adding an @Name attribute to the service class. it would be more consistent and shorter than the standard jboss approach (below)
private GlobalConfigurationMBean globalConfiguration;
@Depends ("upr:service=globalConfiguration")
public void setGlobalConfiguration(final GlobalConfigurationMBean globalConfiguration)
{
this.globalConfiguration = globalConfiguration;
}
--
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
15 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1707) @Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time
by Frits Jalvingh (JIRA)
@Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time
---------------------------------------------------------------------------------------------
Key: JBSEAM-1707
URL: http://jira.jboss.com/jira/browse/JBSEAM-1707
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: Tomcat 6.0.10, JavaBean mode, Hibernate 3.2.3, HBEM 3.3.1
Reporter: Frits Jalvingh
I have a bean defined as follows:
@Name("initBean")
@Startup()
@Scope(ScopeType.APPLICATION)
public class InitBean {
containing a method:
@Destroy
public void destroy() {
Builder.getInstance().terminate();
BuildBot.getInstance().stop();
}
It is meant to shutdown some daemons when the server stops.
When the server stops I get an exception:
01:15:39,703 WARN [Component] Exception calling component @Destroy method: initBean
java.lang.IllegalStateException: no event context active
at org.jboss.seam.web.ServletContexts.instance(ServletContexts.java:40)
at org.jboss.seam.web.Parameters.getRequestParameters(Parameters.java:39)
at org.jboss.seam.faces.Parameters.getRequestParameters(Parameters.java:64)
at org.jboss.seam.Component.injectParameters(Component.java:1334)
at org.jboss.seam.Component.inject(Component.java:1304)
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.intercept.RootInterceptor.invoke(RootInterceptor.java:106)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87)
at to.etc.saram.beans.InitBean_$$_javassist_0.destroy(InitBean_$$_javassist_0.java)
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:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
at org.jboss.seam.Component.callComponentMethod(Component.java:1957)
at org.jboss.seam.Component.callDestroyMethod(Component.java:1888)
at org.jboss.seam.Component.destroy(Component.java:1217)
at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:251)
at org.jboss.seam.contexts.Lifecycle.endApplication(Lifecycle.java:52)
at org.jboss.seam.contexts.ServletLifecycle.endApplication(ServletLifecycle.java:121)
at org.jboss.seam.servlet.SeamListener.contextDestroyed(SeamListener.java:39)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3866)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4502)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068)
at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448)
at org.apache.catalina.core.StandardService.stop(StandardService.java:510)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:602)
at org.apache.catalina.startup.Catalina.start(Catalina.java:577)
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:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
which seems to be caused by the bean Injector trying to access the request context which of course is no longer there. The bean contains only a single injected thingy which is the entityManager.
--
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
15 years, 4 months