[JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null
by Burcu (Yapıcı) Kalkan (JIRA)
[ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugi... ]
Burcu (Yapıcı) Kalkan commented on JASSIST-141:
-----------------------------------------------
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<version> 3.6</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>1.7.4</version>
<exclusions>
<exclusion>
<groupId>org.junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
<exclusion>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-mockito</artifactId>
</exclusion>
<exclusion>
<groupId>org.powermock</groupId>
<artifactId>powermock-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.powermock</groupId>
<artifactId>powermock-reflect</artifactId>
</exclusion>
</exclusions>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.23.1-GA</version>
</dependency>
<dependency>
I use last version of powermock and javassist but it gives same exception?
> Failed to transform class with name com.some.class. Reason: null
> ----------------------------------------------------------------
>
> Key: JASSIST-141
> URL: https://issues.jboss.org/browse/JASSIST-141
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.14.0.GA
> Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA
> Reporter: Andreas Don'tAskDon'tTell
> Assignee: Shigeru Chiba
> Labels: mapmaker, powermock
>
> Hi,
> i get this error while using the @PrepareForTest() annotation from the powermock framework.
> This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug.
> the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes?
> Thankyou for now :D
> Yours,
> Andreas
> and here the stacktrace:
> java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207)
> at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145)
> at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95)
> at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107)
> at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31)
> at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370)
> at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351)
> at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653)
> at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460)
> at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
> at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
> at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
> at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
> at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
> at java.lang.Class.getAnnotations(Class.java:3050)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.NullPointerException
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> =====================================================================================================================
> 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> =====================================================================================================================
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398)
> at javassist.expr.ExprEditor.doit(ExprEditor.java:112)
> at javassist.CtClassType.instrument(CtClassType.java:1384)
> at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77)
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
> ... 28 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (JGRP-2106) Prepare for JDK 11
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/JGRP-2106?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on JGRP-2106:
---------------------------------------
Hi Bela!
technically you don't _need_ module info as you don't strictly need to make it a module. It would be helpful to some, but I'd suggest first making sure it "just works" on JDK11 as a normal classpath library.
I guess in your case it's trivial to make it a module as well, but it's likely not so trivial to define exactly which packages you're going to make non-accessible to users. For this reason on other projects we decided to wait to make actual modules; although we started to clarify which module names we're going to use.
HTH
> Prepare for JDK 11
> ------------------
>
> Key: JGRP-2106
> URL: https://issues.jboss.org/browse/JGRP-2106
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Investigate the changes needed to run with JDK 9. Probably module.info classes are all that's needed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFLY-10339:
------------------------------------------
We could solve it the #2 way by setting a static capability reference on the jgroups-cluster attribute and keep the dynamic one on the jgroups-channel.
This seems to work with the Galleon change and our current test suite
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4139:
-------------------------------------
Comment: was deleted
(was: I understand now. The ProcessController has no shutdown hook, so calling Process.destroy on it is going to succeed very quickly. The HC process then detects the close of stdin and shuts down. So that is async to stopping the PC.
So maybe this is an Enhancement to make that better, or maybe just a Won't Fix because the chance of doing harm with a fix outweighs any benefit.)
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4139:
-------------------------------------
Priority: Major (was: Minor)
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4135) Add a new property to disable backups of configuration XML files. Also avoid writing to standalone_xml_history when --read-only-server-config=<config> is set.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4135?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4135:
------------------------------------------
The server successfully executing a management op and responding with reload-required, and then the user does the reload but the change doesn't end up in the runtime -- that would be a bug. If the server knows it won't be able to effect the change if reload is invoked, then it shouldn't report the initial op as a success.
This could be done by having the OperationContext reject calls to reloadRequired() and restartRequired(), instead marking itself as rollback only and throwing an OperationFailedRuntimeException. The OperationContext would need to know the process is configured this way though.
Thanks for the info about the use cases.
> Add a new property to disable backups of configuration XML files. Also avoid writing to standalone_xml_history when --read-only-server-config=<config> is set.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4135
> URL: https://issues.jboss.org/browse/WFCORE-4135
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Rafael Ruiz
>
> We need something like
> --disable-configuration-history
> to use when running in containers to avoid write to any directory ('standalone_xml_history').
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-10912) CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-10912?page=com.atlassian.jira.plugin... ]
Masafumi Miura reassigned WFLY-10912:
-------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
> -----------------------------------------------------------------------------------
>
> Key: WFLY-10912
> URL: https://issues.jboss.org/browse/WFLY-10912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Final, 14.0.0.Beta2
> Reporter: Masafumi Miura
> Assignee: Paul Ferraro
>
> This issue is very similar to WFLY-10262/JBEAP-14641 but the condition causing the problem is a bit different.
> The issue happens when the client sends JSESSIONID Cookie in the request to the web application does NOT use HttpSession. JSESSIONID Set-Cookie response header should not be sent in this scenario, but WildFly/EAP 7 returns the response with JSESSIONID reusing the requested session id which does not exist in the session manager.
> The fix for WFLY-10262 / JBEAP-14641 added AttachmentKey SESSION_ID_SET to avoid invoking CodecSessionConfig#setSessionId() more than once. However, the fix does not help for this issue because CodecSessionConfig#setSessionId() is not invoked (= SESSION_ID_SET is null) before the problematic CodecSessionConfig#findSessionId() processing in this scenario.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)
by Cristiano Nicolai (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Cristiano Nicolai commented on DROOLS-3000:
-------------------------------------------
[~uxdlc] [~karreiro] there is a component on uberfire already, see: https://github.com/kiegroup/appformer/blob/master/uberfire-workbench/uber...
> Enhance data type restrictions UX (decision tables & DT dialog)
> ---------------------------------------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, date-time.png, date.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4140) Incorrect resource passed into ExtensionRegistry.remove by ExtensionAddHandler rollback handling
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-4140:
----------------------------------------
Summary: Incorrect resource passed into ExtensionRegistry.remove by ExtensionAddHandler rollback handling
Key: WFCORE-4140
URL: https://issues.jboss.org/browse/WFCORE-4140
Project: WildFly Core
Issue Type: Bug
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
ExtensionAddHandler rollback handling passes the extension resource to ExtensionRegistry.remove when the API wants the root resource. This results in this failure:
{code}
2018-09-27 17:21:19,300 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0190: Step handler org.jboss.as.controller.extension.ExtensionAddHandler@4bdb1e35 for operation add at address [("extension" => "org.jboss.as.test.extension")] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
at org.jboss.as.controller.extension.ExtensionRegistry.hasSubsystemsRegistered(ExtensionRegistry.java:372)
at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:342)
at org.jboss.as.controller.extension.ExtensionAddHandler$1.handleRollback(ExtensionAddHandler.java:97)
at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1561)
at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1533)
at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1515)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472)
at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1455)
at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319)
at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:756)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
{code}
Also, ExtensionResource should not return null from getChildren. Fixing that would eliminate the NPE but the rollback handling wouldn't work properly with the wrong object being passed in.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (LOGMGR-203) LogManager stops any logging output after changing "encoding" attribute to file-handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-203?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-203:
---------------------------------
Fix Version/s: 2.0.11.Final
> LogManager stops any logging output after changing "encoding" attribute to file-handler
> ---------------------------------------------------------------------------------------
>
> Key: LOGMGR-203
> URL: https://issues.jboss.org/browse/LOGMGR-203
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Reporter: Masafumi Miura
> Assignee: David Lloyd
> Fix For: 2.0.11.Final, 2.1.5.Final
>
>
> When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
> Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
> Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.io.IOException: Stream Closed
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
> at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
> at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months