[JBoss JIRA] (WFLY-3387) myfaces support : Handling PostConstruct annotations - wrong order
by hamid aghazzaf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3387?page=com.atlassian.jira.plugin.... ]
hamid aghazzaf edited comment on WFLY-3387 at 6/5/14 8:30 AM:
--------------------------------------------------------------
Thank you for the detailed explanation. Should I wait for a patch fixing this problem ?
was (Author: ensahamid):
Thank you for the detailed explanation. Should I wait for a patch fixing this problem.
> myfaces support : Handling PostConstruct annotations - wrong order
> -------------------------------------------------------------------
>
> Key: WFLY-3387
> URL: https://issues.jboss.org/browse/WFLY-3387
> Project: WildFly
> Issue Type: Feature Request
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: hamid aghazzaf
> Assignee: Farah Juma
> Attachments: JavaServerFaces.rar, JavaServerFaces.rar
>
>
> The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed.
> This issue was resolved for tomcat7 server (https://issues.apache.org/jira/browse/MYFACES-1761). But remain with WildFly 8.0.Final .
> Bellow the list of third party artifacts used with their versions :
> activation-1.1.jar joda-time-2.3.jar velocity-1.6.2.jar
> aopalliance-1.0.jar jrobin-1.5.9.jar xml-apis-1.0.b2.jar
> aspectjrt-1.6.12.jar jsr305-1.3.9.jar xmlbeans-2.3.0.jar
> aspectjtools-1.6.2.jar jstl-1.2.jar
> aspectjweaver-1.6.11.jar junit-3.8.1.jar
> atmosphere-runtime-2.0.1.jar log4j-1.2.12.jar
> avalon-framework-4.1.3.jar logback-classic-0.9.30.jar
> bcmail-jdk14-1.38.jar logback-core-0.9.30.jar
> bcmail-jdk14-138.jar logkit-1.0.1.jar
> bcprov-jdk14-1.38.jar mail-1.4.jar
> bcprov-jdk14-138.jar myfaces-api-2.1.12.jar
> bctsp-jdk14-1.38.jar myfaces-impl-2.1.12.jar
> bsh-2.0b4.jar oro-2.0.8.jar
> castor-1.2.jar poi-3.7.jar
> cglib-3.0.jar poi-ooxml-3.7.jar
> commons-beanutils-1.8.2.jar poi-ooxml-schemas-3.7.jar
> commons-codec-1.3.jar primefaces-4.0.jar
> commons-collections-3.2.jar primefaces-extensions-0.7.1.jar
> commons-dbcp-1.2.2.jar servlet-api-2.3.jar
> commons-digester-1.8.jar slf4j-api-1.6.2.jar
> commons-fileupload-1.3.1.jar slf4j-log4j12-1.6.1.jar
> commons-io-2.4.jar smoothness-1.0.10.jar
> commons-lang-2.2.jar snakeyaml-1.6.jar
> commons-lang3-3.1.jar spring-aop-3.1.0.RELEASE.jar
> commons-logging-1.1.jar spring-asm-3.1.0.RELEASE.jar
> commons-pool-1.3.jar spring-aspects-3.1.0.RELEASE.jar
> dom4j-1.6.1.jar spring-beans-3.1.0.RELEASE.jar
> geronimo-stax-api_1.0_spec-1.0.jar spring-binding-2.3.2.RELEASE.jar
> groovy-all-2.0.1.jar spring-context-3.1.0.RELEASE.jar
> gsfar-base-0.0.8-SNAPSHOT.jar spring-context-support-3.1.0.RELEASE.jar
> gsfar-core-0.0.8-SNAPSHOT.jar spring-core-3.1.0.RELEASE.jar
> gsfar-domain-0.0.8-SNAPSHOT.jar spring-data-commons-1.5.2.RELEASE.jar
> gson-2.2.2.jar spring-data-commons-core-1.4.0.RELEASE.jar
> guava-12.0.jar spring-data-envers-0.1.0.RELEASE.jar
> hibernate-commons-annotations-4.0.1.Final.jar spring-data-jpa-1.3.4.RELEASE.jar
> hibernate-core-4.1.7.Final.jar spring-expression-3.2.1.RELEASE.jar
> hibernate-entitymanager-4.1.7.Final.jar spring-faces-2.3.2.RELEASE.jar
> hibernate-envers-4.1.7.Final.jar spring-integration-core-2.2.2.RELEASE.jar
> hibernate-jpa-2.0-api-1.0.1.Final.jar spring-integration-jdbc-2.2.2.RELEASE.jar
> hsqldb-1.8.0.7.jar spring-jdbc-3.1.0.RELEASE.jar
> itext-2.1.7.jar spring-js-2.3.2.RELEASE.jar
> jackson-annotations-2.1.4.jar spring-js-resources-2.3.2.RELEASE.jar
> jackson-core-2.1.4.jar spring-orm-3.1.0.RELEASE.jar
> jackson-databind-2.1.4.jar spring-retry-1.0.2.RELEASE.jar
> jasperreports-5.5.1.jar spring-security-config-3.1.4.RELEASE.jar
> javamelody-core-1.49.0.jar spring-security-core-3.1.4.RELEASE.jar
> javassist-3.15.0-GA.jar spring-security-web-3.1.4.RELEASE.jar
> jboss-logging-3.1.0.GA.jar spring-test-3.1.0.RELEASE.jar
> jboss-transaction-api_1.1_spec-1.0.0.Final.jar spring-tx-3.1.0.RELEASE.jar
> jcl-over-slf4j-1.7.1.jar spring-web-3.1.0.RELEASE.jar
> jcommander-1.12.jar spring-webflow-2.3.2.RELEASE.jar
> jcommon-1.0.15.jar spring-webmvc-3.2.1.RELEASE.jar
> jdtcore-3.1.0.jar stax-api-1.0.1.jar
> jfreechart-1.0.12.jar testng-6.4.jar
> I use spring profiles rather than maven profiles, this way, the same build (war file) is deploy-able in tomcat7 server as well as in Wildfly-8.0.0.Final.
> I have toggled two types of breakpoints in one of my managed bean :
> The first type is for the initialization method ( annotated with @PostConstruct )
> The second type is for setters of all properties aware of injection ( annotated with @ManagedProperty("# {xxx}
> ") ).
> When deploying to Tomcat7, every thing is well, all injections methods are invoked before the initialization method is called.
> But, when running under Wildfly-8.0.0.Final, the initialization method is called before, and this causes NullPointerException for properties not yet injected. This behavior is the same regardless the deployment is done from the administration console or from my eclipse workbench.
> We don’t have a lot of choices regarding the version of myfaces to use, as the only installer provided for adding support of myfaces to wildFly contains the version 2.1.12. And it's not a problem for continue with this version of myfaces. The installer is down-loadable from nexus : https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.wildfl...
> Thanks a lot in advance for your response.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-516?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-516:
----------------------------------
Attachment: 20140604.anotherleak_erratacorrige.zip
Uops sorry attaching again the reproducer. I missed the {{@timestamp}} notation in one of the {{declare}} parts, I missed this bit initially as this reproducer is a very stripped-down version of a real application.
However, behavior of the reproducer is exactly same as per original issue description.
Sorry again, Thanks, Ciao
> 6.1.0.beta4 and identified a rule pattern inducing memory leaks
> ---------------------------------------------------------------
>
> Key: DROOLS-516
> URL: https://issues.jboss.org/browse/DROOLS-516
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.Beta4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20140604.anotherleak.zip, 20140604.anotherleak_erratacorrige.zip, Java_VisualVM_2014-06-05_11-38-12.png, Java_VisualVM_2014-06-05_11-43-06.png
>
>
> Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue.
> Steps to replicate identification of issue:
> * IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly.
> * IF such rule is commented out, application do manage to keep alive.
> Same problem happens even on 6.1.0.beta3 - I did not test with previous versions.
> Thanks a lot in advance,
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-516?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-516:
----------------------------------
Attachment: 20140604.anotherleak.zip
Rules and Java code to replicate the identification of the issue
> 6.1.0.beta4 and identified a rule pattern inducing memory leaks
> ---------------------------------------------------------------
>
> Key: DROOLS-516
> URL: https://issues.jboss.org/browse/DROOLS-516
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.Beta4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20140604.anotherleak.zip, Java_VisualVM_2014-06-05_11-38-12.png, Java_VisualVM_2014-06-05_11-43-06.png
>
>
> Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue.
> Steps to replicate identification of issue:
> * IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly.
> * IF such rule is commented out, application do manage to keep alive.
> Same problem happens even on 6.1.0.beta3 - I did not test with previous versions.
> Thanks a lot in advance,
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-516?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-516:
----------------------------------
Attachment: Java_VisualVM_2014-06-05_11-38-12.png
Java_VisualVM_2014-06-05_11-43-06.png
Screenshots with Java VisualVM which shows that with mentioned rule included, memory leaks do happen.
If mentioned rule is commented out and therefore excluded, application memory use looks stable.
> 6.1.0.beta4 and identified a rule pattern inducing memory leaks
> ---------------------------------------------------------------
>
> Key: DROOLS-516
> URL: https://issues.jboss.org/browse/DROOLS-516
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.Beta4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20140604.anotherleak.zip, Java_VisualVM_2014-06-05_11-38-12.png, Java_VisualVM_2014-06-05_11-43-06.png
>
>
> Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue.
> Steps to replicate identification of issue:
> * IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly.
> * IF such rule is commented out, application do manage to keep alive.
> Same problem happens even on 6.1.0.beta3 - I did not test with previous versions.
> Thanks a lot in advance,
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-516:
-------------------------------------
Summary: 6.1.0.beta4 and identified a rule pattern inducing memory leaks
Key: DROOLS-516
URL: https://issues.jboss.org/browse/DROOLS-516
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta4, 6.1.0.Beta3
Reporter: Matteo Mortari
Assignee: Mark Proctor
Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue.
Steps to replicate identification of issue:
* IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly.
* IF such rule is commented out, application do manage to keep alive.
Same problem happens even on 6.1.0.beta3 - I did not test with previous versions.
Thanks a lot in advance,
Ciao
Matteo
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3451) disabling CBC mode ciphers
by Aleksandr Voloschuk (JIRA)
[ https://issues.jboss.org/browse/WFLY-3451?page=com.atlassian.jira.plugin.... ]
Aleksandr Voloschuk commented on WFLY-3451:
-------------------------------------------
how long will it take to resolve this issue?
> disabling CBC mode ciphers
> --------------------------
>
> Key: WFLY-3451
> URL: https://issues.jboss.org/browse/WFLY-3451
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Affects Versions: JBoss AS7 7.1.1.Final
> Reporter: Aleksandr Voloschuk
> Assignee: Darran Lofthouse
> Priority: Critical
>
> encountered such a problem:
> management of information security vulnerability found on a production environment, namely:
> SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability port 8443/tcp over SSL
> RC4-SHA ECDHE-RSA-DES-CBC3-SHA SSLv3
> they offer a solution:
> This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If
> upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability. Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability.
> as TLS upgrade we can not, it remains disabling CBC mode ciphers
> our platform is jboss-eap-6.1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3454) Syntax error when applying patch and exiting jboss-cli
by Arun Gupta (JIRA)
Arun Gupta created WFLY-3454:
--------------------------------
Summary: Syntax error when applying patch and exiting jboss-cli
Key: WFLY-3454
URL: https://issues.jboss.org/browse/WFLY-3454
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Arun Gupta
Assignee: Jason Greene
[disconnected /] patch apply
../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
{
"outcome" : "success",
"result" : {}
}
[disconnected /]
[disconnected /]
[disconnected /]
[disconnected /] exit
logging.configuration already set in JAVA_OPTS
./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3453) Caused by: java.lang.IllegalArgumentException: Cookie name "path" is a reserved token
by shaik masthan (JIRA)
shaik masthan created WFLY-3453:
-----------------------------------
Summary: Caused by: java.lang.IllegalArgumentException: Cookie name "path" is a reserved token
Key: WFLY-3453
URL: https://issues.jboss.org/browse/WFLY-3453
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.Final, 8.0.0.Final
Environment: windows 2003,flex with java(servlets)
Reporter: shaik masthan
Assignee: Stuart Douglas
Fix For: 8.1.0.Final, 8.0.0.Final
i am getting the below error when trying to access or open the UI page (developed using flex) .it was properly working in tomcat version. recently migrated from tomcat to wildfly 8.0.0 Final.
Caused by: java.lang.IllegalArgumentException: Cookie name "path" is a reserved token
at javax.servlet.http.Cookie.<init>(Cookie.java:192)
at io.undertow.servlet.spec.HttpServletRequestImpl.getCookies(HttpServletRequestImpl.java:145)
at com.ap.ca.mm.util.SessionUtils.getSessionManagerPrincipal(SessionUtils.java:128)
at com.ap.ca.mm.util.SessionUtils.getRmpPrincipalFromSessionManagerBean(SessionUtils.java:166)
at com.ap.ca.mm.util.SessionUtils.getRmpPrincipal(SessionUtils.java:96)
at com.ap.ca.mm.ro.dao.csdb.EntityDAO.<init>(EntityDAO.java:149)
... 42 more
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3452) Support vaulted properties for EE annotation properties
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-3452:
---------------------------------
Summary: Support vaulted properties for EE annotation properties
Key: WFLY-3452
URL: https://issues.jboss.org/browse/WFLY-3452
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: EE
Affects Versions: 8.1.0.Final
Reporter: Jeff Mesnil
Assignee: David Lloyd
Fix For: 9.0.0.Alpha1
EE annotation properties support property substitution (by system and env properties) using the PropertiesValueResolver.
However they do not support resolution of vaulted attributes that could be used for security sensitive values (user credentials).
We could leverage the PropertyReplacer returned by the EJBAnnotationPropertyReplacement to provide this enhancement.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month