[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFLY-11089:
-------------------------------------
Description:
When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part).
Also I noted that the upload of the file was happening through an XHR and not in the initial request.
This happens in domain and standalone mode.
was:
When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part).
Also I noted that the upload of the file was happening through an XHR and not in the initial request.
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part).
> Also I noted that the upload of the file was happening through an XHR and not in the initial request.
> This happens in domain and standalone mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (DROOLS-3050) Serial Version UUID on Declared Types
by Stylianos Koussouris (JIRA)
Stylianos Koussouris created DROOLS-3050:
--------------------------------------------
Summary: Serial Version UUID on Declared Types
Key: DROOLS-3050
URL: https://issues.jboss.org/browse/DROOLS-3050
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 7.12.0.Final
Reporter: Stylianos Koussouris
Assignee: Mario Fusco
We wish to update DeclaredTypes whilst session is in use but the generated serial version ID changes when the DeclaredType pojo is recompiled resulting InvalidClassExceptions. We therefore suggest the usage of an annotation @SerialVersionUUID to set in a constant manner the UUID
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work in domain mode
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFLY-11089:
----------------------------------------
Summary: Uploading content from HAL in SSL doesn't work in domain mode
Key: WFLY-11089
URL: https://issues.jboss.org/browse/WFLY-11089
Project: WildFly
Issue Type: Bug
Components: Web (Undertow), Web Console
Affects Versions: 14.0.0.Final
Reporter: ehsavoie Hugonnet
Assignee: Stuart Douglas
When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part).
Also I noted that the upload of the file was happening through an XHR and not in the initial request.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[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)
7 years
[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)
7 years
[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)
7 years
[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)
7 years
[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)
7 years
[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)
7 years
[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)
7 years