June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4530) resolve property in deployment enabled attribute value

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4530?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-4530: ---------------------------------------- Assignee: (was: Brian Stansberry) I have my doubts about this, as expressions for this attribute were specifically disallowed in 2013, with the comment "// allowing expressions here complicates domain mode and deployment scanners". That was my decision and comment, but I don't recall the details behind it any more. > resolve property in deployment enabled attribute value > ------------------------------------------------------ > > Key: WFCORE-4530 > URL: https://issues.jboss.org/browse/WFCORE-4530 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: David Klika > Priority: Major > > I have defined a deployment (standalone mode) with enabled attribute value referencing to a property like this: enabled="${app1.enabled}". This case is not supported at least by the configuration validator: > OPVDX001: Validation error in standalone.xml ----------------------------------- > | The primary underlying error message was: > | > ParseError at [row,col]:[377,5] > | > Message: "WFLYCTL0097: Wrong type for 'enabled'. Expected [BOOLEAN] > | > but was STRING. Couldn't convert \"${app1.enabled}\" to > | > [BOOLEAN]" > The same problem is in domain mode with enabled property on server group deployment definition. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12196) resolve property in deployment enabled attribute value

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12196?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12196: ------------------------------------ Issue Type: Enhancement (was: Feature Request) > resolve property in deployment enabled attribute value > ------------------------------------------------------ > > Key: WFLY-12196 > URL: https://issues.jboss.org/browse/WFLY-12196 > Project: WildFly > Issue Type: Enhancement > Components: Server > Reporter: David Klika > Assignee: Brian Stansberry > Priority: Major > > I have defined a deployment (standalone mode) with enabled attribute value referencing to a property like this: enabled="${app1.enabled}". This case is not supported at least by the configuration validator: > OPVDX001: Validation error in standalone.xml ----------------------------------- > | The primary underlying error message was: > | > ParseError at [row,col]:[377,5] > | > Message: "WFLYCTL0097: Wrong type for 'enabled'. Expected [BOOLEAN] > | > but was STRING. Couldn't convert \"${app1.enabled}\" to > | > [BOOLEAN]" > The same problem is in domain mode with enabled property on server group deployment definition. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12196) resolve property in deployment enabled attribute value

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12196?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12196: ------------------------------------ Component/s: Management (was: Server) > resolve property in deployment enabled attribute value > ------------------------------------------------------ > > Key: WFLY-12196 > URL: https://issues.jboss.org/browse/WFLY-12196 > Project: WildFly > Issue Type: Enhancement > Components: Management > Reporter: David Klika > Assignee: Brian Stansberry > Priority: Major > > I have defined a deployment (standalone mode) with enabled attribute value referencing to a property like this: enabled="${app1.enabled}". This case is not supported at least by the configuration validator: > OPVDX001: Validation error in standalone.xml ----------------------------------- > | The primary underlying error message was: > | > ParseError at [row,col]:[377,5] > | > Message: "WFLYCTL0097: Wrong type for 'enabled'. Expected [BOOLEAN] > | > but was STRING. Couldn't convert \"${app1.enabled}\" to > | > [BOOLEAN]" > The same problem is in domain mode with enabled property on server group deployment definition. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4530) resolve property in deployment enabled attribute value

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4530?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-12196 to WFCORE-4530: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4530 (was: WFLY-12196) Component/s: Management (was: Management) Affects Version/s: (was: 17.0.0.Final) > resolve property in deployment enabled attribute value > ------------------------------------------------------ > > Key: WFCORE-4530 > URL: https://issues.jboss.org/browse/WFCORE-4530 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: David Klika > Assignee: Brian Stansberry > Priority: Major > > I have defined a deployment (standalone mode) with enabled attribute value referencing to a property like this: enabled="${app1.enabled}". This case is not supported at least by the configuration validator: > OPVDX001: Validation error in standalone.xml ----------------------------------- > | The primary underlying error message was: > | > ParseError at [row,col]:[377,5] > | > Message: "WFLYCTL0097: Wrong type for 'enabled'. Expected [BOOLEAN] > | > but was STRING. Couldn't convert \"${app1.enabled}\" to > | > [BOOLEAN]" > The same problem is in domain mode with enabled property on server group deployment definition. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12204) Update wildfly-transaction-client to 1.1.4.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12204?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12204: ----------------------------------------- [~tomekadamski] Please add "incorporates" links to any JIRAs this resolves. > Update wildfly-transaction-client to 1.1.4.Final > ------------------------------------------------ > > Key: WFLY-12204 > URL: https://issues.jboss.org/browse/WFLY-12204 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB, Transactions > Affects Versions: 17.0.0.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Major > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11865) Wildfly console logging stops with statement, "2 Spring WebApplicationInitializers detected on classpath"

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11865?page=com.atlassian.jira.plugin... ] Radoslav Husar reassigned WFLY-11865: ------------------------------------- Assignee: James Perkins > Wildfly console logging stops with statement, "2 Spring WebApplicationInitializers detected on classpath" > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11865 > URL: https://issues.jboss.org/browse/WFLY-11865 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Shreyas Holla p > Assignee: James Perkins > Priority: Major > Fix For: 10.0.0.Final > > > We are deploying CAS-5.3.8.WAR on on WildFly 10.0.0.Final, the WAR gets deployed successfully and the application works fine but wildfly server console log stops, > This happens when we add "<add-logging-api-dependencies value="false"/>". > WFLYSRV0027: Starting deployment of "cas.war" (runtime-name: "cas.war") > WFLYSRV0027: Starting deployment of "BankFusion.ear" (runtime-name: "BankFusion.ear") > ISPN000128: Infinispan version: Infinispan 'Mahou' 8.1.0.Final > ISPN000128: Infinispan version: Infinispan 'Mahou' 8.1.0.Final > ISPN000128: Infinispan version: Infinispan 'Mahou' 8.1.0.Final > JBWS022052: Starting JBossWS 5.1.3.Final (Apache CXF 3.1.4) > WFLYSRV0059: Class Path entry xml-apis.jar in /E:/FusionBanking/FBP531.5/WildFly/wildfly-10.0.0.Final/bin/content/cas.war/WEB-INF/lib/serializer-2.7.2.jar does not point to a valid jar for a Class-Path reference. > WFLYSRV0059: Class Path entry xercesImpl.jar in /E:/FusionBanking/FBP531.5/WildFly/wildfly-10.0.0.Final/bin/content/cas.war/WEB-INF/lib/xalan-2.7.2.jar does not point to a valid jar for a Class-Path reference. > WFLYSRV0059: Class Path entry xml-apis.jar in /E:/FusionBanking/FBP531.5/WildFly/wildfly-10.0.0.Final/bin/content/cas.war/WEB-INF/lib/xalan-2.7.2.jar does not point to a valid jar for a Class-Path reference. > WFLYSRV0059: Class Path entry serializer.jar in /E:/FusionBanking/FBP531.5/WildFly/wildfly-10.0.0.Final/bin/content/cas.war/WEB-INF/lib/xalan-2.7.2.jar does not point to a valid jar for a Class-Path reference. > WFLYEE0007: Not installing optional component org.springframework.http.server.ServletServerHttpAsyncRequestControl due to an exception (enable DEBUG log level to see the cause) > WFLYEE0007: Not installing optional component org.springframework.web.context.request.async.StandardServletAsyncWebRequest due to an exception (enable DEBUG log level to see the cause) > WFLYWELD0013: Deployment deployment "cas.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 2 Spring WebApplicationInitializers detected on classpath -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12205) Update jboss-ejb-client to 4.0.19

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12205: ------------------------------------- Summary: Update jboss-ejb-client to 4.0.19 Key: WFLY-12205 URL: https://issues.jboss.org/browse/WFLY-12205 Project: WildFly Issue Type: Component Upgrade Components: EJB Affects Versions: 17.0.0.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski Fix For: 18.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12204) Update wildfly-transaction-client to 1.1.4.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12204: ------------------------------------- Summary: Update wildfly-transaction-client to 1.1.4.Final Key: WFLY-12204 URL: https://issues.jboss.org/browse/WFLY-12204 Project: WildFly Issue Type: Component Upgrade Components: EJB, Transactions Affects Versions: 17.0.0.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski Fix For: 18.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-164) Hibernate Criteria SQL select with order by causes in DB2 big performance impact

