August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3769) Implement graceful shutdown for batch tasks

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-3769: ------------------------------------ Summary: Implement graceful shutdown for batch tasks Key: WFLY-3769 URL: https://issues.jboss.org/browse/WFLY-3769 Project: WildFly Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Batch Reporter: Stuart Douglas Assignee: Jason Greene This should make sure that all batch jobs have completed before the container shuts down, and not allow new jobs to start while the container is suspended. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3768) Implement graceful shutdown for MDB's

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-3768: ------------------------------------ Summary: Implement graceful shutdown for MDB's Key: WFLY-3768 URL: https://issues.jboss.org/browse/WFLY-3768 Project: WildFly Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB, JMS Reporter: Stuart Douglas Assignee: David Lloyd This should stop message delivery when notified of a suspend (and possibly perform other actions?). The existing EJB suspend interceptor should track active MDB requests to allow the container to suspend once they are complete. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-578) add double null check to asm stub builders

by david hendi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-578?page=com.atlassian.jira.plugin... ] david hendi updated DROOLS-578: ------------------------------- Attachment: asm-builder-double-null-check.patch patch for fixing the blocking issue > add double null check to asm stub builders > ------------------------------------------ > > Key: DROOLS-578 > URL: https://issues.jboss.org/browse/DROOLS-578 > Project: Drools > Issue Type: Patch > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Beta3, 6.1.0.Beta4, 6.1.0.CR1, 6.1.0.CR2, 6.1.0.Final > Reporter: david hendi > Assignee: Mark Proctor > Attachments: asm-builder-double-null-check.patch > > > currently the code generated does a null check within the synchronized code. this forces all threads to block while the check is made even after the check returns false. by adding a double null check, the synchronized code is bypassed once the check is satisfied. > public void evaluate(KnowledgeHelper paramKnowledgeHelper, WorkingMemory paramWorkingMemory) > throws Exception > { > if (this.consequence == null) { > synchronized (this) { > if (this.consequence == null) { > ConsequenceGenerator.generate(this, paramKnowledgeHelper, paramWorkingMemory); > } > } > } > this.consequence.evaluate(paramKnowledgeHelper, paramWorkingMemory); > } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-578) add double null check to asm stub builders

by david hendi (JIRA)

david hendi created DROOLS-578: ---------------------------------- Summary: add double null check to asm stub builders Key: DROOLS-578 URL: https://issues.jboss.org/browse/DROOLS-578 Project: Drools Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Final, 6.1.0.CR2, 6.1.0.CR1, 6.1.0.Beta4, 6.1.0.Beta3, 6.1.0.Beta2, 6.1.0.Beta1 Reporter: david hendi Assignee: Mark Proctor currently the code generated does a null check within the synchronized code. this forces all threads to block while the check is made even after the check returns false. by adding a double null check, the synchronized code is bypassed once the check is satisfied. public void evaluate(KnowledgeHelper paramKnowledgeHelper, WorkingMemory paramWorkingMemory) throws Exception { if (this.consequence == null) { synchronized (this) { if (this.consequence == null) { ConsequenceGenerator.generate(this, paramKnowledgeHelper, paramWorkingMemory); } } } this.consequence.evaluate(paramKnowledgeHelper, paramWorkingMemory); } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-31) The JBoss Modules schemas are missing from the build

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-31?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFCORE-31: ------------------------------------ Assignee: Eduardo Martins (was: Stuart Douglas) > The JBoss Modules schemas are missing from the build > ---------------------------------------------------- > > Key: WFCORE-31 > URL: https://issues.jboss.org/browse/WFCORE-31 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 1.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3698. ---------------------------------- Resolution: Rejected This looks like a problem with CDI being active in a deployment that it previously would not have been. Just disable CDI by adding the following beans.xml: {code} <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" version="1.1" bean-discovery-mode="none"> </beans> {code} or by use jboss-deployment-structure.xml to disable the CDI subsystem for the deployment. > Could not inject persistence unit into CDI managed bean > ------------------------------------------------------- > > Key: WFLY-3698 > URL: https://issues.jboss.org/browse/WFLY-3698 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, JPA / Hibernate > Affects Versions: 8.1.0.Final > Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop > Reporter: Oscar Calderon > Assignee: Stuart Douglas > Original Estimate: 1 week > Remaining Estimate: 1 week > > I have a project running Spring 4 & JSF 2.1 using Primefaces 5 and Hibernate JPA 2.0. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit"). > Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error: > Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment > But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log: > 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [ > name: persUnit > ...] > But when i try to inject it, it doesn't -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3704) WebSocket Sessions must be manually closed

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3704?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3704. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done This should be fixed now > WebSocket Sessions must be manually closed > ------------------------------------------ > > Key: WFLY-3704 > URL: https://issues.jboss.org/browse/WFLY-3704 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web Sockets > Affects Versions: 8.1.0.Final > Reporter: Cody Lerum > Assignee: Stuart Douglas > Labels: websockets > Fix For: 9.0.0.Beta1 > > > Currently if a WebSocket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE. > The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like > {code} > for (Session session : sessions) { > if (!session.isOpen()) { > session.close(); > } > } > {code} > This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp

