[JBoss JIRA] Created: (JBAS-5739) Allow the use of "this" in annotated named pointcuts, typedefs etc.
by Kabir Khan (JIRA)
Allow the use of "this" in annotated named pointcuts, typedefs etc.
-------------------------------------------------------------------
Key: JBAS-5739
URL: http://jira.jboss.com/jira/browse/JBAS-5739
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Kabir Khan
Assigned To: Stale Pedersen
Currently you have to use the fqn when referencing these things:
package org.jboss.test.microcontainer.annotatedaop;
@Aspect(scope=Scope.PER_VM)
public class SomeAspect
{
@TypeDef("class(org.jboss.test.microcontainer.annotatedaop.SimplePOJO)")
Object typedef;
@PointcutDef("execution(* $typedef{org.jboss.test.microcontainer.annotatedaop.SomeAspect.typedef}->method())")
Object pointcut;
@Bind(pointcut="org.jboss.test.microcontainer.annotatedaop.SomeAspect.pointcut")
public Object advice(MethodInvocation inv) throws Throwable{}
}
it would be better to be able to do:
package org.jboss.test.microcontainer.annotatedaop;
@Aspect(scope=Scope.PER_VM)
public class SomeAspect
{
@TypeDef("class(org.jboss.test.microcontainer.annotatedaop.SimplePOJO)")
Object typedef;
@PointcutDef("execution(* $typedef{this.typedef}->method())")
Object pointcut;
@Bind(pointcut="this.pointcut")
public Object advice(MethodInvocation inv) throws Throwable{}
}
The word "this" is just a suggestion, if we could get rid of it, that would be better. If we need to keep it, we might want to use something more recognisable for string replacement, for exampe "$this$"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBWEB-75) Contention in ApplicationContext
by Phillip Thurmond (JIRA)
Contention in ApplicationContext
--------------------------------
Key: JBWEB-75
URL: http://jira.jboss.com/jira/browse/JBWEB-75
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss 4.0.5, Linux, Java 5
Reporter: Phillip Thurmond
Assigned To: Mladen Turk
I'm seeing some contention inside Tomcat on ApplicationContext.getAttribute() when I run performance tests using a Seam application. With a load of 200 threads, I often see over 150 "waiting to lock" messages on the attributes object. It looks like this contention has already been fixed in Tomcat 6 using the Java 5 concurrent objects.
I also posted to the Tomcat development list about this issue, but Remy did not want to fix it because he didn't want to introduce any new dependencies into the project. I think this is important to fix if we expect users to deploy Seam on 4.0.5.
Example thread dump:
"http-10.68.0.196-8080-301" daemon prio=1 tid=0x0000002b51e425b0 nid=0x78a5 waiting for monitor entry [0x000000005b86c000..0x000000005b86cdb0]
at org.apache.catalina.core.ApplicationContext.getAttribute(ApplicationContext.java:175)
- waiting to lock <0x0000002aabd633b0> (a java.util.HashMap)
at org.apache.catalina.core.ApplicationContextFacade.getAttribute(ApplicationContextFacade.java:315)
at org.apache.myfaces.context.servlet.ApplicationMap.getAttribute(ApplicationMap.java:41)
at org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:87)
at org.jboss.seam.contexts.FacesApplicationContext.get(FacesApplicationContext.java:47)
at org.jboss.seam.Component.forName(Component.java:1588)
at org.jboss.seam.Component.getInstance(Component.java:1636)
at org.jboss.seam.Component.getInstance(Component.java:1631)
at org.jboss.seam.Component.getInstance(Component.java:1608)
at org.jboss.seam.Component.getInstance(Component.java:1603)
at org.jboss.seam.core.Events.instance(Events.java:158)
at org.jboss.seam.jsf.AbstractSeamPhaseListener.afterPhase(AbstractSeamPhaseListener.java:139)
at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:69)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBWEB-74) tomcat config files fail to support default sysprop values like other jboss-service.xml type configs
by John Mazzitelli (JIRA)
tomcat config files fail to support default sysprop values like other jboss-service.xml type configs
----------------------------------------------------------------------------------------------------
Key: JBWEB-74
URL: http://jira.jboss.com/jira/browse/JBWEB-74
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Reporter: John Mazzitelli
Assigned To: Mladen Turk
>From my JBoss forum post and Dimitris' reply:
In jboss-service.xml, you can define values via properties like this:
${my.prop:123}
where the value will be 123 if and only if my.prop property is not explictly set.
However, this syntax does not seem to work on JBossAS 4.0.5 within the jbossweb-tomcat55.sar's server.xml.
If I use ${my.prop} in server.xml, it works fine. But if I define a default value like ${my.prop:123}, it doesn't work - the value becomes literally ${my.prop}.
Dimitris Andreadis reply: "JBoss uses org.jboss.util.StringPropertyReplacer for substituting variables. Tomcat/jboss-web must be using a different way to do this, so this is really a feature request for jboss-web."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Resolved: (JBWEB-57) Threading issue using tomcat
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-57?page=com.atlassian.jira.plugi... ]
Remy Maucherat resolved JBWEB-57.
---------------------------------
Resolution: Rejected
> Threading issue using tomcat
> ----------------------------
>
> Key: JBWEB-57
> URL: https://jira.jboss.org/jira/browse/JBWEB-57
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat Module
> Reporter: Lamon Gray
> Assignee: Remy Maucherat
>
> the threading bug observed in tomcat has been reproduced in data pool manager (dpm) on both redhat linux enterprise server as 3 and microsoft windows xp professional version 2002 sp2 operating systems. we are currently running apache tomcat 5.5.9 coupled with j2se 5.0 update 6 in all of our environments.
> to reproduce the threading bug, two users log in separately from different workstations to the dpm application and on the main menu screen, both users click on the same link simultaneously. tomcat processes the incoming requests properly most of the time and each user is presented with the resulting web screen. however, about 1 out of every 10 times, a series of exceptions is thrown and one user is forwarded to an error page. the enclosed log file tomcat_thread_debug.log captures the results of one of these instances. because the text is difficult to follow, we generated the enclosed file tomcatthreadingbug.png which illustrates graphically the methods invoked by each thread and how individual objects were updated as a function of time. use this illustration when walking through the following summary of what i?s happening:
> 1) each user logs in to dpm and a unique DBService object is created for each user and stored in each user'?s session object (DBService is a container for a single Connection object and also manages transactions for the connection)
> 2) from the main menu page, both users select the Maintain Company Profile link simultaneously
> 3) a unique ClientCompanyProfileInfoMaintenance object is created for each user and each user's DBService object is passed in as an argument
> 4) Thread1 [Thread[http-14104-Processor24,5,main] opens a Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [6f19d5]
> 5) Thread2 [Thread[http-14104-Processor22,5,main] opens a Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 6) Thread1 then closes the Connection [null] in DBService [6f19d5]
> 7) Thread1 then attempts to open the Connection [311410] that was previously opened by Thread2 in DBService [8809ce]; attempting to open a connection that has already been opened is flagged as an exception and Exception1 is thrown
> 8) Thread2 closes the Connection [null] in DBService [8809ce]
> 9) Thread1 then attempts to get a Connection [null] that was previously closed by Thread2 in DBService [8809ce]; attempting to get a Connection that is closed is flagged as an exception and Exception2 is thrown; Thread1 then opens a new Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 10)Thread2 then opens a new Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [8809ce] replacing the previous connection
> 11)Thread1 continues and then ends its transaction performing a commit which causes the next result set retrieved by Thread2 to throw Exception3 which is a NullPointerException runtime exception
> the problem is that after starting out on the right track, Thread1 ceases operating on its own DBService object and then begins operating on Thread2's DBService object concurrent with Thread2's operations. we don't understand how this is possible since the Connection object is defined as an instance variable in the DBService class and there are 2 unique DBService objects created and each is stored in a separate unique session object created by tomcat. again, this only happens about 1 out of every 10 times and works properly the rest of the time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Resolved: (JBWEB-57) Threading issue using tomcat
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-57?page=com.atlassian.jira.plugi... ]
Remy Maucherat resolved JBWEB-57.
---------------------------------
Resolution: Done
Assignee: Remy Maucherat (was: Mladen Turk)
This issue does not make much sense to me. There are no known core threading issues with Tomcat, but obviously you have to be careful when dealing with any shared objects.
> Threading issue using tomcat
> ----------------------------
>
> Key: JBWEB-57
> URL: https://jira.jboss.org/jira/browse/JBWEB-57
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat Module
> Reporter: Lamon Gray
> Assignee: Remy Maucherat
>
> the threading bug observed in tomcat has been reproduced in data pool manager (dpm) on both redhat linux enterprise server as 3 and microsoft windows xp professional version 2002 sp2 operating systems. we are currently running apache tomcat 5.5.9 coupled with j2se 5.0 update 6 in all of our environments.
> to reproduce the threading bug, two users log in separately from different workstations to the dpm application and on the main menu screen, both users click on the same link simultaneously. tomcat processes the incoming requests properly most of the time and each user is presented with the resulting web screen. however, about 1 out of every 10 times, a series of exceptions is thrown and one user is forwarded to an error page. the enclosed log file tomcat_thread_debug.log captures the results of one of these instances. because the text is difficult to follow, we generated the enclosed file tomcatthreadingbug.png which illustrates graphically the methods invoked by each thread and how individual objects were updated as a function of time. use this illustration when walking through the following summary of what i?s happening:
> 1) each user logs in to dpm and a unique DBService object is created for each user and stored in each user'?s session object (DBService is a container for a single Connection object and also manages transactions for the connection)
> 2) from the main menu page, both users select the Maintain Company Profile link simultaneously
> 3) a unique ClientCompanyProfileInfoMaintenance object is created for each user and each user's DBService object is passed in as an argument
> 4) Thread1 [Thread[http-14104-Processor24,5,main] opens a Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [6f19d5]
> 5) Thread2 [Thread[http-14104-Processor22,5,main] opens a Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 6) Thread1 then closes the Connection [null] in DBService [6f19d5]
> 7) Thread1 then attempts to open the Connection [311410] that was previously opened by Thread2 in DBService [8809ce]; attempting to open a connection that has already been opened is flagged as an exception and Exception1 is thrown
> 8) Thread2 closes the Connection [null] in DBService [8809ce]
> 9) Thread1 then attempts to get a Connection [null] that was previously closed by Thread2 in DBService [8809ce]; attempting to get a Connection that is closed is flagged as an exception and Exception2 is thrown; Thread1 then opens a new Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 10)Thread2 then opens a new Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [8809ce] replacing the previous connection
> 11)Thread1 continues and then ends its transaction performing a commit which causes the next result set retrieved by Thread2 to throw Exception3 which is a NullPointerException runtime exception
> the problem is that after starting out on the right track, Thread1 ceases operating on its own DBService object and then begins operating on Thread2's DBService object concurrent with Thread2's operations. we don't understand how this is possible since the Connection object is defined as an instance variable in the DBService class and there are 2 unique DBService objects created and each is stored in a separate unique session object created by tomcat. again, this only happens about 1 out of every 10 times and works properly the rest of the time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Reopened: (JBWEB-57) Threading issue using tomcat
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-57?page=com.atlassian.jira.plugi... ]
Remy Maucherat reopened JBWEB-57:
---------------------------------
> Threading issue using tomcat
> ----------------------------
>
> Key: JBWEB-57
> URL: https://jira.jboss.org/jira/browse/JBWEB-57
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat Module
> Reporter: Lamon Gray
> Assignee: Remy Maucherat
>
> the threading bug observed in tomcat has been reproduced in data pool manager (dpm) on both redhat linux enterprise server as 3 and microsoft windows xp professional version 2002 sp2 operating systems. we are currently running apache tomcat 5.5.9 coupled with j2se 5.0 update 6 in all of our environments.
> to reproduce the threading bug, two users log in separately from different workstations to the dpm application and on the main menu screen, both users click on the same link simultaneously. tomcat processes the incoming requests properly most of the time and each user is presented with the resulting web screen. however, about 1 out of every 10 times, a series of exceptions is thrown and one user is forwarded to an error page. the enclosed log file tomcat_thread_debug.log captures the results of one of these instances. because the text is difficult to follow, we generated the enclosed file tomcatthreadingbug.png which illustrates graphically the methods invoked by each thread and how individual objects were updated as a function of time. use this illustration when walking through the following summary of what i?s happening:
> 1) each user logs in to dpm and a unique DBService object is created for each user and stored in each user'?s session object (DBService is a container for a single Connection object and also manages transactions for the connection)
> 2) from the main menu page, both users select the Maintain Company Profile link simultaneously
> 3) a unique ClientCompanyProfileInfoMaintenance object is created for each user and each user's DBService object is passed in as an argument
> 4) Thread1 [Thread[http-14104-Processor24,5,main] opens a Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [6f19d5]
> 5) Thread2 [Thread[http-14104-Processor22,5,main] opens a Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 6) Thread1 then closes the Connection [null] in DBService [6f19d5]
> 7) Thread1 then attempts to open the Connection [311410] that was previously opened by Thread2 in DBService [8809ce]; attempting to open a connection that has already been opened is flagged as an exception and Exception1 is thrown
> 8) Thread2 closes the Connection [null] in DBService [8809ce]
> 9) Thread1 then attempts to get a Connection [null] that was previously closed by Thread2 in DBService [8809ce]; attempting to get a Connection that is closed is flagged as an exception and Exception2 is thrown; Thread1 then opens a new Connection [311410] retrieved from the connection pool and stores it in DBService [8809ce]
> 10)Thread2 then opens a new Connection [1ecfcd9] retrieved from the connection pool and stores it in DBService [8809ce] replacing the previous connection
> 11)Thread1 continues and then ends its transaction performing a commit which causes the next result set retrieved by Thread2 to throw Exception3 which is a NullPointerException runtime exception
> the problem is that after starting out on the right track, Thread1 ceases operating on its own DBService object and then begins operating on Thread2's DBService object concurrent with Thread2's operations. we don't understand how this is possible since the Connection object is defined as an instance variable in the DBService class and there are 2 unique DBService objects created and each is stored in a separate unique session object created by tomcat. again, this only happens about 1 out of every 10 times and works properly the rest of the time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBWEB-94) JBoss Web 2.1.0
by Remy Maucherat (JIRA)
JBoss Web 2.1.0
---------------
Key: JBWEB-94
URL: http://jira.jboss.com/jira/browse/JBWEB-94
Project: JBoss Web
Issue Type: Release
Security Level: Public (Everyone can see)
Reporter: Remy Maucherat
Assigned To: Mladen Turk
Based on Apache Tomcat 6.0.x, with the following changes:
- Swicth to JBoss logging from Apache Commons Logging.
- Remove Tomcat standalone session clustering.
- Add a system property to delay startup of connectors for JBoss.
- Add context listener configuration.
- Expanded Comet API as a separate package.
- Remove user database functionality (no development of it since Tomcat 4.1).
- Add rewrite valve and PHP servlet from JBoss Web 2.0.
- Use a system property for the session cookie name.
- Remove HTTP NIO connector.
- Remove legacy org.apache.jk AJP connector and utility components.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months