[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1858) Ability to avoid view path repetition in pages.xml
by Matt Drees (JIRA)
Ability to avoid view path repetition in pages.xml
--------------------------------------------------
Key: JBSEAM-1858
URL: http://jira.jboss.com/jira/browse/JBSEAM-1858
Project: JBoss Seam
Issue Type: Feature Request
Reporter: Matt Drees
Priority: Minor
It would be fantastic if instead of this:
<page view-id="/admin/modules/additionalExpenses/registrantTypeSettings.xhtml">
<navigation from-action="#{additionalExpensesAdminManager.newExpense}">
<redirect view-id="/admin/modules/additionalExpenses/editExpense.xhtml"/>
</navigation>
<navigation from-action="#{additionalExpensesAdminManager.newSectionHeader}">
<redirect view-id="/admin/modules/additionalExpenses/editSectionHeader.xhtml"/>
</navigation>
</page>
I could do this:
<pages view-scope="/admin/modules/additionalExpenses/">
<page view-id="registrantTypeSettings.xhtml">
<navigation from-action="#{additionalExpensesAdminManager.newExpense}">
<redirect view-id="editExpense.xhtml"/>
</navigation>
<navigation from-action="#{additionalExpensesAdminManager.newSectionHeader}">
<redirect view-id="editSectionHeader.xhtml"/>
</navigation>
</page>
</pages>
It would be best if <pages> could be nested in other <pages>, but there are probably some other ramifications of that, so maybe it'd be better to introduce another element. Maybe <view-scope> or something.
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1990) Reloading app causes IllegalStateException when passivating session objects
by Matt Drees (JIRA)
Reloading app causes IllegalStateException when passivating session objects
---------------------------------------------------------------------------
Key: JBSEAM-1990
URL: http://jira.jboss.com/jira/browse/JBSEAM-1990
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.CR1
Environment: Tomcat 5.5
Reporter: Matt Drees
Priority: Minor
I haven't tested in other appservers.
Reloading the Hibernate example causes the following stacktrace:
Sep 26, 2007 9:15:37 PM org.apache.catalina.session.StandardSession passivate
SEVERE: Session attribute event listener threw exception
java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application
at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36)
at org.jboss.seam.contexts.Lifecycle.beginCall(Lifecycle.java:84)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:113)
at org.jboss.seam.intercept.RootInterceptor.invokeAndHandle(RootInterceptor.java:84)
at org.jboss.seam.intercept.JavaBeanInterceptor.callPrePassivate(JavaBeanInterceptor.java:135)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:77)
at org.jboss.seam.example.hibernate.HotelSearchingAction_$$_javassist_2.sessionWillPassivate(HotelSearchingAction_$$_javassist_2.java)
at org.apache.catalina.session.StandardSession.passivate(StandardSession.java:764)
at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:515)
at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4345)
at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2984)
at org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:906)
at org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:473)
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2694) QuartzDispatcher and ClassNotFoundException
by Markus Heidt (JIRA)
QuartzDispatcher and ClassNotFoundException
---------------------------------------------
Key: JBSEAM-2694
URL: http://jira.jboss.com/jira/browse/JBSEAM-2694
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.1.GA
Environment: AS 4.2.1
Reporter: Markus Heidt
Error Message after startup of JBoss AS
***********************
21:16:01,118 ERROR [ErrorLogger] Job (DEFAULT.-6ad11a7d:1185c88089f:-7f8e threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception.
[See nested exception: org.jboss.seam.InstantiationException:
Could not instantiate Seam component: danteUsersRetriever]
at org.quartz.core.JobRunShell.run(JobRunShell.java:214)
...
Caused by: javax.naming.CommunicationException
[Root
exception is java.lang.ClassNotFoundException:
No ClassLoaders found for: org.domain.QuartzTest.session.DanteUsersRetriever
(no security manager: RMI class loader disabled)]
**********************
Reproducible:
* Create new seam project
* change components.xml:
***********************
<components
...
xmlns:async="http://jboss.com/products/seam/async"
...
xsi:schemaLocation=
"...http://jboss.com/products/seam/async http://jboss.com/products/seam/async-2.0.xsd...
>
<async:quartz-dispatcher/>
***********************
* Add two classes
DanteUsersTimer.java
***********************
package org.domain.QuartzTest.session;
import org.jboss.annotation.ejb.Local;
@Local
public interface DanteUsersTimer {
public void start() throws Exception;
public void cancel();
public void stop();
}
***********************
DanteUsersTimerBean.java
***********************
package org.domain.QuartzTest.session;
import org.jboss.seam.ScopeType;
import org.jboss.seam.annotations.Destroy;
import org.jboss.seam.annotations.Logger;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Observer;
import org.jboss.seam.annotations.Scope;
import org.jboss.seam.annotations.Startup;
import org.jboss.seam.async.CronSchedule;
import org.jboss.seam.async.QuartzDispatcher;
import org.jboss.seam.async.QuartzTriggerHandle;
import org.jboss.seam.log.Log;
@Name("danteUsersTimer")
@Scope(ScopeType.APPLICATION)
@Startup
public class DanteUsersTimerBean implements DanteUsersTimer {
private static final String defaultTrigger = "1 * * * * ?"; //every minute
@Logger private Log log;
private QuartzTriggerHandle handle;
private String trigger = defaultTrigger;
@Observer("org.jboss.seam.postInitialization")
public void start() throws Exception{
setTrigger(defaultTrigger);
}
public void restoreDefault(){
setTrigger(defaultTrigger);
}
public void setTrigger(String trigger){
try{
QuartzTriggerHandle handle = QuartzDispatcher.instance().scheduleTimedEvent("retrieveDanteUsers",
new CronSchedule((Long) null, trigger));
if (this.handle != null)
this.handle.cancel();
this.handle = handle;
this.trigger = trigger;
}
catch (Exception e){
log.error("setTrigger(): #0", e, trigger);
}
}
public String getTrigger(){
return trigger;
}
public void cancel(){
try{
if (handle != null)
handle.cancel();
handle = null;
trigger = null;
}
catch (Exception e){
log.error("cancel(): #0", e, trigger);
}
}
@Destroy
public void stop(){
cancel();
}
}
***********************
DanteUsersRetriever.java
***********************
package com.dai.dante_tscm.session.users;
import org.jboss.annotation.ejb.Local;
@Local
public interface DanteUsersRetriever {
public void retrieve();
}
***********************
DanteUsersRetrieverBean.java
***********************
package com.dai.dante_tscm.session.users;
import javax.ejb.Stateless;
import org.jboss.seam.annotations.Logger;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Observer;
import org.jboss.seam.log.Log;
@Name("danteUsersRetriever")
@Stateless
public class DanteUsersRetrieverBean implements DanteUsersRetriever{
@Logger private Log log;
@Observer("retrieveDanteUsers")
public void retrieve() {
log.info("retrieve dante users");
}
}
***********************
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2331) EntityHome throws "EntityManager is closed" when app marked <distributable/>
by Chris Fraser (JIRA)
EntityHome throws "EntityManager is closed" when app marked <distributable/>
----------------------------------------------------------------------------
Key: JBSEAM-2331
URL: http://jira.jboss.com/jira/browse/JBSEAM-2331
Project: JBoss Seam
Issue Type: Bug
Reporter: Chris Fraser
Attachments: WidgetHome.java
Please see my forum post for details on this matter: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124779
Attached to this ticket is the source for my WidgetHome EntityHome class. I can upload additional files from the project if that will help, but this can be easily recreated by seam-genning a new project, and generating entities from a DB that's got a single table (Widget) with 2 columns (widgetId, widgetName). Once that's done, drop my WidgetHome in place of the seam-genned one, mark the app <distributable/> in web.xml, build/deploy/run the app and you'll see the problem when you create/update a widget.
If this is not a bug, then it would at least be nice to have some best practices documented for using EntityHomes (and, as it turns out, EntityQuerys) in an application that has been marked <distributable/>.
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2725) Enable jBPM's EJB2 based timers
by Martin Putz (JIRA)
Enable jBPM's EJB2 based timers
-------------------------------
Key: JBSEAM-2725
URL: http://jira.jboss.com/jira/browse/JBSEAM-2725
Project: JBoss Seam
Issue Type: Feature Request
Components: BPM
Affects Versions: 2.0.1.GA
Reporter: Martin Putz
With jBPM 3.2.x, there are basically two options to run the timer service: as a separate thread running in the background, or as an EJB 2.x timer implementation. While the first option, which is started by the JobExecutorServlet, works in a Seam environment, the second option of using the EJB2 based implementation doesn't work due to tx issues. As the EJB2 timer implementation is the preferred option in an enterprise environment and as it offers better clustering capabilities, it would be nice to have it available in a Seam environment.
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2683) QueueSession is null when injected in classes with methods annotated as @Asynchronous
by Vassilis Petropoulos (JIRA)
QueueSession is null when injected in classes with methods annotated as @Asynchronous
-------------------------------------------------------------------------------------
Key: JBSEAM-2683
URL: http://jira.jboss.com/jira/browse/JBSEAM-2683
Project: JBoss Seam
Issue Type: Bug
Components: Async
Affects Versions: 2.0.0.GA
Environment: win xp, jboss 4.2.2, Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Reporter: Vassilis Petropoulos
a) components.xml
<jms:managed-queue-sender name="processSMSQueueSender" auto-create="true" queue-jndi-name="queue/processSMS" />
b) SmsHandlerBean.java
@Stateless
@Name("smsHandler")
public class SmsHandlerBean implements SmsHandler {
@In(create=true) SMSScheduler smsScheduler;
public void test(Sms sms) throws Exception {
QuartzTriggerHandle quartzTriggerHandle = smsScheduler.schedule(
sms.getId(), sms.getStartDate(), sms.getEndDate(), sms.getCronExpression());
}
}
c) SMSScheduler.java
@Name("smsScheduler")
public class SMSScheduler {
@In QueueSender processSMSQueueSender;
@In QueueSession queueSession;
@Asynchronous
@Transactional
public QuartzTriggerHandle schedule(int smsId, @Expiration Date when, @FinalExpiration Date endDate, @IntervalCron String cron) {
try {
processSMSQueueSender.send(queueSession.createObjectMessage(smsId));
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
when scheduler fires queueSession, processSMSQueueSender are null. This also happens if use create=true.
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2659) more friendly documentation
by Sebastian Hennebrueder (JIRA)
more friendly documentation
---------------------------
Key: JBSEAM-2659
URL: http://jira.jboss.com/jira/browse/JBSEAM-2659
Project: JBoss Seam
Issue Type: Task
Components: Documentation Issues
Affects Versions: 2.0.1.GA, 2.0.0.GA
Environment: any
Reporter: Sebastian Hennebrueder
Priority: Minor
I would propose a more friendly formulation in the documentation. See my mail on the developer mailinglist
http://lists.jboss.org/pipermail/seam-dev/2008-February/000021.html
-------
existing formulation
In almost all enterprise applications, the database is the primary bottleneck, and the least scalable tier of the
runtime environment. People from a PHP/Ruby environment will try to tell you that so-called "shared nothing"
architectures scale well. While that may be literally true, I don't know of many interesting multi-user applica-
tions which can be implemented with no sharing of resources between different nodes of the cluster. What these
silly people are really thinking of is a "share nothing except for the database" architecture. Of course, sharing
the database is the primary problem with scaling a multi-user application—so the claim that this architecture is
highly scalable is absurd, and tells you a lot about the kind of applications that these folks spend most of their
time working on.
-------------
alternative formulation:
In almost all enterprise applications, the database is the primary bottleneck, and the least scalable tier of the runtime environment. People from a PHP/Ruby environment state that their lightweigth architecture - which is not sharing resources - scales well. We do not agree here. A PHP/Ruby will share the database which is in large scale application normally already the bottleneck. Lightweight can be fast in smaller applications but is not scalable.
This chapter explains how Seam uses caching to provide a architecture which is fast and scalable at the same time.
--
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
17 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2663) ResourceLoader context problem
by Pierre Ingmansson (JIRA)
ResourceLoader context problem
------------------------------
Key: JBSEAM-2663
URL: http://jira.jboss.com/jira/browse/JBSEAM-2663
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.1.GA
Environment: Windows XP, Eclipse, Seam running in a Tomcat 5.5.25
Reporter: Pierre Ingmansson
Priority: Minor
The ResourceLoader, a core component of Seam, is hard-coded in the ResourceLoader's instance()-method, to be in the stateless context.
Some of the core components in Seam use this static instance()-method to fetch the ResourceLoader. Therefore you can not overload the ResourcLoader with your own component that want to be in another context than stateless.
The ResourceLoader is accessed frequently during the JSF page rendering, and because of the stateless context setting of the ResourceLoader, a new instance of ResourceLoader is instantiated and initlialized everytime it is accessed. My opinion is that it is unnecessary to create a new instance of the ResourceLoader everytime it is accessed, it's just bad for performance.
Also if you want to override the ResourceLoader with your own component, it is only possible to do so in the stateless-context. There is (right now) no way of creating a MyResourceLoader with @Scope(ScopeType.APPLICATION) for example.
This problem is somewhat related to JIRA issue JBSEAM-2364. I bumped in to the ResourceLoader-overloading-problem when trying to find a workaround for this other problem.
--
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
17 years, 10 months