January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3557) Upgrade Wildfly Common to 1.3.0.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3557?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3557: ------------------------------------- Fix Version/s: 4.0.0.Alpha8 (was: 4.0.0.Alpha7) > Upgrade Wildfly Common to 1.3.0.Final > ------------------------------------- > > Key: WFCORE-3557 > URL: https://issues.jboss.org/browse/WFCORE-3557 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Richard Opalka > Assignee: David Lloyd > Fix For: 4.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-350) Domain reflects jboss.server.xy properties

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin... ] Brian Stansberry edited comment on WFCORE-350 at 1/26/18 8:04 PM: ------------------------------------------------------------------ The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its servers means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log. You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions. was (Author: brian.stansberry): The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its server means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log. You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions. > Domain reflects jboss.server.xy properties > ------------------------------------------ > > Key: WFCORE-350 > URL: https://issues.jboss.org/browse/WFCORE-350 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property. > The same server.log file is used for both server-one and server-two. Only file boot.log is created in domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two. > I think jboss.server.xy properties shouldn't be reflected in domain instances. > Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone. > Reproducer of my steps: > {code} > rm -rf domain/servers > bin/domain.sh -Djboss.server.log.dir=/tmp/ > ls -aR domain/servers/server-one/log > ls -aR domain/servers/server-two/log > ls -l /tmp/server* > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-350) Domain reflects jboss.server.xy properties

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-350: ----------------------------------------- The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its server means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log. You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions. > Domain reflects jboss.server.xy properties > ------------------------------------------ > > Key: WFCORE-350 > URL: https://issues.jboss.org/browse/WFCORE-350 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property. > The same server.log file is used for both server-one and server-two. Only file boot.log is created in domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two. > I think jboss.server.xy properties shouldn't be reflected in domain instances. > Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone. > Reproducer of my steps: > {code} > rm -rf domain/servers > bin/domain.sh -Djboss.server.log.dir=/tmp/ > ls -aR domain/servers/server-one/log > ls -aR domain/servers/server-two/log > ls -l /tmp/server* > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-350) Domain reflects jboss.server.xy properties

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-350: -------------------------------------- Was the intention to not allow these {{jboss.server.*}} properties not to be set in domain mode? For example is passing {{-Djboss.server.log.dir=/var/logs/wildfly}} not allowed to be set in the {{JAVA_OPTS}} or {{HOST_CONTROLLER_JAVA_OPTS}}? > Domain reflects jboss.server.xy properties > ------------------------------------------ > > Key: WFCORE-350 > URL: https://issues.jboss.org/browse/WFCORE-350 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property. > The same server.log file is used for both server-one and server-two. Only file boot.log is created in domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two. > I think jboss.server.xy properties shouldn't be reflected in domain instances. > Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone. > Reproducer of my steps: > {code} > rm -rf domain/servers > bin/domain.sh -Djboss.server.log.dir=/tmp/ > ls -aR domain/servers/server-one/log > ls -aR domain/servers/server-two/log > ls -l /tmp/server* > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3561) testAppendCustomFileAbsoluteDirCompletition failures on windows

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3561?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-3561: -------------------------------------------- Assignee: Katerina Novotna (was: Jean-Francois Denise) > testAppendCustomFileAbsoluteDirCompletition failures on windows > --------------------------------------------------------------- > > Key: WFCORE-3561 > URL: https://issues.jboss.org/browse/WFCORE-3561 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Test Suite > Reporter: Jean-Francois Denise > Assignee: Katerina Novotna > > The logic to test completion candidates is failing on Windows, should be reviewed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3561) testAppendCustomFileAbsoluteDirCompletition failures on windows

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-3561: -------------------------------------------- Summary: testAppendCustomFileAbsoluteDirCompletition failures on windows Key: WFCORE-3561 URL: https://issues.jboss.org/browse/WFCORE-3561 Project: WildFly Core Issue Type: Bug Components: CLI, Test Suite Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise The logic to test completion candidates is failing on Windows, should be reviewed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9739) JPA / Hibernate: There is already an object named 'x' in the database

by Eric SantAnna (JIRA)

[ https://issues.jboss.org/browse/WFLY-9739?page=com.atlassian.jira.plugin.... ] Eric SantAnna commented on WFLY-9739: ------------------------------------- The exact case of the created table is 'Animal'. Thank you for point me in the right direction, I'm going report this with Hibernate. > JPA / Hibernate: There is already an object named 'x' in the database > --------------------------------------------------------------------- > > Key: WFLY-9739 > URL: https://issues.jboss.org/browse/WFLY-9739 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Environment: Windows 10 64 bits / Windows Server 2012 R2 64 bits > Java version: 1.8.0_151 > SQL Server 2014 > Reporter: Eric SantAnna > Assignee: Scott Marlow > Attachments: sqljdbc4.jar, wildfly11-migration.zip > > > I'm getting an Exception as a warning in the server.log when a database object already exists an my persistence.xml has the property "hibernate.hbm2ddl.auto" set to "update". > This doesn't happen in my tests with 10.1.0.Final. > Appearently, despite these Exceptions, all my applications are running ok. > I saw this behaviour while I was migrating my application from JBoss 7.1.1.Final to Wildfly. I'm deciding between Wildfly 10.1 and 11. > This behaviour isn't good cause, I'm flooding the logs and it doesn't seem reliable for my manager. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3560) grep command doesn't close file

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3560?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3560: ----------------------------------------- Component/s: CLI > grep command doesn't close file > ------------------------------- > > Key: WFCORE-3560 > URL: https://issues.jboss.org/browse/WFCORE-3560 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > > This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile > Outside tests, the file will be locked during the CLI lifetime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3560) grep command doesn't close file

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3560?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-3560: -------------------------------------------- Assignee: Jean-Francois Denise > grep command doesn't close file > ------------------------------- > > Key: WFCORE-3560 > URL: https://issues.jboss.org/browse/WFCORE-3560 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile > Outside tests, the file will be locked during the CLI lifetime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3560) grep command doesn't close file

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-3560: -------------------------------------------- Summary: grep command doesn't close file Key: WFCORE-3560 URL: https://issues.jboss.org/browse/WFCORE-3560 Project: WildFly Core Issue Type: Bug Reporter: Jean-Francois Denise This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile Outside tests, the file will be locked during the CLI lifetime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018