[JBoss JIRA] (JASSIST-39) failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-39?page=com.atlassian.jira.plugin... ]
Shigeru Chiba closed JASSIST-39.
--------------------------------
> failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-39
> URL: https://issues.jboss.org/browse/JASSIST-39
> Project: Javassist
> Issue Type: Bug
> Reporter: twieger
> Assignee: Shigeru Chiba
> Fix For: 3.13.0.GA
>
>
> The testcase below demonstrates the problem.
> The first invocation of CtNewMethod#make works, the second one fails.
> It looks like the problem is related with MemberResolver#lookupMethod.
> The check to enable the creation of a recursively called method is not precise enough. It actually succeeds, although the current method is an instance method, and the method which shall be invoked is a static method.
> ==========================================
> package experimental;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtNewMethod;
> import org.testng.annotations.Test;
> public class TestJavaAssist {
> @Test
> public void testJavaAssist() throws CannotCompileException {
> ClassPool classPool = new ClassPool();
> classPool.appendSystemPath();
>
> CtClass ctClass = classPool.makeClass("Test");
> CtNewMethod.make("public String foox(){return experimental.TestJavaAssist.foo();}", ctClass);
> CtNewMethod.make("public String foo(){return experimental.TestJavaAssist.foo();}", ctClass);
> }
> public static final String foo() {
> return "foo";
> }
> }
--
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
11 years, 4 months
[JBoss JIRA] (JASSIST-182) update ClassFileWriter for Java 7 invokedynamic
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-182?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-182.
---------------------------------
> update ClassFileWriter for Java 7 invokedynamic
> -----------------------------------------------
>
> Key: JASSIST-182
> URL: https://issues.jboss.org/browse/JASSIST-182
> Project: Javassist
> Issue Type: Feature Request
> Affects Versions: 3.17.0-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.17.1-GA
>
> Attachments: classfilewriter.patch
>
>
> (Originally reported by Grigori Goronzy)
> With Javassist 3.17, the ClassFile, ConstPool, etc. classes gained support for the invokedynamic JVM opcode and associated constant pool data. However, ClassFileWriter wasn't updated, and it isn't possible, for instance, to add an InvokeDynamic_info with a ConstPoolWriter.
> The attached patch fixes this in the most straight-forward manner. I haven't tested it well, but the code is so simple that it is unlikely to have any bugs.
--
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
11 years, 4 months
[JBoss JIRA] (JASSIST-187) Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-187?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-187:
---------------------------------------
Can you post the test code compressed by a much simpler way such as .zip and .jar?
Thank you!
> Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-187
> URL: https://issues.jboss.org/browse/JASSIST-187
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.0-GA, 3.16.1-GA, 3.17.0-GA
> Environment: Windows 7 x64 Oracle JVM x86/x64 1.6.37 - no error
> Linux Ubuntu x64 Oracle JVM x64 1.6.37 - error
> Reporter: Alexander Zinin
> Assignee: Shigeru Chiba
> Attachments: javassist-test.rar
>
>
> It will be difficult to describe what the error.
> I will attach source code that reproduce error.
> If you have hibernate entity with overrided getId() method, in hibernate session this method returns null instead of correct value.
> Running on Windows:
> 2012-12-16 17:33:19,332 INFO ru.zinin.service.SomeServiceImpl :44 - ID = 1
> Running on Linux:
> 2012-12-16 17:41:47,772 INFO ru.zinin.service.SomeServiceImpl :44 - ID = null
> 2012-12-16 17:41:47,772 ERROR ru.zinin.service.SomeServiceImpl :46 - ID IS NULL!!!
> Bug appeared in version 3.16.0.
--
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
11 years, 4 months
[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment
by Philippe Marschall (JIRA)
[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ]
Philippe Marschall commented on AS7-6246:
-----------------------------------------
Very well. I'm not very versed with JBoss internals and when somebody more experienced looks a this that's good.
> Naming context read-only during legacy SAR deployment
> -----------------------------------------------------
>
> Key: AS7-6246
> URL: https://issues.jboss.org/browse/AS7-6246
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX, Naming
> Affects Versions: 7.2.0.Alpha1
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
> Labels: jmx, jndi, naming, sar
>
> When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only.
> Consider the following MBean:
> {code}
> public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean {
> private static final String NAME = "java:global/env/foo/legacy";
> private static final String VALUE = "BAR";
> private static final Logger LOG = Logger.getLogger("sar-legacy");
> public LegacySample() {
> super();
> }
> @Override
> protected void startService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.rebind(NAME, VALUE);
> LOG.info("started");
> }
> @Override
> protected void stopService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.unbind(NAME);
> LOG.info("stopped");
> }
> @Override
> public String getMessage() {
> return "legacy";
> }
> }
> {code}
> This will fail.
--
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
11 years, 4 months
[JBoss JIRA] (AS7-6249) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Christian Kaltepoth (JIRA)
[ https://issues.jboss.org/browse/AS7-6249?page=com.atlassian.jira.plugin.s... ]
Christian Kaltepoth updated AS7-6249:
-------------------------------------
Steps to Reproduce:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
Expected output:
{code}
15:34:10,382 INFO [stdout] (MSC service thread 1-1) =============================================================
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.toString(): jndi:/default-host/tomcat-url-bug/file%231.txt
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.getPath(): /default-host/tomcat-url-bug/file%231.txt
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.getRef(): null
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.openStream(): SUCCESS
15:34:10,385 INFO [stdout] (MSC service thread 1-1) =============================================================
{code}
was:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
Expected output:
{code}
15:34:10,382 INFO [stdout] (MSC service thread 1-1) =============================================================
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.getPath(): /default-host/tomcat-url-bug/file1.txt
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.getRef(): null
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.openStream(): SUCCESS
15:34:10,385 INFO [stdout] (MSC service thread 1-1) =============================================================
{code}
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6249
> URL: https://issues.jboss.org/browse/AS7-6249
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
> Reporter: Christian Kaltepoth
> Assignee: Remy Maucherat
> Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath(): /default-host/tomcat-url-bug/file
> url.getRef(): 1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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
11 years, 4 months
[JBoss JIRA] (AS7-6249) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Christian Kaltepoth (JIRA)
[ https://issues.jboss.org/browse/AS7-6249?page=com.atlassian.jira.plugin.s... ]
Christian Kaltepoth updated AS7-6249:
-------------------------------------
Steps to Reproduce:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
Expected output:
{code}
15:34:10,382 INFO [stdout] (MSC service thread 1-1) =============================================================
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.toString(): jndi:/default-host/tomcat-url-bug/file%231.txt
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.getPath(): /default-host/tomcat-url-bug/file%231.txt
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.getRef(): null
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.openStream(): SUCCESS
15:34:10,385 INFO [stdout] (MSC service thread 1-1) =============================================================
{code}
Note: {{#}} has to be encoded as {{%23}}.
was:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
Expected output:
{code}
15:34:10,382 INFO [stdout] (MSC service thread 1-1) =============================================================
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.toString(): jndi:/default-host/tomcat-url-bug/file%231.txt
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.getPath(): /default-host/tomcat-url-bug/file%231.txt
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.getRef(): null
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.openStream(): SUCCESS
15:34:10,385 INFO [stdout] (MSC service thread 1-1) =============================================================
{code}
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6249
> URL: https://issues.jboss.org/browse/AS7-6249
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
> Reporter: Christian Kaltepoth
> Assignee: Remy Maucherat
> Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath(): /default-host/tomcat-url-bug/file
> url.getRef(): 1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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
11 years, 4 months
[JBoss JIRA] (AS7-6249) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Christian Kaltepoth (JIRA)
Christian Kaltepoth created AS7-6249:
----------------------------------------
Summary: ServletContext.getResource() doesn't work correctly for files containing hash characters
Key: AS7-6249
URL: https://issues.jboss.org/browse/AS7-6249
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.3.Final (EAP)
Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
Reporter: Christian Kaltepoth
Assignee: Remy Maucherat
Attachments: as7-url-bug.zip
{{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
Example:
{code:java}
URL url = servletContext.getResource("/file#1.txt");
{code}
The resulting URL object will be spitted at the {{#}} character like this:
{code}
url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
url.getPath(): /default-host/tomcat-url-bug/file
url.getRef(): 1.txt
{code}
Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
This is a known Tomcat issue fixed in 7.0.28.
References:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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
11 years, 4 months