[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/test TestWebIntegration.java
User: starksm
Date: 01/10/05 00:23:05
Modified:src/main/org/jboss/test/web/test Tag: Branch_2_4
TestWebIntegration.java
Log:
Remove the ejb interfaces from the web war.
Updated the access failures tests to assert that the error code was
a 401 so that a client browser would attempt a login.
Revision ChangesPath
No revision
No revision
1.7.2.5 +32 -3
jbosstest/src/main/org/jboss/test/web/test/Attic/TestWebIntegration.java
Index: TestWebIntegration.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/test/Attic/TestWebIntegration.java,v
retrieving revision 1.7.2.4
retrieving revision 1.7.2.5
diff -u -r1.7.2.4 -r1.7.2.5
--- TestWebIntegration.java 2001/09/14 17:56:01 1.7.2.4
+++ TestWebIntegration.java 2001/10/05 07:23:05 1.7.2.5
@@ -25,14 +25,15 @@
The secure access tests require a user named 'jduke' with a password of 'theduke'
with a role of 'AuthorizedUser' in the servlet container.
- @author [EMAIL PROTECTED]
- @version $Revision: 1.7.2.4 $
+ @author [EMAIL PROTECTED]
+ @version $Revision: 1.7.2.5 $
*/
public class TestWebIntegration extends TestCase
{
private static boolean setUp;
private static boolean webServerAvailable;
private static String baseURL;
+ private static Integer port;
public TestWebIntegration(String name)
{
@@ -48,7 +49,7 @@
return;
setUp = true;
- Integer port = Integer.getInteger("web.port", 8080);
+ port = Integer.getInteger("web.port", 8080);
baseURL = "http://jduke:theduke@localhost:"; + port + '/';
try
{
@@ -163,6 +164,29 @@
URL url = new URL(baseURL+"jbosstest/restricted/SecureServlet");
accessURL(url);
}
+ /** Access the http://localhost/jbosstest/restricted/SecureServlet
+*/
+ public void testSecureServletWithBadPass() throws Exception
+ {
+ if( webServerAvailable == false )
+ return;
+
+ String baseURL = "http://jduke:badpass@localhost:"; + port + '/';
+ URL url = new URL(baseURL+"jbosstest/restricted/SecureServlet");
+ accessURL(url, true);
+ }
+ /** Access the http://localhost/jbosstest/restricted/SecureServlet
+*/
+ public void testSecureServletWithNoLogin() throws Exception
+ {
+ if( webServerAvailable == false )
+ return;
+
+ String baseURL = "http://localhost:"; + port + '/';
+ URL url = new URL(baseURL+"jbosstest/restricted/SecureServlet");
+ accessURL(url, true);
+ }
+
/** Access the http://localhost/jbosstest/restricted/SecureEJBAccess
*/
public void testSecureEJBAccess() throws Exception
@@ -213,6 +237,11 @@
System.out.println(content);
if( shouldFail == false )
fail("Access to: "+url+" failed with responseCode="+responseCode);
+else
+{
+ // Validate that we are seeing a 401 error
+ assert("Error code 401, actual="+responseCode, responseCode ==
HttpURLConnection.HTTP_UNAUTHORIZED);
+}
}
}
catch(IOException e)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-web.xml
User: starksm Date: 01/10/05 00:23:04 Modified:src/build/subprojects Tag: Branch_2_4 build-web.xml Log: Remove the ejb interfaces from the web war. Updated the access failures tests to assert that the error code was a 401 so that a client browser would attempt a login. Revision ChangesPath No revision No revision 1.5.2.3 +0 -1 jbosstest/src/build/subprojects/Attic/build-web.xml Index: build-web.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/subprojects/Attic/build-web.xml,v retrieving revision 1.5.2.2 retrieving revision 1.5.2.3 diff -u -r1.5.2.2 -r1.5.2.3 --- build-web.xml 2001/09/09 07:34:51 1.5.2.2 +++ build-web.xml 2001/10/05 07:23:03 1.5.2.3 @@ -55,7 +55,6 @@ - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] unsubscribe
>>> [EMAIL PROTECTED] 11/09/01 07:30:19 >>>these now use the new build system stuff from jboss-all.I did not change how the jboss-website outputs, so there is still nothingever put into the build/output directory.You will need to checkout jboss-docs again, since its CVSROOT/modulesmapping has changed (it now has its own build module, rather that using theversin from jboss-all).Let me know if there are issues. I am going to try and update jboss-mq, butI don't know if I can finish it tonight (getting tired). Also, the pathproblem for docbook still needs to be sorted out.Now that we can execute any task in the config secion, we simply need tofigure out what the correct config for is.--jason___Jboss-development mailing list[EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-468195 ] The authentication logic is flawed
Bugs item #468195, was opened at 2001-10-05 00:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=468195&group_id=22866 Category: CatalinaBundle Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: The authentication logic is flawed Initial Comment: The org.jboss.web.catalina.security.JBossSecurityMgrRealm is not setting the principal it returns to null when the authentication fails. This is not being detected by the unit tests because they are only looking for a non-200 HTTP status code. The test needs to check for a 401 Unauthorized error code when failure is expected. The current failure scenario is that an invalid user or null user is authenticated due to the non-null principal being returned, but the user is not authorized to see anything. Thus, an HTTP error code of 403 Forbidden is returned and a browser client does not give the user a chance to enter login information. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=468195&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 126 Successful tests: 107 Errors:9 Failures: 10 [time of test: 5 October 2001 6:26 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 115 Successful tests: 101 Errors:12 Failures: 2 [time of test: 5 October 2001 5:16 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-468161 ] Errors in example build.xml file?
Bugs item #468161, was opened at 2001-10-04 20:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=468161&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in example build.xml file? Initial Comment: I think I have found a couple of errors in the examples/build/build.xml file. Please forgive me if these represent my misunderstanding rather being actual errors or if they have already been reported. (I couldn't see any sign of them when I searched though.) Starting with the most trivial ones: The numbering for the chapters on CMP, JAWS and JMS should be 5,6, 8 respectively. Secondly, the line: should have only one } not }} after JBOSS_DIST. The change made no apparent difference to the operation, for me. The final and more serious error for me was in the "Chapter 4 - CMP" section. The build-client.xml file is called from this section for three of the targets, but when I initially tried it, it failed. The reason being that the "client" property had not been set in build.xml. I changed the code to the following (but I don't know much about XML, so am not sure whether it is the 'proper' way to do it.): After adding the three lines shown in italics the code worked and I was able to successfully run the upload and list clients. I hope this is of help. Cheers Roger -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=468161&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] Reply-To list is not coming back
Do you know much about news? inn in particular? --jason On Fri, 5 Oct 2001, Peter Wone wrote: > I have a news server on a backbone. I've offered the use of it before, and > the offer > stands. > - Original Message - > From: "Scott M Stark" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Friday, October 05, 2001 5:53 AM > Subject: Re: [JBoss-dev] Re: [JBoss-user] Reply-To list is not coming back > > > > Yes. Its an old debate with equal advocacy on both sides of the issue. > > SF claims they will have a per-user option to filter out the duplicates > > in a future version of mailman in 2-3+ months. > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 126 Successful tests: 107 Errors:9 Failures: 10 [time of test: 5 October 2001 4:6 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 115 Successful tests: 100 Errors:12 Failures: 3 [time of test: 5 October 2001 3:16 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums/src/web/forums footer.jsp header.jsp
User: user57
Date: 01/10/04 18:01:19
Modified:src/web/forums footer.jsp header.jsp
Log:
o updated footer/header
Revision ChangesPath
1.2 +2 -0 website-forums/src/web/forums/footer.jsp
Index: footer.jsp
===
RCS file: /cvsroot/jboss/website-forums/src/web/forums/footer.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- footer.jsp2001/10/04 02:09:29 1.1
+++ footer.jsp2001/10/05 01:01:19 1.2
@@ -10,6 +10,8 @@
|
Log-In
|
+FAQ/Help
+|
Search
1.2 +3 -4 website-forums/src/web/forums/header.jsp
Index: header.jsp
===
RCS file: /cvsroot/jboss/website-forums/src/web/forums/header.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- header.jsp2001/10/04 02:09:29 1.1
+++ header.jsp2001/10/05 01:01:19 1.2
@@ -2,8 +2,8 @@
<%
/**
* $RCSfile: header.jsp,v $
- * $Revision: 1.1 $
- * $Date: 2001/10/04 02:09:29 $
+ * $Revision: 1.2 $
+ * $Date: 2001/10/05 01:01:19 $
*/
%>
@@ -31,11 +31,10 @@
font-weight : bold;
text-decoration : none;
}
-A: hover {
+A:hover {
text-decoration : underline;
}
-
"
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums/src/metadata jive-web.xml
User: user57 Date: 01/10/04 17:58:40 Modified:src/metadata jive-web.xml Log: o patched jive.jar to hopefully fix the NPE's Revision ChangesPath 1.3 +5 -1 website-forums/src/metadata/jive-web.xml Index: jive-web.xml === RCS file: /cvsroot/jboss/website-forums/src/metadata/jive-web.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jive-web.xml 2001/10/02 22:30:44 1.2 +++ jive-web.xml 2001/10/05 00:58:40 1.3 @@ -1,7 +1,7 @@ - + JBoss Jive Forums WebApp @@ -16,5 +16,9 @@ com.jivesoftware.forum.util.JiveServlet + + + index.jsp + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums/src/lib jive.jar
User: user57 Date: 01/10/04 17:58:40 Modified:src/lib jive.jar Log: o patched jive.jar to hopefully fix the NPE's Revision ChangesPath 1.4 +3354 -3301website-forums/src/lib/jive.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/jvm JVMServerIL.java JVMClientIL.java
User: dmaplesden
Date: 01/10/04 16:26:45
Modified:src/main/org/jboss/mq/il/jvm JVMServerIL.java
JVMClientIL.java
Log:
Fix for a subtle bug. If messages are not copied on delivery to client and client
then modifies the message and does a rollback, the modified message is restored
instead of the original.
Revision ChangesPath
1.4 +6 -2 jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerIL.java
Index: JVMServerIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerIL.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JVMServerIL.java 2001/09/26 05:02:28 1.3
+++ JVMServerIL.java 2001/10/04 23:26:45 1.4
@@ -27,7 +27,7 @@
*
* @authorHiram Chirino ([EMAIL PROTECTED])
* @authorNorbert Lataille ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
* @created August 16, 2001
*/
public class JVMServerIL implements org.jboss.mq.il.ServerIL
@@ -235,7 +235,11 @@
public SpyMessage receive(ConnectionToken dc, int subscriberId, long wait)
throws Exception
{
- return server.receive(dc, subscriberId, wait);
+ SpyMessage message = server.receive(dc, subscriberId, wait);
+ //copy message to avoid server side problems with persisted message if
message is edited client side.
+ if(message != null)
+ message = message.myClone();
+ return message;
}
/**
1.4 +8 -1 jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java
Index: JVMClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JVMClientIL.java 2001/09/26 05:02:28 1.3
+++ JVMClientIL.java 2001/10/04 23:26:45 1.4
@@ -19,7 +19,7 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
* @created August 16, 2001
*/
public class JVMClientIL implements ClientIL
@@ -80,6 +80,13 @@
{
throw new IllegalStateException("The client IL is stopped");
}
+
+ //copy messages to avoid server side problems when messages are edited client
side.
+ for (int i = 0; i < messages.length; i++)
+ {
+ messages[i].message = messages[i].message.myClone();
+ }
+
connection.asynchDeliver(messages);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged PersistenceManager.java
User: dmaplesden
Date: 01/10/04 16:28:28
Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
Log:
Fix a problem with cleaning up data files.
Revision ChangesPath
1.8 +5 -1
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- PersistenceManager.java 2001/09/10 03:26:44 1.7
+++ PersistenceManager.java 2001/10/04 23:28:28 1.8
@@ -32,7 +32,7 @@
* This class manages all persistence related services.
*
* @author David Maplesden ([EMAIL PROTECTED])
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
org.jboss.mq.pm.PersistenceManager, PersistenceManagerMBean
{
@@ -130,6 +130,10 @@
queues.put(key, dest);
SpyTxLog txLog = null;
+ // if called before we have been started there is no need to setup log files
+ if(currentTxLog == null)
+ return;
+
HashMap logs;
synchronized (messageLogs)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyTopicPublisher.java
User: dmaplesden Date: 01/10/04 16:25:12 Modified:src/main/org/jboss/mq SpyTopicPublisher.java Log: No need to copy message in publish Revision ChangesPath 1.3 +2 -5 jbossmq/src/main/org/jboss/mq/SpyTopicPublisher.java Index: SpyTopicPublisher.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTopicPublisher.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- SpyTopicPublisher.java2001/08/17 03:04:01 1.2 +++ SpyTopicPublisher.java2001/10/04 23:25:11 1.3 @@ -20,7 +20,7 @@ * @author Norbert Lataille ([EMAIL PROTECTED]) * @author Hiram Chirino ([EMAIL PROTECTED]) * @createdAugust 16, 2001 - * @version$Revision: 1.2 $ + * @version$Revision: 1.3 $ */ public class SpyTopicPublisher extends SpyMessageProducer @@ -99,11 +99,8 @@ message = m; } - //Clone the message so we can make the outbound message read only - SpyMessage clone = ( ( SpyMessage )message ).myClone(); - clone.setReadOnlyMode(); //Send the message - mySession.sendMessage( clone ); + mySession.sendMessage( ( SpyMessage )message ); } } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
You can document it as a bug on Sun. If it really is, they can confirm it.
Only take care of NOT SPEAKING ABOUT any imaginary patch :)
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]En nombre de Jung
> , Dr. Christoph
> Enviado el: jueves, 04 de octubre de 2001 9:06
> Para: Jboss-Development (E-Mail)
> Asunto: AW: [JBoss-dev] The rabbit has a bug in its pelt:
> org.jboss.system.URLClassLoader
>
>
> Hi Ole & others,
>
> IMHO, your nice patch has partly solved the problem, i.e., the issue that
> Sacha was noticing with the patch.jar NOT;-) applied. And even without
> patch.jar, it should have greatly diminished the deadlock
> possibilities ...
> But nevertheless, I could imagine a scenario, where a synchronized
> java.lang.ClassLoader.loadClassInternal() would lead to hang-ups:
>
> ServiceLibrary contains two classloaders CL1 and CL2.
>
> CL1 has class C1 and needs to loadClassInternal("C2") in Thread T1.
> CL2 has Class C2 and needs to loadClassInternal("C1") in Thread T2.
>
> Then there is certainly a constellation where both threads concurrently
> enter the classloaders, obtaining the respective CL locks and the
> ServiceLibrary code mutually dispatching them will block.
>
> Is that a valid scenario?
>
> CGJ
>
> -Ursprüngliche Nachricht-
> Von: Ole Husgaard [mailto:[EMAIL PROTECTED]]
> Gesendet: Dienstag, 2. Oktober 2001 20:30
> An: [EMAIL PROTECTED]
> Betreff: Re: [JBoss-dev] The rabbit has a bug in its pelt:
> org.jboss.system.URLClassLoader
>
>
> "Jung , Dr. Christoph" wrote:
> >
> > I must correct myself! We have a principle problem, unfortunately, for
> which
> > I do not
> > have an immediate answer right now:
> >
> > Actually, instead of synchronized(classLoaders) in
> ServiceLibraries, there
> > would be the need
> > to *atomically* synchronize on all instances of the set in order not to
> > interfere with the ClassLoader.loadClassInternally() calls.
> >
> > But this is not possible with the Java synchronization mechanism, AFAIK.
>
> Please forgive me if I am wrong - I'm not very familiar
> with this code.
>
> But isn't the only reason for synchronizing on classLoaders
> that there would be problems if another thread tries to
> add or remove classloaders while the Set is traversed?
>
> If this is the case, couldn't we avoid synchronizing on it
> by making ServiceLibraries.addClassLoader() and
> removeClassloader() create an entire new Set?
>
> Of course, then these methods would have to be synchronized,
> and we would probably also have to synchronize on the
> instance variables classes, resources, clToClassSetMap and
> clToResourceSetMap, but these locks would not be held
> while ClassLoader.loadClassInternally() is called.
>
>
> Best Regards,
>
> Ole Husgaard.
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] Reply-To list is not coming back
Yeah, but the sender can remove them (except the list) before sending. Andy - Original Message - From: "danch" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, October 04, 2001 12:22 PM Subject: [JBoss-dev] Re: [JBoss-user] Reply-To list is not coming back > ...so anybody who posts can expect to get everything back twice (or > three times, in this case) > > Scott M Stark wrote: > > > Sourceforge has decided that they are not going to support the Reply-To > > feature > > that only includes the list. Their reasoning can be found here: > > https://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1 > > > > You need to use your mail client reply-to-all feature to address replies to > > the > > list. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why do init, start, etc have to be done per deployment unit? (rh/3.0)
The reply to all "feature" is still biting... Thanks! Will this work? (first conceptually, then how much change would it take) I take it there are several queues for each persistence manager. A queue has a dependency (mbean ref) to a persistence manager. If the queue gets deployed first, it waits till the persistence manager has had start() called on it. The persistence manager does whatever queue- independent startup stuff it needs to do in init() and start() After the persistence manager starts, (or anytime later if a queue happens to get started second), the queue gets init and start called: in one of these it asks the persistence manager to give it back its persistent messages. Since it depends on the mbean-ref to the persistence manager, the persistence manager will be there. The main difference between this and what happens now is that the queues are restored one at a time rather than all at once. Is there some structural reason all the queues need to be restored at once? To my uneducated mind I would think there might be some advantages to being able to restore them one at a time independently. Many thanks for the example david jencks On 2001.10.04 13:43:19 -0400 Hiram Chirino wrote: > > The reason the David M. did that is due to the way that JBossMQ starts up > > it's Queues... The startup sequence is something along the lines of: > > 1. MQ Persistence Manager inits > 2. Queue inits = registers itself with the Persistence Manager > 3. MQ Persistence Manager starts() = restores persitence messages to the > registered queues. > 4. Queues starts() = queues bind to JNDI. > > Maybe this startup sequence should not be used. But the thing we need is > a > signal to the Persistence Manager to restore messages to all the queues > that > have registered. > > >From: David Jencks <[EMAIL PROTECTED]> > >To: jboss-dev <[EMAIL PROTECTED]> > >Subject: [JBoss-dev] Why do init, start, etc have to be done per > deployment > >unit? (rh/3.0) > >Date: Thu, 4 Oct 2001 12:31:53 -0400 > > > >Hi, > > > >When Marc put in the new classloading stuff for 3.0, he had each mbean > >being configured, inited, and started individually (although in the > order > >of the *service.xml file). > > > >David Maplesden added some package depending on mbean dependency control > >and changed the config/init/start to do each step to the entire > deployment > >unit (as it is in 2.4). > > > >I am in the process of making the dependencies operate on an mbean to > mbean > >level by means of mbean references and would like to change this process > >back to config/init/start mbean by mbean. > > > >Given mbean to mbean dependencies, will this cause any problems? Please > >give a specific example. I didn't catch David M's example when he made > the > >first change. > > > > > >Heres an example of the mbean references/ dependencies at work: > > > > > >> name="test:name=TestMBeanA"> > > >name="Mbeanb">test:name=TestMBeanB > > > > > >test:name=TestMBeanB > > > >>JBOSS-SYSTEM:service=TransactionManager > > > > > > > > > > > >> name="test:name=TestMBeanB"> > > test:name=TestMBeanA > > > > > > > > > >Suggestions for better element names will be appreciated. > > > >I am planning to use these two new elements in the mbean element because > >they have such different semantics than the existing attribute element. > > > >Thanks! > > > >David Jencks > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > _ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why do init, start, etc have to be done per deployment unit? (rh/3.0)
Hi, When Marc put in the new classloading stuff for 3.0, he had each mbean being configured, inited, and started individually (although in the order of the *service.xml file). David Maplesden added some package depending on mbean dependency control and changed the config/init/start to do each step to the entire deployment unit (as it is in 2.4). I am in the process of making the dependencies operate on an mbean to mbean level by means of mbean references and would like to change this process back to config/init/start mbean by mbean. Given mbean to mbean dependencies, will this cause any problems? Please give a specific example. I didn't catch David M's example when he made the first change. Heres an example of the mbean references/ dependencies at work: test:name=TestMBeanB test:name=TestMBeanB JBOSS-SYSTEM:service=TransactionManager test:name=TestMBeanA Suggestions for better element names will be appreciated. I am planning to use these two new elements in the mbean element because they have such different semantics than the existing attribute element. Thanks! David Jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBOSS-NET needs solid soldier
Providers are the "last" interceptors (there called handlers) in the Axis invocation chain. They are responsible for mapping a preprocessed Web-Service message-Context to a concrete target logic: Request-Transport --> Intermediate-Handler --> Deserialisation-Handler --> etc --> Provider --> Logic Response-Transport <-- Intermediate-Handler <-- Serialisation-Handler <-- etc <-- Provider <| There are JavaProviders that map invocations to arbitrary Java objects (instantiation, method lookup and call via reflection). I already wrote an MBeanProvider that maps the Web-service description to an invocation on the JMX bus (simply does an invoke with a configurable ObjectName). And there are already EJBProviders that map the service invocation to JNDI lookup and interface-invocation. Since this is identical to the servlet-to-ejb communication, even the in-VM optimisation case should be quite straightforward, once .wsr-deployment is integrated into .ear-deployment. This will hence not interfere with your InvocationHandler&ContainerInvoker&andallthatisbehind changes! Of course, we could think of a special JBossEJBProvider that is able to immediately connect to the JMX bus, hence operates on the same level than ContainerInvoker. But currently I cannot see much advantage except performance, maybe. CGJ -Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 4. Oktober 2001 14:32 An: Jung , Dr. Christoph Cc: Jboss-Development Betreff: Re: [JBoss-dev] JBOSS-NET needs solid soldier What does the EJBProvider do? Is it related to the invoker chains set up by ContainerFactory? I ask because I am working on setting up the invokers as independent (unlinked) mbeans with linking info carried in the MI, as discussed in the thread started by Rickard. Is this related or in conflict in any way to what you are doing here? Thanks david jencks On 2001.10.04 04:19:43 -0400 "Jung , Dr. Christoph" wrote: > Thx Marc for the advertisement, > > as soon as the EJBProvider is working (targetted an integrated .wsr C > .ear > example by the end of this week), > I will make up a nice web-page, some doco and set up sourceforge things > (maybe Jason can help me with that), and send a proper announcement of > the > project, ok? > > The first steps are certainly to have some testers (Roberto, your first > assignment? BTW: Are you sitting at Siemens, Berlin or Munich?) and to > derive requirements to the project from that. > > Best, > CGJ > > -Ursprüngliche Nachricht- > >Von: marc fleury [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 20:32 > >An: Jboss-Development@Lists. Sourceforge. Net > >Betreff: [JBoss-dev] JBOSS-NET needs solid soldier > > -Ursprüngliche Nachricht- > >Von: Jason Dillon [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 22:11 > >An: marc fleury > >Cc: Jboss-Development@Lists. Sourceforge. Net > >Betreff: Re: [JBoss-dev] JBOSS-NET needs solid soldier > > -Ursprüngliche Nachricht- > >Von: Roberto Leong [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 22:34 > >An: '[EMAIL PROTECTED]' > >Betreff: RE: [JBoss-dev] JBOSS-NET needs solid soldier > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS-NET needs solid soldier
What does the EJBProvider do? Is it related to the invoker chains set up by ContainerFactory? I ask because I am working on setting up the invokers as independent (unlinked) mbeans with linking info carried in the MI, as discussed in the thread started by Rickard. Is this related or in conflict in any way to what you are doing here? Thanks david jencks On 2001.10.04 04:19:43 -0400 "Jung , Dr. Christoph" wrote: > Thx Marc for the advertisement, > > as soon as the EJBProvider is working (targetted an integrated .wsr C > .ear > example by the end of this week), > I will make up a nice web-page, some doco and set up sourceforge things > (maybe Jason can help me with that), and send a proper announcement of > the > project, ok? > > The first steps are certainly to have some testers (Roberto, your first > assignment? BTW: Are you sitting at Siemens, Berlin or Munich?) and to > derive requirements to the project from that. > > Best, > CGJ > > -Ursprüngliche Nachricht- > >Von: marc fleury [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 20:32 > >An: Jboss-Development@Lists. Sourceforge. Net > >Betreff: [JBoss-dev] JBOSS-NET needs solid soldier > > -Ursprüngliche Nachricht- > >Von: Jason Dillon [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 22:11 > >An: marc fleury > >Cc: Jboss-Development@Lists. Sourceforge. Net > >Betreff: Re: [JBoss-dev] JBOSS-NET needs solid soldier > > -Ursprüngliche Nachricht- > >Von: Roberto Leong [mailto:[EMAIL PROTECTED]] > >Gesendet: Mittwoch, 3. Oktober 2001 22:34 > >An: '[EMAIL PROTECTED]' > >Betreff: RE: [JBoss-dev] JBOSS-NET needs solid soldier > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBOSS-NET needs solid soldier
Thx Marc for the advertisement, as soon as the EJBProvider is working (targetted an integrated .wsr C .ear example by the end of this week), I will make up a nice web-page, some doco and set up sourceforge things (maybe Jason can help me with that), and send a proper announcement of the project, ok? The first steps are certainly to have some testers (Roberto, your first assignment? BTW: Are you sitting at Siemens, Berlin or Munich?) and to derive requirements to the project from that. Best, CGJ -Ursprüngliche Nachricht- >Von: marc fleury [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 3. Oktober 2001 20:32 >An: Jboss-Development@Lists. Sourceforge. Net >Betreff: [JBoss-dev] JBOSS-NET needs solid soldier -Ursprüngliche Nachricht- >Von: Jason Dillon [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 3. Oktober 2001 22:11 >An: marc fleury >Cc: Jboss-Development@Lists. Sourceforge. Net >Betreff: Re: [JBoss-dev] JBOSS-NET needs solid soldier -Ursprüngliche Nachricht- >Von: Roberto Leong [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 3. Oktober 2001 22:34 >An: '[EMAIL PROTECTED]' >Betreff: RE: [JBoss-dev] JBOSS-NET needs solid soldier ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Hi Ole & others,
IMHO, your nice patch has partly solved the problem, i.e., the issue that
Sacha was noticing with the patch.jar NOT;-) applied. And even without
patch.jar, it should have greatly diminished the deadlock possibilities ...
But nevertheless, I could imagine a scenario, where a synchronized
java.lang.ClassLoader.loadClassInternal() would lead to hang-ups:
ServiceLibrary contains two classloaders CL1 and CL2.
CL1 has class C1 and needs to loadClassInternal("C2") in Thread T1.
CL2 has Class C2 and needs to loadClassInternal("C1") in Thread T2.
Then there is certainly a constellation where both threads concurrently
enter the classloaders, obtaining the respective CL locks and the
ServiceLibrary code mutually dispatching them will block.
Is that a valid scenario?
CGJ
-Ursprüngliche Nachricht-
Von: Ole Husgaard [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 2. Oktober 2001 20:30
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] The rabbit has a bug in its pelt:
org.jboss.system.URLClassLoader
"Jung , Dr. Christoph" wrote:
>
> I must correct myself! We have a principle problem, unfortunately, for
which
> I do not
> have an immediate answer right now:
>
> Actually, instead of synchronized(classLoaders) in ServiceLibraries, there
> would be the need
> to *atomically* synchronize on all instances of the set in order not to
> interfere with the ClassLoader.loadClassInternally() calls.
>
> But this is not possible with the Java synchronization mechanism, AFAIK.
Please forgive me if I am wrong - I'm not very familiar
with this code.
But isn't the only reason for synchronizing on classLoaders
that there would be problems if another thread tries to
add or remove classloaders while the Set is traversed?
If this is the case, couldn't we avoid synchronizing on it
by making ServiceLibraries.addClassLoader() and
removeClassloader() create an entire new Set?
Of course, then these methods would have to be synchronized,
and we would probably also have to synchronize on the
instance variables classes, resources, clToClassSetMap and
clToResourceSetMap, but these locks would not be held
while ClassLoader.loadClassInternally() is called.
Best Regards,
Ole Husgaard.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] java.lang.ClassLoader misery. Verify this patch!
Hello David,
-Ursprüngliche Nachricht-
>Von: David Jencks [mailto:[EMAIL PROTECTED]]
>Gesendet: Mittwoch, 3. Oktober 2001 21:43
>An: [EMAIL PROTECTED]
>Betreff: Re: [JBoss-dev] java.lang.ClassLoader misery. Verify this
>patch!
>In my (unproven) opinion the problem comes from the loadClass(name,
>resolve) method being synchronized and calling to another object within the
>synchronization. The loadClassInternal being synchronized makes no
>difference here (although I might agree it shouldn't be) since it ends up
>calling the synchronized loadClass anyway.
see my previous mail, I think that its was this time the ServiceLibraries
synchronization behaviour where a (globally) unsynchronized dispatching back
to the caller classloader was introduced for optimisation purposes.
public Class loadClass(String name, boolean resolve, ClassLoader scl)
throws ClassNotFoundException
{
...
// If not start asking around to URL classloaders for it
// who will find it?
URLClassLoader cl = null;
if (scl instanceof URLClassLoader)
{
// First ask the asking classloader chances are the dependent class
is in there
try
{
Here, no sync is done and the scl will obtain a lock on itself
and come back to the ServiceLibrary while immediately linking files
***
foundClass = ((URLClassLoader)scl).loadClassLocally(name,
resolve);
//If we get here we know the scl is the right one
cl = (URLClassLoader)scl;
}
catch (ClassNotFoundException ignored)
{
}
}
Another CL can at the same time enter here and not get the lock
on the scl above! ***
synchronized (classLoaders)
{
Iterator allLoaders = classLoaders.iterator();
while (allLoaders.hasNext() && (foundClass == null))
...
CGJ
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] java.lang.ClassLoader misery. Verify this patch!
My impression from the problemAgain stacktrace is that there was indeed a change in behaviour: Thread1 does call java.lang.ClassLoader.loadClassInternal() [instance CL1, no lock obtained] org.jboss.system.ServiceLibraries.loadClass() [instance SL1, no lock obtained] org.jboss.system.URLCLassLoader.loadClassLocally() [instance CL1, no lock obtained] java.lang.ClassLoader.loadClass() [instance CL1, lock on CL1 obtained] [now the class is loaded, and additional linkage happens, some other class is needed] Thread2 does java.lang.ClassLoader.loadClassInternal() [instance CL2, no lock obtained] org.jboss.system.ServiceLibraries.loadClass() [instance SL1, no lock obtained] org.jboss.system.URLCLassLoader.loadClassLocally() [instance CL2, no lock obtained, failed] [now the SL1 code obains the SL1.classLoaders lock] Thread1 does now java.lang.ClassLoader.loadClassInternal() [instance CL1, lock on CL1 obtained] org.jboss.system.ServiceLibraries.loadClass() [instance SL1, lock on CL1 obtained] [SL1 waits on the SL1.classLoaders lock, has lock on CL1] Thread2 does now org.jboss.system.URLClassLoader.loadClassLocally() [instance CL1, lock on SL1 obtained] java.lang.ClassLoader.loadClass() [instance CL1, has lock on SL1 waits for lock on CL1] Oles changes to the ServiceLibrary should perhaps (in addition to the NOT applied patch) now lead to a successful result (Ole, when you say no deadlocks anymore does that mean without or WITHOUT the patch? ;-) CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMQ thread model
There is a interesting thread on linux threads here: http://www.jboss.org/forums/thread.jsp?forum=52&thread=2273 tobi Ole Husgaard wrote: > > Hi, > > As most of you are probably aware, JBossMQ creates a _lot_ of > threads. This can be particularly annoying with native threads > Java VMs on Linux where threads are just processes with shared > memory and io, and where the number of operating system threads > by default are limited to 512. > I am a Linux user, and I am a bit annoyed by this. Sometimes > when I play with JBoss, I cannot even open a new shell, because > all available OS processes are in use by JBoss. > > Looking into the JBossMQ sources, it looks like the message > pusher threads in org.jboss.mq.server.ClientConsumer are > allocated per-connection. > > I do not think that this approach is very scalable. > > So what I propose (and intend to do, if noone complains) is: > 1) Add code to JBossMQ that implements a thread pool with >an embedded work queue. > 2) Change the per-connection message pusher thread >implementation to use an instance of 1) above. > > Best Regards, > > Ole Husgaard. > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
