[JBoss JIRA] Created: (JBREM-728) Improve access to HTTP response headers
by Thomas Diesler (JIRA)
Improve access to HTTP response headers
---------------------------------------
Key: JBREM-728
URL: http://jira.jboss.com/jira/browse/JBREM-728
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.Alpha7
Reporter: Thomas Diesler
Assigned To: Tom Elrod
JAXWS needs access to the HTTP response headers
/**
* Standard property: HTTP response headers.
* <p>Type: java.util.Map<java.lang.String, java.util.List<java.lang.String>>
*/
public static final String HTTP_RESPONSE_HEADERS = "javax.xml.ws.http.response.headers";
Currently remoting copies these headers to the metadata and I can access them doing a little guess work like this
// Get the HTTP response headers
Map<String, List> headers = new HashMap<String, List>();
for (Map.Entry en : msgContext.entrySet())
{
if (en.getKey() instanceof String && en.getValue() instanceof List)
headers.put((String)en.getKey(), (List)en.getValue());
}
msgContext.put(MessageContext.HTTP_RESPONSE_HEADERS, headers);
I suggest remoting copies the concept of accessing the headers through a single property
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBAOP-305) annotations not found for non-generic implementations of generic interface methods
by Havoc Pennington (JIRA)
annotations not found for non-generic implementations of generic interface methods
----------------------------------------------------------------------------------
Key: JBAOP-305
URL: http://jira.jboss.com/jira/browse/JBAOP-305
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Havoc Pennington
I'm not sure if this is an AOP problem or a how-jboss-is-using-AOP-on-EJB3-session-beans problem, but I'll file it here to start.
The original issue is TransactionAttribute(NEVER) being ignored on certain session bean methods, the test case / details on that are in this list post:
http://groups.google.com/group/mugshot/browse_thread/thread/bc43e0dd34c8c...
I made an AOP test case that either shows an AOP problem or shows a way jboss could easily misuse AOP.
In the AOP test case, If there is an interface Foo<T> with method frobate(T t), then you look that up in AOP as resolveAnnotation("frobate", new Class[] { Object.class })
But if you implement that interface ("class FooImpl implements Foo<Double>") then you have to look that up in AOP as
resolveAnnotation("frobate", new Class[] { Double.class }) - looking it up with the erasure (Object.class arg) will not work, it returns null for the annotation.
So if someone were iterating over methods in the interface, looking each one up on the implementing class, they would not get the annotation for any generic methods in the interface implemented in the class.
The case that's going wrong in EJB3 is a little bit more complicated, so maybe there is some attempt at handling this that isn't catching all the cases.
It looks like further investigation requires messing with jboss TxInterceptor etc. itself, which is a little bit more than I think I can bite off, but hopefully this info is a helpful start.
Thanks
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBAS-3423) Fix org.jboss.test.cmp2.commerce.CompleteUnitTestCase in HEAD
by Anil Saldhana (JIRA)
Fix org.jboss.test.cmp2.commerce.CompleteUnitTestCase in HEAD
-------------------------------------------------------------
Key: JBAS-3423
URL: http://jira.jboss.com/jira/browse/JBAS-3423
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: CMP service
Reporter: Anil Saldhana
Assigned To: Alexey Loubyansky
Fix For: JBossAS-5.0.0.Beta
Could you please have a look at why the tests "testJBossQL, testEJBQL" are failing?
==========================================================================================
Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id)
junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id)
at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:173)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:39)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:168)
at org.jboss.ejb.plugins.SecurityAuthorizationInterceptor.invoke(SecurityAuthorizationInterceptor.java:105)
at org.jboss.ejb.plugins.JaasAuthenticationInterceptor.invoke(JaasAuthenticationInterceptor.java:146)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:646)
at org.jboss.ejb.Container.invoke(Container.java:974)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
=========================================================================================
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBCACHE-923) Aquired node lock never released after transaction timeout
by Jacek Halat (JIRA)
Aquired node lock never released after transaction timeout
----------------------------------------------------------
Key: JBCACHE-923
URL: http://jira.jboss.com/jira/browse/JBCACHE-923
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.0.SP1
Environment: Windows XP, Weblogic 9.1
Reporter: Jacek Halat
Assigned To: Ben Wang
Priority: Critical
Under weblogic 9.1 (and probably earlier version too, not tested) in some situations locks aquired on nodes are never released. Only way to release locks is stop and start again treecache.
On WebLogic the rollback after a tx timeout is handled in a separate thread (and all registered transaction synchronization handlers are invoked in separated thread! In treecache information about InvocationContext (GlobalTransaction, Transaction etc) is stored in ThreadLocal. In this situation SynchronizationHandler is scrubbing NOT correct invocationContext with information about currend rolled-back transaction, but new created empty invocationContext !!!! Informations from TransactionTable are correctly removed, because mapping of transactions is not stored in ThreadLocal variable.
This caused unexpected effects:
Information about GlobalTransaction is not cleared and when in main thread TransactionTimedOutException is catched and put/get operations without explicity created transaction are invoked, TreeCache is trying aquire RL/WL on node and caller is set to non-exist and cleared GlobalTransaction. Lock is aquired but not added to LockTable! (and not released).
>From now every access to locked node failed, because RL/WL can't be aquired in 10 secs. Only way to get system working is stop and start again TreeCache.
2007-01-04 10:13:42,092 DEBUG - calling aftercompletion for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - Running rollback phase
2007-01-04 10:13:42,092 DEBUG - running rollback for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - PessimisticLockInterceptor invoked for method rollback(GlobalTransaction:<192.168.141.1:2100>:1)
2007-01-04 10:13:42,092 DEBUG - called to rollback cache with GlobalTransaction=GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - _remove(GlobalTransaction:<192.168.141.1:2100>:1, "/NODEA/NODEB", systemProperty)
2007-01-04 10:13:42,092 DEBUG - _remove(GlobalTransaction:<192.168.141.1:2100>:1, "/NODEA/NODEB")
2007-01-04 10:13:42,092 DEBUG - removed child NODEB
2007-01-04 10:13:42,092 DEBUG - releasing lock for /NODEA/NODEB (<unlocked>)
2007-01-04 10:13:42,092 DEBUG - releasing lock for /NODEA (read owners=[GlobalTransaction:<192.168.141.1:2100>:1])
2007-01-04 10:13:42,092 DEBUG - removing local transaction Name=FooManager.foo,Xid=BEA1-00068143BD8A02E8BAA1(4771853),Status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 20 seconds
BEA1-00068143BD8A02E8BAA1],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=30,seconds left=20,activeThread=Thread[Timer-5,5,Pooled Threads],XAServerResourceInfo[dataSource]=(ServerResourceInfo[dataSource]=(state=rolledback,assigned=AdminServer),xar=dataSource,re-Registered = false),SCInfo[sample_domain+AdminServer]=(state=rolledback),properties=({weblogic.transaction.name=FooManager.foo}),local properties=({weblogic.jdbc.jta.dataSource=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+10.1.1.218:9002+sample_domain+admin+, XAResources={dataSource, WLStore_sample_domain__WLS_AdminServer},NonXAResources={})],CoordinatorURL=AdminServer+10.1.1.218:9002+sample_domain+admin+) and global transaction GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - bypassed locking as method rollback() doesn't require locking
2007-01-04 10:13:42,092 DEBUG - Suppressing invocation of method rollback(GlobalTransaction:<192.168.141.1:2100>:1) on cache.
2007-01-04 10:13:42,092 DEBUG - Attempting to release locks on current thread. Lock table is {}
2007-01-04 10:13:42,092 DEBUG - Finished local commit/rollback method for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - Finished rollback phase
(...)
2007-01-04 10:14:12,302 DEBUG - Non-tx and non crud meth
2007-01-04 10:14:37,310 DEBUG - (192.168.141.1:2100) call on method [_get(/NODEC, NODE_VALUE, true)]
2007-01-04 10:14:37,310 DEBUG - PessimisticLockInterceptor invoked for method _get(/NODEC, NODE_VALUE, true)
2007-01-04 10:14:37,310 DEBUG - Attempting to lock node /NODEC for owner GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:14:37,310 DEBUG - acquiring RL: fqn=/NODEC, caller=GlobalTransaction:<192.168.141.1:2100>:1, lock=<unlocked>
2007-01-04 10:14:37,310 DEBUG - acquired RL: fqn=/NODEC, caller=GlobalTransaction:<192.168.141.1:2100>:1, lock=read owners=[GlobalTransaction:<192.168.141.1:2100>:1]
2007-01-04 10:14:37,310 ERROR - transaction entry not found for (gtx=GlobalTransaction:<192.168.141.1:2100>:1)
2007-01-04 10:14:37,310 DEBUG - Invoking method _get(/NODEC, NODE_VALUE, true) on cache.
2007-01-04 10:14:37,310 DEBUG - _get("/NODEC", NODE_VALUE, "true")
2007-01-04 10:14:37,310 DEBUG - Attempting to release locks on current thread. Lock table is {}
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBAS-4152) Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
by Vivek Lakshmanan (JIRA)
Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
-------------------------------------------------------------------------------------------------------------------
Key: JBAS-4152
URL: http://jira.jboss.com/jira/browse/JBAS-4152
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.0.5.CR1
Environment: BEA JRockit 1.5.0_08 on Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Reporter: Vivek Lakshmanan
Assigned To: Scott M Stark
On upgrade of HSQLDB from 1.8.0.2 to 1.8.0.7 the following testcase seems to consistently fail:
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2
Error: FKey cmr2_id is indexed
The test reports say:
junit.framework.AssertionFailedError: Error: FKey cmr2_id is indexed
at org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase.testCMRmn2(IdxAndUsersqlUnitTestCase.java:190)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
The sourcefile for the test says:
/*
* Look for indices on the m:n mapping table
* This is for hsql a strange case, at indices are put there
* anyway, but it has been told that other databases don't do
* it by themselves, so we check if the creation succeeds.
*/
Would like to get an experts opinion on it
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBAS-4433) Row-locking enhancement for loading bean outside of a transaction
by Scott Marlow (JIRA)
Row-locking enhancement for loading bean outside of a transaction
-----------------------------------------------------------------
Key: JBAS-4433
URL: http://jira.jboss.com/jira/browse/JBAS-4433
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta1, JBossAS-4.0.4.GA
Reporter: Scott Marlow
Assigned To: Scott Marlow
Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.1.CR1
JBoss recommends that applications should use transactions (see user forum reference). However, there are certain types of applications that use "transaction-type=NotSupported" and load data without a transaction.
If the bean is being loaded without a transaction, treat the operation as if row-locking==false.
--
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
18 years, 8 months