[JBoss JIRA] (WFLY-5074) MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5074?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka edited comment on WFLY-5074 at 11/9/15 7:09 AM:
-----------------------------------------------------------------
Hi [~jmesnil],
my basic doubt was that being able to deploy MDB defined with {{REQUIRES_NEW}} is against spec and probably should not be permitted.
I haven't been reviewing the cause of the failure in my testcase deeper. Nevertheless it's possible to run a test in our testsuite in this way and I can see then this problem
# {{git clone git://git.app.eng.bos.redhat.com/jbossqe-eap-tests-transactions.git}}
# {{cd jbossqe-eap-tests-transactions}}
# {{export JBOSS_HOME=path/to/eap/wfly/distro}} (tested with EAP7.0.0.DR13/WFLY10.CR4 and the problem seems still exist)
# change annotation {{(a)TransactionAttribute(TransactionAttributeType.REQUIRED)}} to {{(a)TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)}} in file {{jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jms/mdb/JMSCrashMessageDrivenBean.java}}
# {{mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JMSProxyMdbMessagingServerCrashRecoveryTestCase#prepareHalt -Djbossts.noJTS -Dno.cleanup.at.teardown -Djboss.dist=$JBOSS_HOME}}
The failure is then shown as
{code}
JMSProxyMdbMessagingServerCrashRecoveryTestCase.prepareHalt:184->JMSMdbCrashRecoveryTestCase.checkAfterTestExecution:290 expectedCommit: got unexpected message in queue/MDBTriggerQueue (inqueue should be empty) [queue/crashRecoveryQueue:JMSCrashMessageDrivenBean] expected null, but was:<MDB:prepare_halt_proxy>
{code}
when it's expected to have the message being committed after the recovery manager starts to work but it seems that it's left in-doubt.
was (Author: ochaloup):
Hi [~jmesnil],
my basic doubt was that being able to deploy MDB defined with {{REQUIRES_NEW}} is against spec and probably should not be permitted.
I haven't been reviewing the cause of the failure in my testcase deeper. Nevertheless it's possible to run a test in our testsuite in this way and I can see then this problem
# {{git clone git://git.app.eng.bos.redhat.com/jbossqe-eap-tests-transactions.git}}
# {{cd jbossqe-eap-tests-transactions}}
# {{export JBOSS_HOME=path/to/eap/wfly/distro}} (tested with EAP7.0.0.DR13/WFLY10.CR4 and the problem seems still exist)
# change annotation {{(a)TransactionAttribute(TransactionAttributeType.REQUIRED)}} to {{(a)TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)}} in file {{jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jms/mdb/JMSCrashMessageDrivenBean.java}}
# {{mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JMSProxyMdbMessagingServerCrashRecoveryTestCase#prepareHalt -Djbossts.noJTS -Dno.cleanup.at.teardown -Djboss.dist=$JBOSS_HOME}}
> MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5074
> URL: https://issues.jboss.org/browse/WFLY-5074
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Reporter: Ondřej Chaloupka
> Assignee: Jeff Mesnil
> Attachments: JMSProxyMdbMessagingServerCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> Message driven bean should be used only with transaction attributes REQUIRED an NOT_SUPPORTED.
> The ejb specification says
> {quote}
> 13.6.3 Container-Managed Transaction Demarcation for Message-Driven Beans
> Only the NOT_SUPPORTED and REQUIRED transaction attributes may be used for message-driven bean message listener methods. The use of the other transaction attributes is not meaningful for message-driven bean message listener methods because there is no pre-existing client transaction context (REQUIRES_NEW, SUPPORTS) and no client to handle exceptions (MANDATORY, NEVER).
> {quote}
> EAP 7 permits usage of other transaction attributes as well. In my testcase strangely attribute REQUIRED behaves differently than REQUIRES_NEW.
> I do have mdb receiving message from remote message broker of ActiveMQ and closing connection during the commit (during prepare phase of XA 2PC). It happens to me that if used REQUIRED then all works fine. If used REQUIRES_NEW message seems to be read from the inbound queue but returned there instead of being left in in-doubt state (as expected when txn failed to prepare all participants).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5074) MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5074?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-5074:
-----------------------------------
Attachment: JMSProxyMdbMessagingServerCrashRecoveryTestCase_prepareHalt_jta_server.log
adding a log file from the failed testcases when MDB is configured with transactional attribute REQUIRES_NEW
> MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5074
> URL: https://issues.jboss.org/browse/WFLY-5074
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Reporter: Ondřej Chaloupka
> Assignee: Jeff Mesnil
> Attachments: JMSProxyMdbMessagingServerCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> Message driven bean should be used only with transaction attributes REQUIRED an NOT_SUPPORTED.
> The ejb specification says
> {quote}
> 13.6.3 Container-Managed Transaction Demarcation for Message-Driven Beans
> Only the NOT_SUPPORTED and REQUIRED transaction attributes may be used for message-driven bean message listener methods. The use of the other transaction attributes is not meaningful for message-driven bean message listener methods because there is no pre-existing client transaction context (REQUIRES_NEW, SUPPORTS) and no client to handle exceptions (MANDATORY, NEVER).
> {quote}
> EAP 7 permits usage of other transaction attributes as well. In my testcase strangely attribute REQUIRED behaves differently than REQUIRES_NEW.
> I do have mdb receiving message from remote message broker of ActiveMQ and closing connection during the commit (during prepare phase of XA 2PC). It happens to me that if used REQUIRED then all works fine. If used REQUIRES_NEW message seems to be read from the inbound queue but returned there instead of being left in in-doubt state (as expected when txn failed to prepare all participants).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5074) MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5074?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5074:
----------------------------------------
Hi [~jmesnil],
my basic doubt was that being able to deploy MDB defined with {{REQUIRES_NEW}} is against spec and probably should not be permitted.
I haven't been reviewing the cause of the failure in my testcase deeper. Nevertheless it's possible to run a test in our testsuite in this way and I can see then this problem
# {{git clone git://git.app.eng.bos.redhat.com/jbossqe-eap-tests-transactions.git}}
# {{cd jbossqe-eap-tests-transactions}}
# {{export JBOSS_HOME=path/to/eap/wfly/distro}} (tested with EAP7.0.0.DR13/WFLY10.CR4 and the problem seems still exist)
# change annotation {{(a)TransactionAttribute(TransactionAttributeType.REQUIRED)}} to {{(a)TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)}} in file {{jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jms/mdb/JMSCrashMessageDrivenBean.java}}
# {{mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JMSProxyMdbMessagingServerCrashRecoveryTestCase#prepareHalt -Djbossts.noJTS -Dno.cleanup.at.teardown -Djboss.dist=$JBOSS_HOME}}
> MDB should not permit transaction attributes other than REQUIRED and NOT_SUPPORTED
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5074
> URL: https://issues.jboss.org/browse/WFLY-5074
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Reporter: Ondřej Chaloupka
> Assignee: Jeff Mesnil
>
> Message driven bean should be used only with transaction attributes REQUIRED an NOT_SUPPORTED.
> The ejb specification says
> {quote}
> 13.6.3 Container-Managed Transaction Demarcation for Message-Driven Beans
> Only the NOT_SUPPORTED and REQUIRED transaction attributes may be used for message-driven bean message listener methods. The use of the other transaction attributes is not meaningful for message-driven bean message listener methods because there is no pre-existing client transaction context (REQUIRES_NEW, SUPPORTS) and no client to handle exceptions (MANDATORY, NEVER).
> {quote}
> EAP 7 permits usage of other transaction attributes as well. In my testcase strangely attribute REQUIRED behaves differently than REQUIRES_NEW.
> I do have mdb receiving message from remote message broker of ActiveMQ and closing connection during the commit (during prepare phase of XA 2PC). It happens to me that if used REQUIRED then all works fine. If used REQUIRES_NEW message seems to be read from the inbound queue but returned there instead of being left in in-doubt state (as expected when txn failed to prepare all participants).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5613) Fix transaction subsystem resource descriptions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5613?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-5613:
-----------------------------------
Assignee: Amos Feng (was: Tom Jenkinson)
> Fix transaction subsystem resource descriptions
> -----------------------------------------------
>
> Key: WFLY-5613
> URL: https://issues.jboss.org/browse/WFLY-5613
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Attachments: jts-tooltip-700.DR132.png
>
>
> I would like ask for changing text in transaction configuration helper tooltip (_Need Help?
> _). First there is an issue of not having an information that jts to be fully enabled is need to set subsystem of iiop orb as well (the same issue was for 6.4.0 https://bugzilla.redhat.com/show_bug.cgi?id=995439).
> Nevertheless I would like ask for a bit more general change of the text in the help webconsole tooltip
> Current text is
> {noformat}
> Default timeout: The default timeout.
> Enable tsm status: Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not..
> Journal store enable async io: Whether AsyncIO should be enabled for the journal store. Default is false. The server should be restarted for this setting to take effect.
> Jts: If true this enables the Java Transaction Service.
> Node identifier: Used to set the node identifier on the core environment.
> Statistics enabled: Whether statistics should be enabled.
> Use journal store: Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to jdbc based store.
> {noformat}
> {noformat}
> Process id uuid: Indicates whether the transaction manager should use a UUID based process id.
> Process id socket binding: The name of the socket binding configuration to use if the transaction manager should use a socket-based process id. Will be 'undefined' if 'process-id-uuid' is 'true'; otherwise must be set.
> Process id socket max ports: The maximum number of ports to search for an open port if the transaction manager should use a socket-based process id. If the port specified by the socket binding referenced in 'process-id-socket-binding' is occupied, the next higher port will be tried until an open port is found or the number of ports specified by this attribute have been tried. Will be 'undefined' if 'process-id-uuid' is 'true'.
> {noformat}
> {noformat}
> Socket binding: Used to reference the correct socket binding to use for the recovery environment.
> Status socket binding: Used to reference the correct socket binding to use for the transaction status manager.
> Recovery listener: Used to specify if the recovery system should listen on a network socket or not.
> {noformat}
> {noformat}
> Object store path: Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute.
> Object store relative to: References a global path configuration in the domain model, defaulting to the JBoss Application Server data directory (jboss.server.data.dir). The value of the "path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "path" attribute to be treated as an absolute path.
> {noformat}
> {noformat}
> Use jdbc store: Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to Horneq based store
> Jdbc action store drop table: Configure if jdbc action store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc action store table prefix: Optional prefix for table used to write transcation logs in configured jdbc action store. The server should be restarted for this setting to take effect.
> Jdbc communication store drop table: Configure if jdbc communication store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc communication store table prefix: Optional prefix for table used to write transcation logs in configured jdbc communication store. The server should be restarted for this setting to take effect.
> Jdbc state store drop table: Configure if jdbc state store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc state store table prefix: Optional prefix for table used to write transcation logs in configured jdbc state store. The server should be restarted for this setting to take effect.
> Jdbc store datasource: Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. The server should be restarted for this setting to take effect.
> {noformat}
> I would propose the following changes in the tooltip text
> *Attributes*
> * Default timeout
> ** The default timeout for a transaction managed by the transaction manager.
> * Enable tsm status
> ** Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not.
> * Journal store enable async io
> ** Whether AsyncIO should be enabled for the journal store. Default is false. For this settings being active journal natives libraries needs to be available. The server should be restarted for this setting to take effect.
> * Jts
> ** If true this enables the Java Transaction Service. Use of the JTS needs configuration in IIOP OpenJDK where Transactions parameter needs to be set to full. The server should be restarted for this setting to take effect.
> * Node identifier
> ** Used to set the node identifier on the core environment. Each server should have this identifier unique. It's an identifier which differentiates XA transactions as created by this node. The server should be restarted for this setting to take effect.
> * Statistics enabled
> ** Whether transaction statistics should be enabled. The transaction statistics could be seen in section Runtime > Monitor > Subsystems > Transactions. The server should be reloaded for this setting to take effect.
> * Use journal store
> ** Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store. The server should be restarted for this setting to take effect.
> *Process ID* + *Recovery*
> Add information that for settings these attributes taking effect the server needs to be reloaded.
> *Path*
> * Object store path
> ** Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute. This settings is valid when default or journal store is used. It's not used when jdbc journal store is used. The server should be reloaded for this setting to take effect.
> * Object store relative to
> ** References a global path configuration in the domain model, defaulting to the Application Server data directory (jboss.server.data.dir). The value of the "Object store path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "Object store path" attribute to be treated as an absolute path. The server should be reloaded for this setting to take effect.
> *JDBC*
> * Use jdbc store
> ** Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store. The server should be restarted for this setting to take effect.
> * Jdbc store datasource
> ** Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. For this would work the non-XA datasource has to be marked as jta="false". The server should be restarted for this setting to take effect.
> ...the rest of the information is ok from my point of view
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1116) Review initial user creation process.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1116:
----------------------------------------
Summary: Review initial user creation process.
Key: WFCORE-1116
URL: https://issues.jboss.org/browse/WFCORE-1116
Project: WildFly Core
Issue Type: Enhancement
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha1
We started off with a very simple add user utility where the purpose was just to get the first management user added so users could remotely administer the server, this tool has grown and grown so now it covers management users and application users. we also have additional questions in relation to groups that are not obvious to users what they need to add.
This task is to look into providing something that in it's simplest form just focusses on the first management user.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1115) Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1115?page=com.atlassian.jira.plugi... ]
Petr Kremensky reassigned WFCORE-1115:
--------------------------------------
Assignee: Brian Stansberry (was: Petr Kremensky)
> Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1115
> URL: https://issues.jboss.org/browse/WFCORE-1115
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha1
> Reporter: Petr Kremensky
> Assignee: Brian Stansberry
> Attachments: TEST-org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase.xml, TEST-org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase.xml
>
>
> org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase and org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase from wildfly-core testsuite domain module starts to intermittently fail since 7.0.0.DR13 (2.0.0.CR8).
> Tests fails only once I run the whole Domain Mode Integration Tests module, running only these two tests in isolation never fails.
> [Reproducer job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-core-Comp...] which starts the tests in testsuite/domain module:
> \- *2.0.0.CR6* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR7* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR8* - no more HcExtensionAndSubsystemManagementTestCase failures, CompositeOperationTestCase and CoreResourceManagementTestCase starts failing
> \- *3.0.0.Alpha1-SNAPSHOT* - CompositeOperationTestCase and CoreResourceManagementTestCase intermittent fails
> Attaching surefire reports.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1115) Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1115?page=com.atlassian.jira.plugi... ]
Petr Kremensky moved JBEAP-1794 to WFCORE-1115:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1115 (was: JBEAP-1794)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Test Suite
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 3.0.0.Alpha1
(was: 7.0.0.DR13 (Alpha))
> Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1115
> URL: https://issues.jboss.org/browse/WFCORE-1115
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha1
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Attachments: TEST-org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase.xml, TEST-org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase.xml
>
>
> org.jboss.as.test.integration.domain.suites.CompositeOperationTestCase and org.jboss.as.test.integration.domain.suites.CoreResourceManagementTestCase from wildfly-core testsuite domain module starts to intermittently fail since 7.0.0.DR13 (2.0.0.CR8).
> Tests fails only once I run the whole Domain Mode Integration Tests module, running only these two tests in isolation never fails.
> [Reproducer job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-core-Comp...] which starts the tests in testsuite/domain module:
> \- *2.0.0.CR6* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR7* - intermittent failures of HcExtensionAndSubsystemManagementTestCase JBEAP-1598
> \- *2.0.0.CR8* - no more HcExtensionAndSubsystemManagementTestCase failures, CompositeOperationTestCase and CoreResourceManagementTestCase starts failing
> \- *3.0.0.Alpha1-SNAPSHOT* - CompositeOperationTestCase and CoreResourceManagementTestCase intermittent fails
> Attaching surefire reports.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5648) Access log message fails to be written to recreated access log on Windows
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5648?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5648:
-----------------------------------
Affects Version/s: 10.0.0.CR4
> Access log message fails to be written to recreated access log on Windows
> -------------------------------------------------------------------------
>
> Key: WFLY-5648
> URL: https://issues.jboss.org/browse/WFLY-5648
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
>
> Undertow fails to write to access-log when the access-log configuration was removed including the access-log file and then the configuration was recreated with [1]. Probably there remains some lock to old file preventing creation of the new one.
> Steps to reproduce:
> 1) deploy some simple web application
> 2) define access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}}
> 3) reload server
> 4) access the web application
> 5) see that the access was logged to access-log
> 6) remove the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:remove()}}
> 7) reload the server
> 8) remove the access-log file
> 9) define again the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}}
> 10) access again the web application
> 11) check both server logs and access-log
> [1]
> {noformat}
> 05:49:51,448 ERROR [io.undertow] (default task-2) UT005016: Error writing access log: java.nio.file.AccessDeniedException: W:\workspace\eap-7x-undertow-integration-tests\d07ae7a0\manu-eap-1.1.13\out\UnzipEap_1\workspace\jboss-eap-7.0\standalone\log\access_log.log
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
> at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
> at java.nio.file.Files.newOutputStream(Files.java:216)
> at java.nio.file.Files.newBufferedWriter(Files.java:2860)
> at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.writeMessage(DefaultAccessLogReceiver.java:224)
> at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.run(DefaultAccessLogReceiver.java:180)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months