[JBoss JIRA] (WFLY-3725) Unable to deploy dynamic, programmatic JSR-356 Endpoints
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3725?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3725:
--------------------------------------
Have you tested this against WF upstream, I think it may have already been fixed.
> Unable to deploy dynamic, programmatic JSR-356 Endpoints
> ---------------------------------------------------------
>
> Key: WFLY-3725
> URL: https://issues.jboss.org/browse/WFLY-3725
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Jim Crossley
> Assignee: Stuart Douglas
>
> I'm following the example here: https://github.com/undertow-io/undertow/blob/ceb019c91bd5ff5f219093298be9...
> I'm dynamically creating a Servlet instance and deploying it using the the ServletContext's addServlet method. The servlet init's method is similar to the above test case, obtaining a ServerContainer and calling its addEndpoint method with a ServerEndpointConfig$Configurator.
> Everything works fine in standalone Undertow 1.0.15.Final, but in WildFly 8.1, I see the following:
> [io.undertow.websockets.jsr] (MSC service thread 1-1) UT026005: Adding programmatic server endpoint class immutant.web.internal.servlet.proxy$javax.websocket.Endpoint$ff19274a for path /
> And then my configurator never gets called when I attempt to connect. It's as if the upgrade is never attempted, i.e. like the request protocol is 'http://' instead of 'ws://' but I know it's 'ws://' because the same client works fine against Undertow standalone.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-2510) Add CLI command to display information about current connection.
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-2510?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-2510:
---------------------------------------
Oh, I just forgot about the command prompt. I will send the PR for your review.
> Add CLI command to display information about current connection.
> ----------------------------------------------------------------
>
> Key: WFLY-2510
> URL: https://issues.jboss.org/browse/WFLY-2510
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: management_security,
> Fix For: Awaiting Volunteers
>
>
> Would be useful for a single command to display information about the current connection.
> Definitely information about SSL, certificates, authenticated user, address etc...
> Could also obtain other common info from server.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3725) Unable to deploy dynamic, programmatic JSR-356 Endpoints
by Jim Crossley (JIRA)
Jim Crossley created WFLY-3725:
----------------------------------
Summary: Unable to deploy dynamic, programmatic JSR-356 Endpoints
Key: WFLY-3725
URL: https://issues.jboss.org/browse/WFLY-3725
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.Final
Reporter: Jim Crossley
Assignee: Stuart Douglas
I'm following the example here: https://github.com/undertow-io/undertow/blob/ceb019c91bd5ff5f219093298be9...
I'm dynamically creating a Servlet instance and deploying it using the the ServletContext's addServlet method. The servlet init's method is similar to the above test case, obtaining a ServerContainer and calling its addEndpoint method with a ServerEndpointConfig$Configurator.
Everything works fine in standalone Undertow 1.0.15.Final, but in WildFly 8.1, I see the following:
[io.undertow.websockets.jsr] (MSC service thread 1-1) UT026005: Adding programmatic server endpoint class immutant.web.internal.servlet.proxy$javax.websocket.Endpoint$ff19274a for path /
And then my configurator never gets called when I attempt to connect. It's as if the upgrade is never attempted, i.e. like the request protocol is 'http://' instead of 'ws://' but I know it's 'ws://' because the same client works fine against Undertow standalone.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-2510) Add CLI command to display information about current connection.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2510?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2510:
----------------------------------------
Sounds good - personally I would say no it does not need to say domain or standalone mode as that is already indicated in the command prompt.
> Add CLI command to display information about current connection.
> ----------------------------------------------------------------
>
> Key: WFLY-2510
> URL: https://issues.jboss.org/browse/WFLY-2510
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: management_security,
> Fix For: Awaiting Volunteers
>
>
> Would be useful for a single command to display information about the current connection.
> Definitely information about SSL, certificates, authenticated user, address etc...
> Could also obtain other common info from server.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JASSIST-232) BadBytecode when trying access localVariable using insertAfter and asFinally = true
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-232?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-232:
---------------------------------------
The BadBytecode exception was thrown because aVar was not initialised if an exception is thrown.
I suppose doing insertBefore("aVar = null;") after doing insertAfter() would fix the problem.
> BadBytecode when trying access localVariable using insertAfter and asFinally = true
> -----------------------------------------------------------------------------------
>
> Key: JASSIST-232
> URL: https://issues.jboss.org/browse/JASSIST-232
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Reporter: Marvin Herman Froeder
> Assignee: Shigeru Chiba
>
> What I was trying to do:
> I wanna init a variable calling a method and then I wanna run a cleanup on
> finally.
> {code:java}
> private void originalMethod() {
> String aVar = null; // ctMethod.addLocalVariable()
> try{
> aVar = initVar(); // routine to create something ctMethod.insertBefore()
> runOriginalCode();
> }finally {
> dismiss(aVar); //cleanup routine ctMethod.insertAfter(,true)
> }
> }
> {code}
> I tried that by doing:
> {code:java}
> ctMethod.addLocalVariable("aVar", StringCtClass));
> ctMethod.insertBefore("aVar = initVar();");
> ctMethod.insertAfter(" dismiss( aVar );" , true);
> {code}
> But I got:
> {quote}
> javassist.CannotCompileException: by javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.CtBehavior.insertAfter(CtBehavior.java:880)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:127)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:120)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.instrumentContaAzul(DbAdvisorClassFileTransformer.java:66)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.transform(DbAdvisorClassFileTransformer.java:38)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest$1.loadClass(DbAdvisorClassFileTransformerTest.java:39)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest.contaazulish(DbAdvisorClassFileTransformerTest.java:93)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> Caused by: javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:111)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertAfter(CtBehavior.java:871)
> ... 31 more
> Caused by: javassist.bytecode.BadBytecode: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.TypeData$BasicType.setType(TypeData.java:134)
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:930)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:221)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108)
> ... 34 more
> {quote}
> and I also tried the other way around (insertAfter first and insertBefore later):
> {code:java}
> ctMethod.addLocalVariable("aVar", StringCtClass));
> ctMethod.insertAfter(" dismiss( aVar );" , true);
> ctMethod.insertBefore("aVar = initVar();");
> {code}
> still, same error
> {quote}
> javassist.CannotCompileException: by javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.CtBehavior.insertAfter(CtBehavior.java:880)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:126)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:120)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.instrumentContaAzul(DbAdvisorClassFileTransformer.java:66)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.transform(DbAdvisorClassFileTransformer.java:38)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest$1.loadClass(DbAdvisorClassFileTransformerTest.java:39)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest.contaazulish(DbAdvisorClassFileTransformerTest.java:93)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> Caused by: javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:111)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertAfter(CtBehavior.java:871)
> ... 31 more
> Caused by: javassist.bytecode.BadBytecode: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.TypeData$BasicType.setType(TypeData.java:134)
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:930)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:221)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108)
> ... 34 more
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (SECURITY-853) x500Name-regexp-match not working
by Frank Cornelis (JIRA)
Frank Cornelis created SECURITY-853:
---------------------------------------
Summary: x500Name-regexp-match not working
Key: SECURITY-853
URL: https://issues.jboss.org/browse/SECURITY-853
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossXACML
Affects Versions: picketbox_xacml_2.0.9.Final
Reporter: Frank Cornelis
Assignee: Stefan Guilhen
Fix For: PicketBox_XACML_2.0.10.Final
The x500Name-regexp-match function is not registered.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JASSIST-230) Javassist throws java.lang.VerifyError with dead code
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-230?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-230.
---------------------------------
> Javassist throws java.lang.VerifyError with dead code
> -----------------------------------------------------
>
> Key: JASSIST-230
> URL: https://issues.jboss.org/browse/JASSIST-230
> Project: Javassist
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Reporter: Kelvin Law
> Assignee: Shigeru Chiba
> Fix For: 3.19.0-GA
>
>
> I found the root cause of the Javassist throws java.lang.VerifyError with JRE 7, but the exact same binary works on JRE6
> It is because of dead code like the following:
> if (false) {
> do something;
> }
> These code is generated by the template:
> if (${transitory}) {
> do something;
> }
> The reason why we have such dead code in our generated java classes is, it is far more easier to code and maintain condition checking in runtime logic(in Java) instead of template logic (template expression). And we think that the if (false) statement does not make significant performance degradation in runtime.
> Although these code could be avoided, this is comply with Java 1.4/5/6/7 syntax standard thus it works with Javassist on JRE 6. Obviously It is a bug in Javassist.
> I have the following: tentative solution:
> Rewrite the if (${transitory}) with if (${transitory == true})
> I tested the above solution and found that Javassist works with that. No more java.lang.VerifyError. And I believe it does not make significant performance degradation in runtime.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JASSIST-230) Javassist throws java.lang.VerifyError with dead code
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-230?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-230.
-----------------------------------
Fix Version/s: 3.19.0-GA
Resolution: Done
> Javassist throws java.lang.VerifyError with dead code
> -----------------------------------------------------
>
> Key: JASSIST-230
> URL: https://issues.jboss.org/browse/JASSIST-230
> Project: Javassist
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Reporter: Kelvin Law
> Assignee: Shigeru Chiba
> Fix For: 3.19.0-GA
>
>
> I found the root cause of the Javassist throws java.lang.VerifyError with JRE 7, but the exact same binary works on JRE6
> It is because of dead code like the following:
> if (false) {
> do something;
> }
> These code is generated by the template:
> if (${transitory}) {
> do something;
> }
> The reason why we have such dead code in our generated java classes is, it is far more easier to code and maintain condition checking in runtime logic(in Java) instead of template logic (template expression). And we think that the if (false) statement does not make significant performance degradation in runtime.
> Although these code could be avoided, this is comply with Java 1.4/5/6/7 syntax standard thus it works with Javassist on JRE 6. Obviously It is a bug in Javassist.
> I have the following: tentative solution:
> Rewrite the if (${transitory}) with if (${transitory == true})
> I tested the above solution and found that Javassist works with that. No more java.lang.VerifyError. And I believe it does not make significant performance degradation in runtime.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months