by Gael Marziou (JIRA)

[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ] Gael Marziou edited comment on WFLY-3385 at 8/25/14 2:45 PM: ------------------------------------------------------------- I submitted a [pull request|https://github.com/undertow-io/undertow/pull/244] where I back ported the fix from 1.1 branch to 1.0.15 was (Author: gmarziou): I submitted a [https://github.com/undertow-io/undertow/pull/244][pull request] where I back ported the fix from 1.1 branch to 1.0.15 > when using jsp:include the jsp:param being encoded at the included jsp > ---------------------------------------------------------------------- > > Key: WFLY-3385 > URL: https://issues.jboss.org/browse/WFLY-3385 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.1.0.CR2 > Reporter: roy mizrachi > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > I have JSP A that includes JSP B like this: > <jsp:include page="../anotherFolder/B.jsp"> > <jsp:param name="pathToRootContext" value='../' /> > </jsp:include> > In JSP B i have the following: > String pathToRootContext = request.getParameter("pathToRootContext"); > The value i get in the pathToRootContext is "..%2f" > I tried the following but it didn't help: > <servlet-container name="default" default-encoding="UTF-8"> > <jsp-config development="true" java-encoding="UTF-8"/> > </servlet-container> -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp

by Gael Marziou (JIRA)

[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ] Gael Marziou commented on WFLY-3385: ------------------------------------ I submitted a [https://github.com/undertow-io/undertow/pull/244][pull request] where I back ported the fix from 1.1 branch to 1.0.15 > when using jsp:include the jsp:param being encoded at the included jsp > ---------------------------------------------------------------------- > > Key: WFLY-3385 > URL: https://issues.jboss.org/browse/WFLY-3385 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.1.0.CR2 > Reporter: roy mizrachi > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > I have JSP A that includes JSP B like this: > <jsp:include page="../anotherFolder/B.jsp"> > <jsp:param name="pathToRootContext" value='../' /> > </jsp:include> > In JSP B i have the following: > String pathToRootContext = request.getParameter("pathToRootContext"); > The value i get in the pathToRootContext is "..%2f" > I tried the following but it didn't help: > <servlet-container name="default" default-encoding="UTF-8"> > <jsp-config development="true" java-encoding="UTF-8"/> > </servlet-container> -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3766) Enhance DST changes handling by EJB CalendarBasedTimeout

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3766?page=com.atlassian.jira.plugin.... ] Eduardo Martins edited comment on WFLY-3766 at 8/25/14 1:52 PM: ---------------------------------------------------------------- This issue should also fix CalendarBasedTimeoutTestCase logic because there are issues shown on openjdk with updated (ART) timezone data, which adds a DST change that clashes with existent tests. was (Author: emmartins): This issue should also fix CalendarBasedTimeoutTestCase logic because there are issues shown on openjdk with updated (ART) timezone data. > Enhance DST changes handling by EJB CalendarBasedTimeout > -------------------------------------------------------- > > Key: WFLY-3766 > URL: https://issues.jboss.org/browse/WFLY-3766 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > EJB schedule expressions were designed to match UNIX Cron, but WildFly currently does not includes modern Cron handling of DST changes, i.e., on DST rollback avoid duplicate timeouts, and on DST forward avoid skipping timeouts on the skipped time period, running the related timeouts later. > This issue should add such behaviour to WildFly EJB CalendarBasedTimeout and add tests to ensure its correctness. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014