[JBoss JIRA] Assigned: (JBAS-2889) AppClientUnitTestCase doesn't clean up if it fails
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2889?page=all ]
Dimitris Andreadis reassigned JBAS-2889:
----------------------------------------
Assignee: Shelly McGowan
If you have time to look at.
> AppClientUnitTestCase doesn't clean up if it fails
> --------------------------------------------------
>
> Key: JBAS-2889
> URL: http://jira.jboss.com/jira/browse/JBAS-2889
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Ryan Campbell
> Assigned To: Shelly McGowan
> Fix For: JBossAS-5.0.0.Beta3
>
>
> The org.jboss.test.client.test.AppClientUnitTestCase deploys a bunch of services but fails to clean them.
> If you run a CMP test before the AppClientUnitTest, it passes, but if you run it immediately after, it fails:
> > ./build.sh one-test -Dtest=org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> one-test:
> [junit] Running org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 6.04 sec
> > ./build.sh one-test -Dtest=org.jboss.test.client.test.AppClientUnitTestCase
> [junit] Running org.jboss.test.client.test.AppClientUnitTestCase
> [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.149 sec
> [junit] Test org.jboss.test.client.test.AppClientUnitTestCase FAILED
> > ./build.sh one-test -Dtest=org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Running org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Tests run: 19, Failures: 0, Errors: 19, Time elapsed: 1.05 sec
> [junit] Test org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase FAILED
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBFORUMS-247) forums and commons-fileupload-1.1
by Luca Stancapiano (JIRA)
forums and commons-fileupload-1.1
---------------------------------
Key: JBFORUMS-247
URL: http://jira.jboss.com/jira/browse/JBFORUMS-247
Project: JBoss Forums
Issue Type: Bug
Environment: JBoss as from http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_CP06,
JBoss Portal from http://anonsvn.jboss.org/repos/portal/trunk since 9 july 2007,
JBoss Forums from http://anonsvn.jboss.org/repos/labs/labs/jbossforums/branches/forums101P26 since 9 july 2007
Reporter: Luca Stancapiano
Assigned To: Ryszard Kozmik
Attachments: ForumsJSFPortlet.java
hi....I send you to see http://jira.jboss.com/jira/browse/JBPORTAL-1550 by me reported. It is the same problem......if you post messages using 'multipart/form-data' through commons-fileupload libs, you miss character encoding because there is a incompatibility between tomcat 5.5.23 and fileupload 1.1, and then if you try to send messages with characters as à, è, ì, ò, ù you 'll get problems of decoding with strange characters of response. Also for Forums I send you a patch. I substituted getString() method of org.apache.commons.fileupload.disk.DiskFileItem class with getString( String ...) method, passing inside the character encoding of the request:
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 560
I write :
newParams.put(item.getFieldName(), new String[]{item.getString(req.getCharacterEncoding())});
instead of:
newParams.put(item.getFieldName(), new String[]{item.getString()});
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 564
I write:
String value = item.getString(req.getCharacterEncoding());
instead of:
String value = item.getString();
--
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
17 years, 1 month
[JBoss JIRA] Created: (JGRP-535) NAKACK: release lock when message is delivered
by Bela Ban (JIRA)
NAKACK: release lock when message is delivered
----------------------------------------------
Key: JGRP-535
URL: http://jira.jboss.com/jira/browse/JGRP-535
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
When NAKACK receives a message from C, it gets the NakReceiverWindow for C and acquires a lock on C, and then passes up the message. When the call returns, the lock is received (it is actually currently a synchronized(win) statement).
The reason is that this is needed to deliver all messages from C in the order in which they were sent.
The issue is that, while a message from C is delivered, all other threads are blocked on the lock for C's NakReceiverWindow. Especially the case when an up() method calls down() before returning, and down() blocks, this increases the duration during which the lock is kept. Example:
- Message from C acquires a lock on C's NakReceiverWindow
- Message is passed up
- The application gets the receive() callback
- *Inside* the receive(), the application calls Channel.send() which results in a down()
- Only when the down() placed the message on the network and returned will the up() method unwind its stack and return
--> Result: we kept a lock on C's NRW for much longer than we needed to. The lock should be kept until C's message has been *DELIVERED*, but not until the down() method returns !
--> If FC.down() blocks for credits, this makes it even worse !
SOLUTION:
- Investigate associating the lock acquired in NAKACK for C's NakReceiverWindow with the thread local. When the message is delivered (semantics ?), release the lock, this is sooner than when the up() method returns in NAKACK.
- This could also be done for example in STABLE.handleRegularMessage(), where we send the message up first, the release the lock and *only then* multicast the STABLE message
Investigate UNICAST as well.
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBMICROCONT-155) java.io.IOException: No context factory for vfsfile
by Scott M Stark (JIRA)
java.io.IOException: No context factory for vfsfile
---------------------------------------------------
Key: JBMICROCONT-155
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-155
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
The following org.jboss.test.virtual.test.FileVFSUnitTestCase:
/**
* Test that one can go from a file uri to VirtualFile and obtain the
* same VirtualFile using VirtualFile vfsfile uri
* @throws Exception
*/
public void testVFSFileURIFactory()
throws Exception
{
URL rootURL = getClass().getProtectionDomain().getCodeSource().getLocation();
VFS rootVFS0 = VFS.getVFS(rootURL.toURI());
VirtualFile root0 = rootVFS0.getRoot();
VFS rootVFS1 = VFS.getVFS(root0.toURI());
VirtualFile root1 = rootVFS1.getRoot();
assertEquals(root0, root1);
}
fails with:
java.io.IOException: No context factory for vfsfile:/home/svn/JBossMC/vfs/target/test-classes/
at org.jboss.virtual.VFS.getVFS(VFS.java:83)
at org.jboss.test.virtual.test.FileVFSUnitTestCase.testVFSFileURIFactory(FileVFSUnitTestCase.java:104)
The VFSContextFactory uri mappings need to be updated to include the vfs* forms of the known handlers.
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBMICROCONT-205) Accessing content of vfsfile url fails
by Scott M Stark (JIRA)
Accessing content of vfsfile url fails
--------------------------------------
Key: JBMICROCONT-205
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-205
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Reporter: Scott M Stark
Fix For: JBossMC-2.0.0.Beta4
When trying to create a ManagedProperty for a URL type with a vfsfile: url value, the content fails to be obtained:
Caused by: java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1167)
at java.net.URLConnection.getContent(URLConnection.java:683)
at java.net.URL.getContent(URL.java:1021)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:172)
at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:238)
at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:371)
... 23 more
VirtualFileURLConnection should be overriding the getContent method to return the VirtualFile I suppose.
--
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
17 years, 1 month