[JBoss JIRA] (WFLY-1289) Spurious warnings about invalid META-INF/services class name
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-1289:
-------------------------------------
Summary: Spurious warnings about invalid META-INF/services class name
Key: WFLY-1289
URL: https://issues.jboss.org/browse/WFLY-1289
Project: WildFly
Issue Type: Bug
Components: Class Loading
Environment: 7.2.0.Final
java version "1.7.0_21"
Ubuntu 12.04 LTS
Reporter: Harald Wellmann
Assignee: David Lloyd
When an application contains a {{META-INF/services}} resource referencing an inner class, JBoss prints a spurious warning
{noformat}
JBAS015893: Encountered invalid class name 'com.acme.Foo$Bar' for service type 'com.acme.Service'
{noformat}
{{META-INF/services}} lists classes with their binary name, so dollar characters are likely to occur.
{{org.jboss.as.server.deployment.ServiceLoaderProcessor}} scans all {{META-INF/services}} resources but does not accept dollar characters in its validation pattern.
(Note: I can't select any 7.x release for "Affects Version".)
--
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, 8 months
[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
[ https://issues.jboss.org/browse/JASSIST-195?page=com.atlassian.jira.plugi... ]
John Brush updated JASSIST-195:
-------------------------------
Description:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
BTW: my only workaround for the time being is to force the 1.7 JVM to use the old verifier with -XX:-UseSplitVerifier.
was:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> Verifier error with try-finally clause in Java 1.7
> ---------------------------------------------------
>
> Key: JASSIST-195
> URL: https://issues.jboss.org/browse/JASSIST-195
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: Oracle Java 1.7 on Mac OS X
> Reporter: John Brush
> Assignee: Shigeru Chiba
>
> After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
> {code}
> public int testInstrumentedCallInFinallyBlock( int i )
> {
> try
> {}
> catch ( Throwable t )
> {}
> finally
> {
> i = incByOne( i );
> }
> return i;
> }
> {code}
> This unit test results in the following exception:
> java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
> After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #3 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: astore_2
> 10: aload_0
> 11: iload_1
> 12: invokespecial #3 // Method incByOne:(I)I
> 15: istore_1
> 16: aload_2
> 17: athrow
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 73 /* same_locals_1_stack_item */
> stack = [ class java/lang/Throwable ]
> frame_type = 8 /* same */
> {code}
> Afterwards, it looks like this:
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #23 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: nop
> 10: nop
> 11: nop
> 12: nop
> 13: nop
> 14: nop
> 15: goto 9
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 249 /* chop */
> offset_delta = 9
> frame_type = 253 /* append */
> offset_delta = 8
> locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
> {code}
> Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> BTW: my only workaround for the time being is to force the 1.7 JVM to use the old verifier with -XX:-UseSplitVerifier.
--
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, 8 months
[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
[ https://issues.jboss.org/browse/JASSIST-195?page=com.atlassian.jira.plugi... ]
John Brush updated JASSIST-195:
-------------------------------
Description:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
was:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
Afterwards, it looks like this:
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> Verifier error with try-finally clause in Java 1.7
> ---------------------------------------------------
>
> Key: JASSIST-195
> URL: https://issues.jboss.org/browse/JASSIST-195
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: Oracle Java 1.7 on Mac OS X
> Reporter: John Brush
> Assignee: Shigeru Chiba
>
> After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
> {code}
> public int testInstrumentedCallInFinallyBlock( int i )
> {
> try
> {}
> catch ( Throwable t )
> {}
> finally
> {
> i = incByOne( i );
> }
> return i;
> }
> {code}
> This unit test results in the following exception:
> java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
> After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #3 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: astore_2
> 10: aload_0
> 11: iload_1
> 12: invokespecial #3 // Method incByOne:(I)I
> 15: istore_1
> 16: aload_2
> 17: athrow
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 73 /* same_locals_1_stack_item */
> stack = [ class java/lang/Throwable ]
> frame_type = 8 /* same */
> {code}
> Afterwards, it looks like this:
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #23 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: nop
> 10: nop
> 11: nop
> 12: nop
> 13: nop
> 14: nop
> 15: goto 9
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 249 /* chop */
> offset_delta = 9
> frame_type = 253 /* append */
> offset_delta = 8
> locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
> {code}
> Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
--
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, 8 months
[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
John Brush created JASSIST-195:
----------------------------------
Summary: Verifier error with try-finally clause in Java 1.7
Key: JASSIST-195
URL: https://issues.jboss.org/browse/JASSIST-195
Project: Javassist
Issue Type: Bug
Affects Versions: 3.17.1-GA
Environment: Oracle Java 1.7 on Mac OS X
Reporter: John Brush
Assignee: Shigeru Chiba
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
Afterwards, it looks like this:
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
--
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, 8 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Abhi Datt (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Abhi Datt edited comment on AS7-6079 at 4/27/13 2:19 AM:
---------------------------------------------------------
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers that issue
Thanks again.
was (Author: abhidatt):
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers this issue
Thanks again.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
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, 8 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Abhi Datt (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Abhi Datt commented on AS7-6079:
--------------------------------
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers this issue
Thanks again.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
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, 8 months