by Petr Hariprasad Hajič (Jira)

[ https://issues.jboss.org/browse/HIBERNATE-164?page=com.atlassian.jira.plu... ] Petr Hariprasad Hajič updated HIBERNATE-164: -------------------------------------------- Description: Using detached criteria with ordering clause produces inefficient SQL (simplified). {code:java} DetachedCriteria crit = DetachedCriteria.forClass(Log.class); ... crit.addOrder(org.hibernate.criterion.Order.asc("dateTime"); {code} Catched hibernate QUERY in console (simplified and replaced ? with values): {noformat} select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75; {noformat} Cost of this SQL is about 2*10^6 - very pure (index was used). Slightly improved SQL gives good performance: {noformat} select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75; {noformat} Cost is about 75 (i.e. nearly milion times better), of course index was used also! But I dont know how to modify Criteria to exclude second wrong order by. Is there solution or workaround? was: Using detached criteria with ordering clause produces inefficient SQL (simplified). ??DetachedCriteria crit = DetachedCriteria.forClass(Log.class); ... crit.addOrder(org.hibernate.criterion.Order.asc("dateTime");?? Catched hibernate QUERY in console (simplified and replaced ? with values): ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75; ?? Cost of this SQL is about 2*10^6 - very pure (index was used). Slightly improved SQL gives good performance: ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75;?? Cost is about 75 (i.e. nearly milion times better), of course index was used also! But I dont know how to modify Criteria to exclude second wrong order by. Is there solution or workaround? > Hibernate Criteria SQL select with order by causes in DB2 big performance impact > -------------------------------------------------------------------------------- > > Key: HIBERNATE-164 > URL: https://issues.jboss.org/browse/HIBERNATE-164 > Project: Hibernate Integration > Issue Type: Bug > Environment: Oracle Java 7, Hibernate 3.6.10.Final, Tomcat 7.0, IBM DB2 9, 10 (not tested on the last version). > Reporter: Petr Hariprasad Hajič > Assignee: Steve Ebersole > Priority: Major > Labels: support > > Using detached criteria with ordering clause produces inefficient SQL (simplified). > {code:java} > DetachedCriteria crit = DetachedCriteria.forClass(Log.class); > ... > crit.addOrder(org.hibernate.criterion.Order.asc("dateTime"); > {code} > Catched hibernate QUERY in console (simplified and replaced ? with values): > {noformat} > select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* > from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75; > {noformat} > Cost of this SQL is about 2*10^6 - very pure (index was used). > Slightly improved SQL gives good performance: > {noformat} > select temp.* from ( select row_number() over(order by a.dateTime asc) as > rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75; > {noformat} > Cost is about 75 (i.e. nearly milion times better), of course index was used also! > But I dont know how to modify Criteria to exclude second wrong order by. > Is there solution or workaround? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-164) Hibernate Criteria SQL select with order by causes in DB2 big performance impact

by Petr Hariprasad Hajič (Jira)

[ https://issues.jboss.org/browse/HIBERNATE-164?page=com.atlassian.jira.plu... ] Petr Hariprasad Hajič updated HIBERNATE-164: -------------------------------------------- Description: Using detached criteria with ordering clause produces inefficient SQL (simplified). ??DetachedCriteria crit = DetachedCriteria.forClass(Log.class); ... crit.addOrder(org.hibernate.criterion.Order.asc("dateTime");?? Catched hibernate QUERY in console (simplified and replaced ? with values): ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75; ?? Cost of this SQL is about 2*10^6 - very pure (index was used). Slightly improved SQL gives good performance: ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75;?? Cost is about 75 (i.e. nearly milion times better), of course index was used also! But I dont know how to modify Criteria to exclude second wrong order by. Is there solution or workaround? was: Using detached criteria with ordering clause produces inefficient SQL (simplified). ?? DetachedCriteria crit = DetachedCriteria.forClass(Log.class); ... crit.addOrder(org.hibernate.criterion.Order.asc("dateTime"); ?? Catched hibernate QUERY in console (simplified and replaced ? with values): ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75;?? Cost of this SQL is about 2*10^6 - very pure (index was used). Slightly improved SQL gives good performance: ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75;?? Cost is about 75 (i.e. nearly milion times better), of course index was used also! But I don´t know how to modify criteria to omit But I dont know how to modify Criteria to exclude second wrong order by. Is there solution or workaround? > Hibernate Criteria SQL select with order by causes in DB2 big performance impact > -------------------------------------------------------------------------------- > > Key: HIBERNATE-164 > URL: https://issues.jboss.org/browse/HIBERNATE-164 > Project: Hibernate Integration > Issue Type: Bug > Environment: Oracle Java 7, Hibernate 3.6.10.Final, Tomcat 7.0, IBM DB2 9, 10 (not tested on the last version). > Reporter: Petr Hariprasad Hajič > Assignee: Steve Ebersole > Priority: Major > Labels: support > > Using detached criteria with ordering clause produces inefficient SQL (simplified). > ??DetachedCriteria crit = DetachedCriteria.forClass(Log.class); > ... > crit.addOrder(org.hibernate.criterion.Order.asc("dateTime");?? > Catched hibernate QUERY in console (simplified and replaced ? with values): > ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* > from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75; > ?? > Cost of this SQL is about 2*10^6 - very pure (index was used). > Slightly improved SQL gives good performance: > ??select temp.* from ( select row_number() over(order by a.dateTime asc) as > rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75;?? > Cost is about 75 (i.e. nearly milion times better), of course index was used also! > But I dont know how to modify Criteria to exclude second wrong order by. > Is there solution or workaround? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 June 2019