[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1814) DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
by Matt Drees (JIRA)
DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
-------------------------------------------------------------------------
Key: JBSEAM-1814
URL: http://jira.jboss.com/jira/browse/JBSEAM-1814
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.BETA1
Environment: seam cvs (20070816.1709)
Reporter: Matt Drees
Priority: Minor
The following test fails:
@Name("dataModelComponent")
@Scope(ScopeType.CONVERSATION)
public class DataModelComponent extends EntityQuery {
@Override
public String getEjbql() {
return "from java.lang.Object o";
}
}
public class DataModelComponentTest extends SeamTest{
@Test
public void test() throws Exception {
new FacesRequest() {
@Override
protected void renderResponse() throws Exception {
DataModel model = (DataModel) getValue("#{dataModelComponent.dataModel}");
assert model.getWrappedData() != null;
}
}.run();
}
}
Because the component is conversation-scoped, a ManagedEntityIdentityInterceptor is attached, which nulls the wrapped List after getDataModel() is called.
In the referenced forum, Gavin indicated he hadn't decided whether this should be expected behavior or not, and asked for a jira issue.
If it is expected behavior (I hope not), I think either EntityQuery should not have a getDataModel() attribute, or it should be documented and/or programmatically enforced that EntityQuerys should not be conversation-scoped.
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1875) Rework configuration chapter
by Pete Muir (JIRA)
Rework configuration chapter
----------------------------
Key: JBSEAM-1875
URL: http://jira.jboss.com/jira/browse/JBSEAM-1875
Project: JBoss Seam
Issue Type: Task
Components: Documentation
Affects Versions: 2.0.0.BETA1
Reporter: Pete Muir
Fix For: 2.0.0.GA
Rework configuration chapter to make it a generic discussion of configuring and packaging Seam applications. Move platform specific stuff to platform specific chapter.
i.e.
25 Configuring & Packaging Seam Applications
25.1 Basic Seam Configuration
25.1.1 Integrating Seam with JSF and the Servlet Container
25.1.2 Using Facelets
25.1.3 Seam Resource Servlet
25.1.4 Seam Filter
25.1.5. Integrating Seam with your EJB container
25.2 Seam Applications in a JEE 5 environment
25.3 Seam Applications in a J2EE environment
25.4 Seam Applicaitons in a JSE environment
* Move JBPM configuration to JBPM chapter
* Move JBoss AS stuff to new JBoss AS chapter
* Move JBoss Embedded stuff to new JBoss Embedded Chapter
26 Seam on JBoss AS
26.1 Seam on JBoss AS 4.0
* Includes stuff on install JSF 1.2 from Chapter 2
26.2 Seam on JBoss AS 4.2
27 Seam with JBoss Embedded
28 Seam on OC4J
29 Seam on Glassfish
* Needs writing!
--
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
16 years, 3 months
[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
16 years, 5 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
16 years, 5 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
16 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1879) Magic mime type detection support
by Christian Bauer (JIRA)
Magic mime type detection support
---------------------------------
Key: JBSEAM-1879
URL: http://jira.jboss.com/jira/browse/JBSEAM-1879
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Reporter: Christian Bauer
Priority: Minor
A component I can call to find out what mime type a particular byte[] or ByteInputStream is. The only existing solution in Java is http://sourceforge.net/projects/jmimemagic/ but it's basically an unmaintained half-working pile of junk.
It's interesting that nobody ever build a simple port of file(1), which you get on every unix box, together with a fantastic (/etc/magic or /usr/share/file/magic on the Mac) database of magic bytes found in file headers. We should just take that database (or the source database from which it is generated) and write our own file(1) for Seam. Search for "mime magic java" with Google and you see why it's needed. Try "file myfile.foo" on every unix box (well, younger than 10 years) and you see how it works.
--
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
16 years, 6 months