[JBoss JIRA] (JBSEAM-4006) Setting transaction.auto_close_session=true creates "Session is closed" warnings
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4006?page=com.atlassian.jira.plugi... ]
Marek Novotny closed JBSEAM-4006.
---------------------------------
Resolution: Rejected
> Setting transaction.auto_close_session=true creates "Session is closed" warnings
> --------------------------------------------------------------------------------
>
> Key: JBSEAM-4006
> URL: https://issues.jboss.org/browse/JBSEAM-4006
> Project: Seam 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.0.SP1
> Environment: Seam 2.1.0.SP1
> Spring 2.5.5
> Seam Managed Persistence Context enabled
> JTA transaction Manager declared in Spring used.
> Persistence unit property :"hibernate.transaction.auto_close_session=true" set to true
> Reporter: Luc DEW
>
> Setting the hibernate.transaction.auto_close_session property to true cause "Session is closed!;" warnings in Seam with Seam Managed Persistence Context.
> Because for instance, in the SeamPhaseListener's afterServletPhase(PhaseEvent event) the following code is executed:
> handleTransactionsAfterPhase(event);
> if ( event.getPhaseId() == RENDER_RESPONSE )
> {
> afterRenderResponse(facesContext);
> }
> else if ( facesContext.getResponseComplete() )
> {
> afterResponseComplete(facesContext);
> }
> If the current JSF phase is "after RENDER_RESPONSE" transaction is terminated (commited or rollbacked) by the handleTransactionsAfterPhaseMethod(event) method. If auto_close_session mode is set to true, the session is closed. But the afterRenderResponse(facesContext) is then executed. This method tries to change session's flush mode. Therefore, a "session is already closed" warning appears !
> It should be documented that setting this parameter to true can cause this kind of errors in Seam. But not setting this parameter to true can cause Hibernate sessions leakage if the persistence context not handled by Seam. Also, i am not sure that in any Seam use cases, the managed persistence context is closed properly. Some examples a method annotated @Observer("org.jboss.seam.postInitialization") with or @Async...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBSEAM-4022) ComponentScanner fails with classes in WEB-INF/classes on websphere
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4022?page=com.atlassian.jira.plugi... ]
Marek Novotny closed JBSEAM-4022.
---------------------------------
Resolution: Rejected
> ComponentScanner fails with classes in WEB-INF/classes on websphere
> -------------------------------------------------------------------
>
> Key: JBSEAM-4022
> URL: https://issues.jboss.org/browse/JBSEAM-4022
> Project: Seam 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.1.GA
> Environment: Websphere 7.0 (also reported on Websphere 6.1)
> Reporter: John Eckhart
> Attachments: classdescriptor.patch
>
>
> This bug is a follow-on to 2347 which was rejected. Since it doesn't appear possible to request a bug be "reopened", I've created a new bug to track the problem.
> The problem: When a Seam annotated class is included in a WAR file, the filename of the class will be "WEB-INF/classes/com/mycompany/MyClass.class". Theoretically, this IS the filename as the classes are packaged under WEB-INF/classes, however, the classloader does not recognize/ignore "WEB-INF/classes/" as part of the name (which is logical, since the classpath includes everything under this directory). This causes ComponentScanner to throw the following exception: java.lang.NoClassDefFoundError: WEB-INF.classes.com.mycompany.Myclass
> The previous issue was rejected with the following rationale: "This turned out to be a user error, not a websphere issues. The classpath was correct, but the user put a META-INF/components.xml in the WAR which causes the scanning error."
> However:
> Where would the components.xml go if a project is broken into WAR, JAR (for JPA), JAR (for EJB), and finally EAR (containing the mentioned components)?
> Based on the examples I've read for WebSphere , the recommended place for components.xml is in the WAR file. Moreover, it would stand to reason that including seam components in the WAR would be beneficial (ie POJO components as backing beans for jsf pages).
> I ran into this issue recently in Websphere 7.0 where I had a Seam managed POJO as a backing bean to a JSF page. The bean wouldn't load because of the NoClassDefFoundError. I patched seam to work-around this issue as I didn't see any other solution (JSF backing beans don't belong in my JPA or EJB layers).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBSEAM-4081) Seam Dev Tools Ref Guide 3.0.1.GA Chapter 5 Seam Wizards Not working according to tutorial. Server errors.
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4081?page=com.atlassian.jira.plugi... ]
Marek Novotny closed JBSEAM-4081.
---------------------------------
Resolution: Out of Date
> Seam Dev Tools Ref Guide 3.0.1.GA Chapter 5 Seam Wizards Not working according to tutorial. Server errors.
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBSEAM-4081
> URL: https://issues.jboss.org/browse/JBSEAM-4081
> Project: Seam 2
> Issue Type: Bug
> Components: Seam Text
> Affects Versions: 2.1.1.GA, 2.1.2.CR2
> Environment: JBossAS 5.0.1.GA, Windows Server 2003, localhost:8080, seam 2.1.2.CR2, Eclipse 3.4.2 with JbossTools 3.0.1.GA, PostgreSQL 8.3
> Reporter: Jeffrey Wexler
> Assignee: Dan Allen
>
> Going through tutorial. Chapter 5 encountering server errors.
> 5.2 New Seam Form & 5.3 New Seam Conversation.
> After creating the new form, when enter a value in the text field and click on FormMethod get Jboss Seam Debug Page.
> Also get a Jboss Seam debug page after creating a seam conversation and then clicking on the Begin button.
> Also get a Jboss Seam debug page after creating an Action (5.1) and clicking on the button.
> Below is the exception for the case of entering a value in th text field of the created Form.
> Exception during request processing:
> Please see comment that I just added (below) for the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBSEAM-5130) Add security warning to seam logging docs
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-5130?page=com.atlassian.jira.plugi... ]
Marek Novotny resolved JBSEAM-5130.
-----------------------------------
Assignee: Marek Novotny
Fix Version/s: 2.3.2.CR1
Resolution: Done
> Add security warning to seam logging docs
> -----------------------------------------
>
> Key: JBSEAM-5130
> URL: https://issues.jboss.org/browse/JBSEAM-5130
> Project: Seam 2
> Issue Type: Bug
> Components: Documentation Issues
> Affects Versions: 2.2.2.Final, 2.3.0.Final, 2.3.1.Final
> Reporter: David Jorm
> Assignee: Marek Novotny
> Priority: Critical
> Fix For: 2.3.2.CR1
>
>
> It has been reported that seam parses expression language (EL) statements in log messages. This is safe if used as intended - all user-provided input is supposed to be bound to a variable in the EL, conceptually similar to bound parameters in SQL. If an application did not use the Seam logging facility as intended, and included user-provided strings in log messages directly via string concatenation, then a remote attacker could use this flaw to execute arbitrary code in the context of the application server. The documentation does not highlight this issue at all, and it seems to be highly likely that some seam-based application developers would have used string concatenation with user-provided strings in log messages.
> This needs to be addressed in all seam docs as a priority:
> http://docs.jboss.org/seam/2.3.1.Final/reference/html_single/#d0e4185
> http://docs.jboss.org/seam/2.3.0.Final/reference/en-US/html_single/#d0e4185
> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html_single/#d0e4254
> I suggest adding a big red warning admonition such as:
> Title:
> SECURITY WARNING: Do not use string concatenation to construct log messages
> Body:
> Seam logging evaluates expression language (EL) statements in log messages. This is safe if used as intended, because all user-provided input is bound to a parameter in the EL statement. If an application does not use the Seam logging facility as intended, and includes user-provided strings in log messages directly via string concatenation, then a remote attacker could inject EL statements directly into the log messages, which would be evaluated on the server. This could lead to a variety of security impacts. To protect against this issue, ensure that all user-provided input in log messages is bound to a parameter, and not included directly in log messages using string concatenation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBSEAM-4163) Nullpointerexception from s:selectItems when noSelectionLabel is present and converter of selectOneMenu evaluates to null
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4163?page=com.atlassian.jira.plugi... ]
Marek Novotny closed JBSEAM-4163.
---------------------------------
Resolution: Rejected
> Nullpointerexception from s:selectItems when noSelectionLabel is present and converter of selectOneMenu evaluates to null
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JBSEAM-4163
> URL: https://issues.jboss.org/browse/JBSEAM-4163
> Project: Seam 2
> Issue Type: Bug
> Components: JSF Integration
> Affects Versions: 2.1.1.GA
> Reporter: Jakub Janczak
>
> The problem is that when you have the noSelectionLabel in s:selectItems it installs a converter chain in the h:selectOneMenu.
> <h:selectOneMenu converter="#{conv}" .... >
> <s:selectItems noSelectionLabel="#{messages['noSelectionLabel']}" />
> </h:selectOneMenu>
> So when the #{conv} evaluates to null it blows. The problem is in the PrioritizableConverter as it has the constructor:
> public PrioritizableConverter(ValueExpression vb, int priority)
> {
> this.valueExpression = vb;
> this.priority = priority;
> }
> and then
> public String getAsString(FacesContext context, UIComponent component, Object value)
> throws ConverterException
> {
> return getDelegate().getAsString(context, component, value);
> }
> public Converter getDelegate()
> {
> if (valueExpression != null)
> {
> return (Converter) valueExpression.getValue(FacesContext.getCurrentInstance().getELContext());
> }
> else
> {
> return delegate;
> }
> }
> so if getDelegate returns null it's not able to convert.
> The solution would be to disable adding the PrioritizableConverter to the chain when the #{conv} evaluates to null (ConverterChain.java : 73)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months