[JBoss JIRA] (WFLY-1737) org.jboss.as.model.test.ModelTestUtils String[] is incompatible with expected argument type String
by Filipe Ferraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1737?page=com.atlassian.jira.plugin.... ]
Filipe Ferraz commented on WFLY-1737:
-------------------------------------
Changing the pe.getKeyValuePair() to pe.getKey() can resolve this bug?
children is a set<String> of names and the pe.getkey() return the name (String) that can be verified if exits in the set
> org.jboss.as.model.test.ModelTestUtils String[] is incompatible with expected argument type String
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-1737
> URL: https://issues.jboss.org/browse/WFLY-1737
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Beta1
>
>
> children is a Set<String>, but pe.getKeyValuePair() is String[], so it will always return false.
> {code}
> } else {
> if (children.contains(pe.getKeyValuePair())) {
> String name = pe.getValue();
> ModelNode value = model.get(pe.getKeyValuePair());
> ManagementResourceRegistration sub = rr.getSubModel(PathAddress.pathAddress(pe));
> Assert.assertNotNull(getComparePathAsString(stack) + " Child with name '" + name + "' not found", sub);
> if (value.isDefined()) {
> stack.push(pe);
> checkModelAgainstDefinition(value, sub, stack);
> stack.pop();
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-807) ServletContext#getRealPath() returns wrong path
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-807?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved WFLY-807.
---------------------------------
Resolution: Out of Date
This appears to work fine now.
> ServletContext#getRealPath() returns wrong path
> -----------------------------------------------
>
> Key: WFLY-807
> URL: https://issues.jboss.org/browse/WFLY-807
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Environment: MacOSX Lion
> Reporter: Douglas Campos
> Assignee: Stuart Douglas
>
> GET /aerogear-controller-demo/test.haml
> ServletContext.getRealPath("/aerogear-controller-demo/test.haml") returns:
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/aerogear-controller-demo/test.haml
> this path points to a non-existing place, the right one to return would be
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/test.haml
> (note the stripped contextPath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-807) ServletContext#getRealPath() returns wrong path
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-807?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on WFLY-807:
-----------------------------------
This is a year old bug report and probably not relevant. Maybe there was a bug in a certain version which used to copy over the web app content at the wrong location in the tmp/vfs folder.
I've anyway assigned this to Stuart since I think he'll know a bit more about the expected behaviour of this API and can close this JIRA if it isn't an issue.
> ServletContext#getRealPath() returns wrong path
> -----------------------------------------------
>
> Key: WFLY-807
> URL: https://issues.jboss.org/browse/WFLY-807
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Environment: MacOSX Lion
> Reporter: Douglas Campos
> Assignee: Stuart Douglas
>
> GET /aerogear-controller-demo/test.haml
> ServletContext.getRealPath("/aerogear-controller-demo/test.haml") returns:
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/aerogear-controller-demo/test.haml
> this path points to a non-existing place, the right one to return would be
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/test.haml
> (note the stripped contextPath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-807) ServletContext#getRealPath() returns wrong path
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-807?page=com.atlassian.jira.plugin.s... ]
jaikiran pai updated WFLY-807:
------------------------------
Assignee: Stuart Douglas
Component/s: Web (JBoss Web)
> ServletContext#getRealPath() returns wrong path
> -----------------------------------------------
>
> Key: WFLY-807
> URL: https://issues.jboss.org/browse/WFLY-807
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Environment: MacOSX Lion
> Reporter: Douglas Campos
> Assignee: Stuart Douglas
>
> GET /aerogear-controller-demo/test.haml
> ServletContext.getRealPath("/aerogear-controller-demo/test.haml") returns:
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/aerogear-controller-demo/test.haml
> this path points to a non-existing place, the right one to return would be
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/test.haml
> (note the stripped contextPath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-807) ServletContext#getRealPath() returns wrong path
by Filipe Ferraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-807?page=com.atlassian.jira.plugin.s... ]
Filipe Ferraz commented on WFLY-807:
------------------------------------
I have tried to reproduce this bug in my system (MacOSX Lion and Wildfly 8.0.0.Alpha4-SNAPSHOT) creating a test servlet that responds to 'app-context/test', a file.txt at webapp dir and inside the servlet#doGet() get the servletContext and run the following commands:
1. servletContext.getRealPath("") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servlet-test.war-10e40a3c8a480cb5/
2. servletContext.getRealPath("/test") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/test
3. servletContext.getRealPath("/file.txt") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/file.txt
4. servletContext.getRealPath("/test/file.txt") : null
Seems to be the correct and expected response, the line 4 will return a non null value just if inside the webapp the file is inside a test folder.
If possible try to explain more the problem to be possible reproduce the bug (for me seems to not be a bug, it's and expected behavior).
> ServletContext#getRealPath() returns wrong path
> -----------------------------------------------
>
> Key: WFLY-807
> URL: https://issues.jboss.org/browse/WFLY-807
> Project: WildFly
> Issue Type: Bug
> Environment: MacOSX Lion
> Reporter: Douglas Campos
>
> GET /aerogear-controller-demo/test.haml
> ServletContext.getRealPath("/aerogear-controller-demo/test.haml") returns:
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/aerogear-controller-demo/test.haml
> this path points to a non-existing place, the right one to return would be
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/test.haml
> (note the stripped contextPath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-807) ServletContext#getRealPath() returns wrong path
by Filipe Ferraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-807?page=com.atlassian.jira.plugin.s... ]
Filipe Ferraz edited comment on WFLY-807 at 7/22/13 11:24 PM:
--------------------------------------------------------------
I tried to reproduce this bug in my system (MacOSX Lion and Wildfly 8.0.0.Alpha4-SNAPSHOT) creating a test servlet that responds to 'app-context/test', a file.txt at webapp dir and inside the servlet#doGet() get the servletContext and run the following commands:
1. servletContext.getRealPath("") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servlet-test.war-10e40a3c8a480cb5/
2. servletContext.getRealPath("/test") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/test
3. servletContext.getRealPath("/file.txt") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/file.txt
4. servletContext.getRealPath("/test/file.txt") : null
Seems to be the correct and expected response, the line 4 will return a non null value just if inside the webapp the file is inside a test folder.
If possible try to explain more the problem to be possible reproduce the bug (for me seems to not be a bug, it's and expected behavior).
was (Author: filipeferraz):
I have tried to reproduce this bug in my system (MacOSX Lion and Wildfly 8.0.0.Alpha4-SNAPSHOT) creating a test servlet that responds to 'app-context/test', a file.txt at webapp dir and inside the servlet#doGet() get the servletContext and run the following commands:
1. servletContext.getRealPath("") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servlet-test.war-10e40a3c8a480cb5/
2. servletContext.getRealPath("/test") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/test
3. servletContext.getRealPath("/file.txt") : {...}/wildfly-8.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp75c7aa7a10b66a9e/servet-test.war-10e40a3c8a480cb5/file.txt
4. servletContext.getRealPath("/test/file.txt") : null
Seems to be the correct and expected response, the line 4 will return a non null value just if inside the webapp the file is inside a test folder.
If possible try to explain more the problem to be possible reproduce the bug (for me seems to not be a bug, it's and expected behavior).
> ServletContext#getRealPath() returns wrong path
> -----------------------------------------------
>
> Key: WFLY-807
> URL: https://issues.jboss.org/browse/WFLY-807
> Project: WildFly
> Issue Type: Bug
> Environment: MacOSX Lion
> Reporter: Douglas Campos
>
> GET /aerogear-controller-demo/test.haml
> ServletContext.getRealPath("/aerogear-controller-demo/test.haml") returns:
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/aerogear-controller-demo/test.haml
> this path points to a non-existing place, the right one to return would be
> /Users/qmx/dev/jboss-as-7.1.1.Final/standalone/tmp/vfs/temp6e0c35ea20e93021/content-85417a32e88feba4/test.haml
> (note the stripped contextPath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when inserting throw Expression with Java 7
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-207:
--------------------------------------
I cloned test4.LocalVars.run() into test4.JASSIST207.test() (see https://github.com/scottmarlow/javassist/tree/JASSIST-207) and also went back to the original inserted code (could possibly be hitting dead code issues).
{quote}
<testcase time="0.005" classname="javassist.JvstTest4" name="testThrowExpression">
<error message="StackMapTable error: bad offset in method test4.JASSIST207.test()I" type="java.lang.VerifyError">java.lang.VerifyError: StackMapTable error: bad offset in method test4.JASSIST207.test()I
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
at java.lang.Class.getConstructor0(Class.java:2723)
at java.lang.Class.newInstance0(Class.java:345)
at java.lang.Class.newInstance(Class.java:327)
at javassist.JvstTestRoot.make(JvstTestRoot.java:37)
at javassist.JvstTest4.testThrowExpression(JvstTest4.java:827)
</error>
{quote}
If I instead insert conditional code that tests a public class variable setting and then throws the assertion, no error occurs. In the test code, [you can see this around here|https://github.com/scottmarlow/javassist/commit/93ec9f78e61c4784b27d...].
I'm using JDK 1.7.0_21 (on Fedora 19).
{quote}
If the Javassist compiler is skipping cleaning up the local variable table or stack map table because of unreachable code, that would be a good explanation. As a library user I would then expect a BadBytecode exception to be thrown during Javassist compile-time, and not a non-related exception during class-loading time.
{quote}
It is possible that we have identified a problem (dead code detection may be causing this) and workaround (avoid asking Javassist to generate dead code). Could you try working around the error in your real case, by avoiding asking Javassist to generate dead code (if that is possible for you to try)?
I also agree, that if this is a problem with "dead code detection", that a compile time error would be better.
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
> Key: JASSIST-207
> URL: https://issues.jboss.org/browse/JASSIST-207
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Reporter: Ben Romberg
> Assignee: Shigeru Chiba
> Priority: Critical
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> public ThrowExpressionCorruptsStackMapTableTest(String name) {
> super(name);
> }
> public void testInsertLocalVars() throws Exception {
> CtClass cc = sloader.get("test4.LocalVars");
> CtMethod m1 = cc.getDeclaredMethod("run");
> m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> cc.writeFile();
> Object obj = make(cc.getName());
> assertEquals(10, invoke(obj, "run"));
> }
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JASSIST-183) API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-183?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-183:
---------------------------------------
I fixed JASSIST-206.
> API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-183
> URL: https://issues.jboss.org/browse/JASSIST-183
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA, 3.17.1-GA
> Environment: Seam 2.2.2 / 2.3.0, Java 7u9
> Reporter: Andrei Ivanov
> Assignee: Shigeru Chiba
> Priority: Blocker
> Labels: regression
> Fix For: 3.18.0-GA
>
>
> Checking how some applications run with Java 7, I've tried to upgrade to the newly released Javassist just to notice Seam is no longer working:
> {noformat}
> java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findSuperMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
> at OrderInitializer_$$_javassist_seam_0.writeReplace(OrderInitializer_$$_javassist_seam_0.java)
> at org.jboss.seam.Component.postConstructJavaBean(Component.java:1461)
> at org.jboss.seam.Component.postConstruct(Component.java:1379)
> at org.jboss.seam.Component.newInstance(Component.java:2155)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
> at org.jboss.seam.init.Initialization.init(Initialization.java:744)
> at org.jboss.seam.mock.AbstractSeamTest.startSeam(AbstractSeamTest.java:929)
> at org.jboss.seam.mock.SeamTest.startSeam(SeamTest.java:69)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months