[JBoss-dev] jboss-3.2-testsuite build.216 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060206214119Lbuild.216 BUILD COMPLETE - build.216Date of build: 02/06/2006 21:41:19Time to build: 49 minutes 23 secondsLast changed: 02/05/2006 09:33:51Last log entry: added cvs id Unit Tests: (1847) Total Errors and Failures: (0)All Tests Passed Modifications since last build: (first 50 of 2)1.1.2.2.2.6modifieddimitrisbuild/docs/readme.htmladded cvs id1.1.2.2.2.5modifieddimitrisbuild/docs/readme.htmlupdate release notes for 3.2.8
[JBoss-dev] RE: JAXBException serialVersionUID mismtach with j2ee.14
javax.xml.bind.* and jaxb are not part of j2ee1.4 even though the ri
happens to include them so this is actually fine. The serialVersionUID
has been set to the j2ee1.4 value.
-Original Message-
From: Scott M Stark
Sent: Monday, February 06, 2006 11:27 AM
To: jboss-development@lists.sourceforge.net
Cc: '[EMAIL PROTECTED]'
Subject: JAXBException serialVersionUID mismtach with j2ee.14
Somehow we seem to have missed synching the javax.xml.bind.JAXBException
class serialVersionUID up with the j2ee1.4 value when we aligned these
in 4.0.2.
WARNING: No explicit serialVersionUID:
ClassVersionInfo{serialVersion=4092921986583236256,
hasExplicitSerialVersionUID=false, name=javax.xml.bind.JAXBException}
serialVersionUID error for javax.xml.bind.JAXBException, J2EE1.4
-1795805848732208234, current: 4092921986583236256
I rechecked the current j2ee1.4 ri value and it is consistent with the
testsuite serialVersionUID/j2ee141.ser value:
[EMAIL PROTECTED] lib]$ serialver -classpath jaxr-impl.jar
javax.xml.bind.JAXBException
javax.xml.bind.JAXBException:static final long serialVersionUID =
-1795805848732208234L;
We can use the org.jboss.j2ee.LegacySerialization system property to
correct this, but the check against the serialVersionUID/402.ser will
then fail and the JAXBException would have to be excluded from the
check, or the serialVersionUID/402.ser updated.
The big issue here is that I don't see how the
org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase passed
for the past releases. We can't have this test pass and latter have an
incompatibility like this show up. Either there is a flaw in the test or
what I'm seeing so I need to figure this out before 4.0.4RC1 goes out.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: WebServices in the 3.2.8 compatibility testsuite
> I would say if you QA to test WebService between different versions at any > time, you will need to provide a compatible testsuite. Lets talk about this in vegas - if you are there. > -Original Message- > From: Clebert Suconic > Sent: 06 February 2006 21:48 > To: Thomas Diesler > Cc: Scott M Stark; '[EMAIL PROTECTED]' > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > Okay... > > At this point my understanding is it's not needed to perform compatibility > tests with WebServices. > > I would say if you QA to test WebService between different versions at any > time, you will need to provide a compatible testsuite. > > > Clebert > > -Original Message- > From: Thomas Diesler > Sent: Monday, February 06, 2006 2:41 PM > To: Clebert Suconic > Cc: Scott M Stark; [EMAIL PROTECTED] > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > Hi Clebert, > > see attached my earlier response. With web service, the endpoint and the > client are fundamentally detached (i.e. the server side endpoint does not > care what technology put the message on the wire) > > All of our WS tests currently deploy the endpoint and the client to the > same box - this is not very sensible. Similar to a J2EE-1.4 application > client, the client should be deployed to a separate box (that may run a > different jboss version) > > If you look at testsuite/output/lib you see jars like ws4ee-sometest.jar + > ws4ee-sometest-client.jar > > Form JBossTest, both jars should be deployable to different jboss > versions. This is currently not possible. > > Please create a JIRA issue for this requirement that equally applies to > all tests where the client does a jndi lookup - it should not use the jndi > tree from the server if you want to test compatibility. > > Cheers > -thomas > > > -Original Message- > > From: Clebert Suconic > > Sent: 06 February 2006 16:29 > > To: Thomas Diesler > > Subject: FW: WebServices in the 3.2.8 compatibility testsuite > > > > Hey Thomas... > > > > I don't know if you saw that e-mail. > > > > We still need to know if there are client libraries that need to be > > validated. > > > > Or if we don't need to validate client libraries, if it's required to > > validate any sort of protocol in between versions. (3.2.x vs previous, > > 4.0.x vs previous). > > > > It seems that you said that 3.2.x it's not needed even within previous > > version of 3.2.x, but what about 4.0.x withing previous prevsions. > > > > Please, copy QA in your answer. > > > > Thanks > > > > > > Clebert > > > > -Original Message- > > From: Clebert Suconic > > Sent: Friday, February 03, 2006 11:20 AM > > To: Thomas Diesler > > Cc: QA; Dimitris Andreadis; Scott M Stark; Ryan Campbell > > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > > > >For QA: Generally web service client deployments should be disconnected > > from web service endpoint deployments. Currently an application client > is > > deployed on the same host as the webservice endpoint - this is strictly > > speaking incorrect. > > > > We know what a webservice is (that is a disconnected service endpoint), > > but we need to know if there are client libraries that might need to be > > required on WebService clients. > > > > You already answered our question about if we need interoperability > > between 3.2.x and 4.0.x, but you didn't answer what tests we need (or > even > > if we have to) to execute to guarantee interoperability between 4.0.x > and > > previous versions of 4. > > > > > > -Original Message- > > From: Thomas Diesler > > Sent: Friday, February 03, 2006 7:20 AM > > To: Dimitris Andreadis; Scott M Stark; Ryan Campbell; Clebert Suconic > > Cc: QA > > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > > > Hi Dimitris, > > > > There is no need to test interoperability between 3.2.x and 4.0.x web > > services . With jboss 4.0.x we have J2EE-1.4 compliant web services that > > did not exist prior to jboss-4.0.0. The Jboss.Net implementation is > > shipped with jboss-4.0.x as an optional module in docs/examples. If > > customers really choose to install Jboss.NET on jboss-4.0.x (what we > > discourage them from doing so) and they really run into interop issues > > with jboss-3.2.x, we will be dealing with those on a case by case basis. > > > > For QA: Generally web service client deployments should be disconnected > > from web service endpoint deployments. Currently an application client > is > > deployed on the same host as the webservice endpoint - this is strictly > > speaking incorrect. > > > > Cheers > > -thomas > > > > > -Original Message- > > > From: Dimitris Andreadis > > > Sent: 03 February 2006 09:50 > > > To: Thomas Diesler > > > Subject: WebServices in the 3.2.8 compatibility testsuite > > > Importance: High > > > > > > > > > Hi Thomas, > > > > > > Is there any chance of interoperability between 3.2.x / 4.0.x > > webservices? > > > > > > If yes, is there someo
[JBoss-dev] RE: WebServices in the 3.2.8 compatibility testsuite
Okay... At this point my understanding is it's not needed to perform compatibility tests with WebServices. I would say if you QA to test WebService between different versions at any time, you will need to provide a compatible testsuite. Clebert -Original Message- From: Thomas Diesler Sent: Monday, February 06, 2006 2:41 PM To: Clebert Suconic Cc: Scott M Stark; [EMAIL PROTECTED] Subject: RE: WebServices in the 3.2.8 compatibility testsuite Hi Clebert, see attached my earlier response. With web service, the endpoint and the client are fundamentally detached (i.e. the server side endpoint does not care what technology put the message on the wire) All of our WS tests currently deploy the endpoint and the client to the same box - this is not very sensible. Similar to a J2EE-1.4 application client, the client should be deployed to a separate box (that may run a different jboss version) If you look at testsuite/output/lib you see jars like ws4ee-sometest.jar + ws4ee-sometest-client.jar Form JBossTest, both jars should be deployable to different jboss versions. This is currently not possible. Please create a JIRA issue for this requirement that equally applies to all tests where the client does a jndi lookup - it should not use the jndi tree from the server if you want to test compatibility. Cheers -thomas > -Original Message- > From: Clebert Suconic > Sent: 06 February 2006 16:29 > To: Thomas Diesler > Subject: FW: WebServices in the 3.2.8 compatibility testsuite > > Hey Thomas... > > I don't know if you saw that e-mail. > > We still need to know if there are client libraries that need to be > validated. > > Or if we don't need to validate client libraries, if it's required to > validate any sort of protocol in between versions. (3.2.x vs previous, > 4.0.x vs previous). > > It seems that you said that 3.2.x it's not needed even within previous > version of 3.2.x, but what about 4.0.x withing previous prevsions. > > Please, copy QA in your answer. > > Thanks > > > Clebert > > -Original Message- > From: Clebert Suconic > Sent: Friday, February 03, 2006 11:20 AM > To: Thomas Diesler > Cc: QA; Dimitris Andreadis; Scott M Stark; Ryan Campbell > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > >For QA: Generally web service client deployments should be disconnected > from web service endpoint deployments. Currently an application client is > deployed on the same host as the webservice endpoint - this is strictly > speaking incorrect. > > We know what a webservice is (that is a disconnected service endpoint), > but we need to know if there are client libraries that might need to be > required on WebService clients. > > You already answered our question about if we need interoperability > between 3.2.x and 4.0.x, but you didn't answer what tests we need (or even > if we have to) to execute to guarantee interoperability between 4.0.x and > previous versions of 4. > > > -Original Message- > From: Thomas Diesler > Sent: Friday, February 03, 2006 7:20 AM > To: Dimitris Andreadis; Scott M Stark; Ryan Campbell; Clebert Suconic > Cc: QA > Subject: RE: WebServices in the 3.2.8 compatibility testsuite > > Hi Dimitris, > > There is no need to test interoperability between 3.2.x and 4.0.x web > services . With jboss 4.0.x we have J2EE-1.4 compliant web services that > did not exist prior to jboss-4.0.0. The Jboss.Net implementation is > shipped with jboss-4.0.x as an optional module in docs/examples. If > customers really choose to install Jboss.NET on jboss-4.0.x (what we > discourage them from doing so) and they really run into interop issues > with jboss-3.2.x, we will be dealing with those on a case by case basis. > > For QA: Generally web service client deployments should be disconnected > from web service endpoint deployments. Currently an application client is > deployed on the same host as the webservice endpoint - this is strictly > speaking incorrect. > > Cheers > -thomas > > > -Original Message- > > From: Dimitris Andreadis > > Sent: 03 February 2006 09:50 > > To: Thomas Diesler > > Subject: WebServices in the 3.2.8 compatibility testsuite > > Importance: High > > > > > > Hi Thomas, > > > > Is there any chance of interoperability between 3.2.x / 4.0.x > webservices? > > > > If yes, is there someone from WS team, to work on this now? > > > > We are at the last stages of finalizing 3.2.8 (we are supposed to > release > > on Monday 6th) so a quick response is appreciated :) > > > > -Original Message- > > From: Scott M Stark > > Sent: 03 February, 2006 00:38 > > To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis; QA > > Cc: Thomas Diesler > > Subject: RE: Inclusion of jbossmx in the 3.2.8 compatibility testsuite > > > > A server side library should not be required for the recent jboss > > webservice tests/stacks. The 3.2 branch may not have a descent > webservice > > stack and might need to be excluded, but the 4.0.x inter
[JBoss-dev] Pluggable Serialization into JBAS Invocation Layer
I just committed JBAS-2436 into JBAS 4.0 since JBoss Remoting is already out (I had some changes on JBoss Remoting holding me to commit this). I still have some questions about how to improve its configuration at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73693 I will create a wiki page on how to use and configure it. Clebert Suconic --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [Hibernate] Do antlr exception leak to users?
On Mon, 06 Feb 2006 20:49:08 +0100, Scott M Stark <[EMAIL PROTECTED]> wrote: I'm seeing some incompatible serial version uid changes in the latest antlr, but I don't know if antlr exceptions every leak to users outside of the vm such that this is an issue. Do the ql grammar exception get exposed or are they always converted to a hibernate exception? it is always converted, but of course it can be inside as a cause exception. /max serialVersionUID error for antlr.ANTLRException, 402 7031854369222456415, current: -3185796504902623848 serialVersionUID error for antlr.TokenStreamException, 402 -6645096224442002282, current: -8659971349776228514 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Do antlr exception leak to users?
I’m seeing some incompatible serial version uid changes in the latest antlr, but I don’t know if antlr exceptions every leak to users outside of the vm such that this is an issue. Do the ql grammar exception get exposed or are they always converted to a hibernate exception? serialVersionUID error for antlr.ANTLRException, 402 7031854369222456415, current: -3185796504902623848 serialVersionUID error for antlr.TokenStreamException, 402 -6645096224442002282, current: -8659971349776228514
[JBoss-dev] JAXBException serialVersionUID mismtach with j2ee.14
Somehow we seem to have missed synching the javax.xml.bind.JAXBException
class serialVersionUID up with the j2ee1.4 value when we aligned these
in 4.0.2.
WARNING: No explicit serialVersionUID:
ClassVersionInfo{serialVersion=4092921986583236256,
hasExplicitSerialVersionUID=false, name=javax.xml.bind.JAXBException}
serialVersionUID error for javax.xml.bind.JAXBException, J2EE1.4
-1795805848732208234, current: 4092921986583236256
I rechecked the current j2ee1.4 ri value and it is consistent with the
testsuite serialVersionUID/j2ee141.ser value:
[EMAIL PROTECTED] lib]$ serialver -classpath jaxr-impl.jar
javax.xml.bind.JAXBException
javax.xml.bind.JAXBException:static final long serialVersionUID =
-1795805848732208234L;
We can use the org.jboss.j2ee.LegacySerialization system property to
correct this, but the check against the serialVersionUID/402.ser will
then fail and the JAXBException would have to be excluded from the
check, or the serialVersionUID/402.ser updated.
The big issue here is that I don't see how the
org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase passed
for the past releases. We can't have this test pass and latter have an
incompatibility like this show up. Either there is a flaw in the test or
what I'm seeing so I need to figure this out before 4.0.4RC1 goes out.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ejb3-4.0-testsuite Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060206131903 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details.Date of build: 02/06/2006 13:19:03Time to build: 31 minutes 46 secondsLast changed: 12/31/2005 16:46:08Last log entry: call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 3659)1.3modifiedbillsrc/test/org/jboss/ejb3/test/tableperinheritance/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.7modifiedbillsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.6modifiedbillsrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaEJBs and Persistence can now be within a .jar file1.3modifiedbillsrc/test/org/jboss/ejb3/test/xmlcfg/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.4modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaapplication-exception support1.7modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaapplication-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorAppException.javabranches: 1.1.2;application-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorCheckedRollbackException.javabranches: 1.1.2;application-exception support1.5modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaapplication-exception support1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javabranches: 1.2.2;activateConfig to activationConfig1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javabranches: 1.2.2;activateConfig to activationConfig1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/unit/EmbeddedEjb3TestCase.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/Customer.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOBean.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOLocal.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAORemote.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/EmbeddedEJB3.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/JndiTest.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javatest for embedded EJB3 in WLS1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/Customer.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTest.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTestBean.javaUpdate the jboss LGPL headers1.4modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTester.javaUpdate the jboss LGPL headers1.9modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean21.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AnnotatedAppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/CheckedRollbackException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRuntimeException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRuntimeException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/SimpleEntity.javaUpdate the jboss LGPL headers1.4m
[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060206112716 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/06/2006 11:27:16Time to build: 71 minutes 32 secondsLast changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (283) Total Errors and Failures: (2)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization) Modifications since last build: (first 50 of 2031)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-253 - changed to use coyote connector by default instead of http server invoker. Also adding many fixes so now only ssl related http tests are failing within the tests suite.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/.truststoreJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.2modifiedtelrodsrc/tests/org/jbo
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
Yes this is a great example of the general problem of canceling a thread
asynchronously. That resulting state is most likely not anticipated by
the thread (No one expects a = 1 to throw an exception).
Most threading APIs try to solve this problem using cancelable points.
In pthreads for example, this is any blocking thread operation (sigwait,
or pthread_join). There is also a pthread_testcancel that you can use to
programmatically check for cancellation. So the equivalent in Java is
thread.interrupt().
However, I should clarify that what I meant is that the state of the
overall system will be safe provided that the thread did not access any
shared resource. So in this scenario, while it is possible that the
thread will be corrupted, we don't care because it will eventually exit,
and all of its resources will be freed.
An example of a safe use of Thread.stop is where the target thread is
doing some long running mathematical calculation.
I am in no way, endorsing the use of thread cancellation. Even in
scenarios where it is safe to use it, the code can be easily rewritten
to periodically poll a notification variable.
-Jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED] On Behalf Of Adrian Brock
> Sent: Monday, February 06, 2006 3:25 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] BasicThreadPool and Thread.stop()
>
> Thanks for the clarification. Re-reading this:
>
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecatio
n.
> html
>
> This says it is never safe. 2 examples:
>
> lock = lock();
> // Thread death here is bad!
> try
> {
> ...
> }
> finally
> {
>lock.unlock();
> }
>
> An attempt to fix it
>
> lock = null;
> try
> {
>lock = lock();
> ...
> }
> finally
> {
>if (lock != null)
> lock.unlock();
> }
>
> But it won't work, because this code is really:
>
> lock = null;
> try
> {
>lock();
>// Thread death here is bad!
>lock = popResultFromThreadStack();
> ...
> }
> finally
> {
>if (lock != null)
> lock.unlock();
> }
> --
>
> Adrian Brock
> Chief Scientist
> JBoss Inc.
>
>
>
>
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060206092628 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/06/2006 09:26:28Time to build: 41 minutes 53 secondsLast changed: 12/28/2005 10:48:11Last log entry: Add the 1.2.4SP1 changelog notes. Unit Tests: (1349) Total Errors and Failures: (48)testorg.jboss.cache.ConcurrentEvictAndRemoveTesttestCircularAndSharedReferencesorg.jboss.cache.aop.ObjectGraphAopTesttestCircularAndSharedReferencesorg.jboss.cache.aop.ReplicatedObjectGraphAopTesttestSimplifiedorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestSimplifiedorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestIsReachableorg.jboss.cache.aop.util.ObjectUtilAopTesttestDataSourceIntegrationorg.jboss.cache.loader.DataSourceIntegrationTesttestSharedCacheLoadingWithReplicationorg.jboss.cache.optimistic.OptimisticWithCacheLoaderTesttestCollectionWithCacheLoaderorg.jboss.cache.aop.loader.FileCacheLoaderAopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer1241AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer124AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer130AopTestwarningorg.jboss.cache.benchmark.support.BaseTestwarningorg.jboss.cache.benchmark.support.Read50PercentTestwarningorg.jboss.cache.benchmark.support.Read75PercentTestwarningorg.jboss.cache.benchmark.support.Read90PercentTestwarningorg.jboss.cache.benchmark.tests.HashMapRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead90JRunitTesttestUpdateEvictionorg.jboss.cache.eviction.AopLRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.FIFOPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LFUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.MRUPolicyTesttestThreadedAccess_RWLockorg.jboss.cache.lock.IdentityLockTesttestReadCommittedorg.jboss.cache.lock.LockTesttest2ReadersAnd1Writerorg.jboss.cache.lock.ReentrantWriterPreferenceReadWriteLockTestwarningorg.jboss.cache.optimistic.LocalCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticTestwarningorg.jboss.cache.optimistic.LocalTesttestConcurrentAccessWithRWLockorg.jboss.cache.transaction.ConcurrentTransactionalTesttestReadCommittedorg.jboss.cache.transaction.IsolationLevelReadCommittedTesttestNodeCreationRollbackorg.jboss.cache.transaction.IsolationLevelReadCommittedTest Modifications since last build: (first 50 of 1564)1.3modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaFixes rating to JBCACHE-118 - optimising cache loader functionality.1.2modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.1addedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.2modifieddhuangtests/stress/org/jboss/cache/EvictionLocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.2modifieddhuangtests/stress/org/jboss/cache/LocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Re
Re: [JBoss-dev] Applet class loaders and getResource()
On Mon, 2006-02-06 at 06:24, Kabir Khan wrote:
> I am trying to find out if jboss aop will work within an applet, and have
> stumbled upon a problem when javassist tries to determine if a class exists.
> This seems to be releated to how applets find resources.
>
> Isolating this, I have the following code in my applet:
>
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> System.out.println("ClassLoader: " + cl);
> URL coll = (URL)cl.getResource("java/util/Collection.class");
>
> System.out.println("Resource: " + coll);
>
> which gives the following output when running with the appletviewer:
>
> ClassLoader: [EMAIL PROTECTED]
> Resource: null
>
> If I run it from withing eclipse (debug applet) it can find the resource:
>
> ClassLoader: [EMAIL PROTECTED]
> Resource:
> jar:file:/C:/Java/jdk/jdk1.5.0_04/jre/lib/rt.jar!/java/util/Collection.class
>
> Does anybody have any suggestions to what could be going on here?
>
Security. Something in the stack is not authorized to that url.
Install a security manager and policy for the eclipse test
to reproduce the problem.
> Cheers,
>
> Kabir
>
>
>
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Applet class loaders and getResource()
I am trying to find out if jboss aop will work within an applet, and have
stumbled upon a problem when javassist tries to determine if a class exists.
This seems to be releated to how applets find resources.
Isolating this, I have the following code in my applet:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
System.out.println("ClassLoader: " + cl);
URL coll = (URL)cl.getResource("java/util/Collection.class");
System.out.println("Resource: " + coll);
which gives the following output when running with the appletviewer:
ClassLoader: [EMAIL PROTECTED]
Resource: null
If I run it from withing eclipse (debug applet) it can find the resource:
ClassLoader: [EMAIL PROTECTED]
Resource:
jar:file:/C:/Java/jdk/jdk1.5.0_04/jre/lib/rt.jar!/java/util/Collection.class
Does anybody have any suggestions to what could be going on here?
Cheers,
Kabir
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
On Mon, 2006-02-06 at 01:06, Jason T. Greene wrote:
> Actually the behavior you describe is the semantics of Thread.destroy()
> if it were actually implemented. Thread.stop() just forces the targeted
> thread to throw a ThreadDeath exception. This causes all finally blocks
> to execute, and in fact if a thread were to catch ThreadDeath, it could
> prevent the thread from dieing. This also causes all monitors that were
> aquired by the thread to be released. So, herein lies the problem. Since
> this exception can occur at any point, the object state of that thread
> is potentially corrupt.
>
> So, if the thread does not share state with other threads, it is
> actually quite safe. This is hardly the case though, and is a problem
> for BasicThreadPool because we do not know what the task is actually
> doing.
Thanks for the clarification. Re-reading this:
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
This says it is never safe. 2 examples:
lock = lock();
// Thread death here is bad!
try
{
...
}
finally
{
lock.unlock();
}
An attempt to fix it
lock = null;
try
{
lock = lock();
...
}
finally
{
if (lock != null)
lock.unlock();
}
But it won't work, because this code is really:
lock = null;
try
{
lock();
// Thread death here is bad!
lock = popResultFromThreadStack();
...
}
finally
{
if (lock != null)
lock.unlock();
}
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Legacy xml config parsing
I have a javabean schemabinding in the Microcontainer module that does this: http://anoncvs.forge.jboss.com/viewrep/JBoss/microkernel/src/resources/schema/javabean_1_0.xsd?r=1.1 It is only in the Microcontainer module, because I reused the BeanInfo model to do the reflection. I think you'll find the problem with the legacy model is that much of it isn't javabeans. There are no setters because the values are read from the load method. On Sun, 2006-02-05 at 16:11, Scott M Stark wrote: > The simple immediate solution would be to take all of the interceptor > attributes as string key/value pairs for java bean style properties that > are passed to the > org.jboss.util.propertyeditor.PropertyEditors.mapJavaBeanProperties > similar to the handling in the service configuration for > serialDataType="javaBean". > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Scott M Stark > Sent: Sunday, February 05, 2006 1:05 PM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] Legacy xml config parsing > > I have a need to externalize some configuration on a new security > related interceptor and don't want to propagate the old XmlLoadable > interface, even though it's the only way to do this currently. I could > adapt some of the service xml support configuration mechanisms like > serialDataType="javaBean | jbxb" (see > http://wiki.jboss.org/wiki/Wiki.jsp?page=SERVICEdotXML), but introducing > this piecewise for all of the extension points in the requires mods to > many layers due to the XmlLoadable coupling configuration to > implementation layers. > > Anyone looked at trying to unify the legacy jboss.xml parsing into a > jbossxb implementation that would help with this? > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
