Re: [JBoss-dev] undeploy a dependency?
On Wed, 2006-02-01 at 16:42, Bill Burke wrote: I'm seeing start being called twice for a particular MBean and thus, I'm getting an error. I think what is happening is this: 1. deploy 'A' MBean, its dependency 'B' has not been resolved 2. Deploy 'B', resolve 'A''s dependency, call create/start 3. Undeploy 'B' 4. Deploy 'B' Is this the correct behavior? Is the 4.0.4 kernel attempting to do redploys correct? It doesn't sound like correct behaviour to me. :-) Do you know what is triggering the undeploy? -- 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=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060202074428 BUILD FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details.Date of build:02/02/2006 07:44:28Time to build:19 minutes 7 secondsLast changed:02/02/2006 07:07:20Last log entry:[JBAS-2762] - Missing statemanger causes infinite loop Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 3)1.23modifiedadrianmessaging/src/main/org/jboss/mq/server/JMSDestinationManager.java[JBAS-2762] - Missing statemanger causes infinite loop1.16modifiedadriankernel/src/main/org/jboss/kernel/plugins/dependency/KernelControllerContextActions.java[JBMICROCONT-67] - Shouldn't need to specify class="blah"when using a factory.1.11modifiedadriancontainer/src/main/org/jboss/reflect/plugins/MethodInfoImpl.javaFix the toShortString()
[JBoss-dev] jboss-cache build.141 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache?log=log20060202080548Lbuild.141 BUILD COMPLETE-build.141Date of build:02/02/2006 08:05:48Time to build:17 secondsLast changed:02/02/2006 07:19:26Last log entry:Fixed syntax error in TreeCache.getState() as it wouldn't compile. Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 9)1.113modifiedjerrygauthsrc/org/jboss/cache/TreeCache.javaFixed syntax error in TreeCache.getState() as it wouldn't compile.1.1addedbstansberrytests/functional/org/jboss/cache/statetransfer/ConcurrentStateTransfer1241Test.java[JBCACHE-315] First pass at breaking locks for state transfer1.1addedbstansberrytests/functional/org/jboss/cache/statetransfer/ForcedStateTransferTest.java[JBCACHE-315] First pass at breaking locks for state transfer1.3modifiedbstansberrytests/functional/org/jboss/cache/statetransfer/StateTransfer1241Test.java[JBCACHE-315] First pass at breaking locks for state transfer1.3modifiedbstansberrytests/functional/org/jboss/cache/statetransfer/StateTransfer124Test.java[JBCACHE-315] First pass at breaking locks for state transfer1.3modifiedbstansberrytests/functional/org/jboss/cache/statetransfer/StateTransfer130Test.java[JBCACHE-315] First pass at breaking locks for state transfer1.10modifiedbstansberrytests/functional/org/jboss/cache/statetransfer/StateTransferTestBase.java[JBCACHE-315] First pass at breaking locks for state transfer1.1addedbstansberrytests/functional/org/jboss/cache/statetransfer/VersionedTestBase.java[JBCACHE-315] First pass at breaking locks for state transfer1.112modifiedbstansberrysrc/org/jboss/cache/TreeCache.java[JBCACHE-315] First pass at breaking locks for state transfer
[JBoss-dev] jboss-head-jdk-matrix build.1338 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060202083906Lbuild.1338 BUILD COMPLETE-build.1338Date of build:02/02/2006 08:39:06Time to build:29 minutes 53 secondsLast changed:02/02/2006 08:20:19Last log entry:Stupid autocomplete :-) Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 5)1.2modifiedadrianmessaging/src/main/org/jboss/mq/sm/none/NullStateManager.javaStupid autocomplete :-)1.1addedadrianmessaging/src/main/org/jboss/mq/sm/none/NullStateManager.javaA simple state manager that does not persist any state.i.e. Doesn't support durable subscriptions or preconfigured client ids.Suitable for use in simple in memory unit tests.Currently it throws an error for durable subscription operations.We could probably have a version that pretends it stored them?1.23modifiedadrianmessaging/src/main/org/jboss/mq/server/JMSDestinationManager.java[JBAS-2762] - Missing statemanger causes infinite loop1.16modifiedadriankernel/src/main/org/jboss/kernel/plugins/dependency/KernelControllerContextActions.java[JBMICROCONT-67] - Shouldn't need to specify class="blah"when using a factory.1.11modifiedadriancontainer/src/main/org/jboss/reflect/plugins/MethodInfoImpl.javaFix the toShortString()
Re: [JBoss-dev] undeploy a dependency?
Adrian Brock wrote: On Wed, 2006-02-01 at 16:42, Bill Burke wrote: I'm seeing start being called twice for a particular MBean and thus, I'm getting an error. I think what is happening is this: 1. deploy 'A' MBean, its dependency 'B' has not been resolved 2. Deploy 'B', resolve 'A''s dependency, call create/start 3. Undeploy 'B' 4. Deploy 'B' Is this the correct behavior? Is the 4.0.4 kernel attempting to do redploys correct? It doesn't sound like correct behaviour to me. :-) Do you know what is triggering the undeploy? :) Yes, my test code! I'm testing to make sure dependencies work. -- Bill Burke Chief Architect 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=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ejb3-4.0-testsuite Build Failed
Am finished adding the remoting-int module (see JBAS-2698). The jar produced (and put in the lib directory of default and all server config) is jboss-remoting-int.jar (instead of jbossas-remoting.jar, which is how it is in HEAD). I am not sure if/where there will need to be any adjustments for this within the ejb3 project. Ryan Campbell wrote: Yes, this is Branch_4_0. Thanks, Tom. -Original Message- From: Tom Elrod Sent: Tuesday, January 31, 2006 1:28 PM To: Tom Elrod Cc: Ryan Campbell; Tom Elrod; Kabir Khan; Bill Burke; jboss-development@lists.sourceforge.net Subject: Re: ejb3-4.0-testsuite Build Failed I think I get the mis-match now. This is being build out of JBoss 4.x branch, right? If so, then the code for jbossas-remoting.jar is not there. There is an issue for this (JBAS-2698), which I will work on today. Tom Elrod wrote: The class that is not being found is within jbossas-remoting.jar. This is part of JBossAS code base and not remoting. Only way this would be called to be loaded is if was configured to use the JBossAS security domain via configuration. So am guessing the jar was excluded from the build? Ryan Campbell wrote: The ejb3-ssl-advanced test server is broken: 2006-01-30 20:09:06,202 DEBUG [org.jboss.deployment.SARDeployer] create operation failed for package file:/services/cruisecontrol/checkout/ejb3-4.0-testsuite/build/output/jb oss-4.0.4RC1/server/ejb3-ssl-advanced/deploy/ejb3.deployer/ org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:19 6) at org.jboss.system.ServiceController.install(ServiceController.java:226) *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, January 30, 2006 7:12 PM *To:* Adrian Brock; Bill Decoste; Bill Burke; Gavin King; jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel Loehr; Scott M Stark; Thomas Diesler *Subject:* ejb3-4.0-testsuite Build Failed *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=lo g20060130193339 *BUILD FAILED* *Ant 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: *01/30/2006 19:33:39 *Time to build: *37 minutes 18 seconds *Last changed: *12/31/2005 16:46:08 *Last log entry: *call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false --- 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=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] undeploy a dependency?
So can you show the server.log
You should see this message from the ServiceController
when you redeploy B:
// Remove the context, unless it is still recording
dependencies
if (ctx.dependsOnMe.size() == 0)
nameToServiceMap.remove(objectName);
else
{
log.debug(Context not removed, it is recording +
dependencies: + ctx);
ctx.proxy = null;
}
There is are tests for this in the JMX part of the testsuite.
On Thu, 2006-02-02 at 09:20, Bill Burke wrote:
Adrian Brock wrote:
On Wed, 2006-02-01 at 16:42, Bill Burke wrote:
I'm seeing start being
called twice for a particular MBean and thus, I'm getting an error. I
think what is happening is this:
1. deploy 'A' MBean, its dependency 'B' has not been resolved
2. Deploy 'B', resolve 'A''s dependency, call create/start
3. Undeploy 'B'
4. Deploy 'B'
Is this the correct behavior? Is the 4.0.4 kernel attempting to do
redploys correct?
It doesn't sound like correct behaviour to me. :-)
Do you know what is triggering the undeploy?
:) Yes, my test code! I'm testing to make sure dependencies work.
--
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=lnkkid=103432bid=230486dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 3.2.x / 4.0.x compatibility
One of the differences I see in the 2 branches, is the useFullHashMode: org.jboss.invocation.MarshalledInvocation /** A flag indicating if the */ static boolean useFullHashMode = false; Which was added around 3.2.4 http://sourceforge.net/docman/display_doc.php?docid=21888group_id=22866 This is 'true' for 4.0.x thus prohibiting interoperability and I don't see this being configured somewhere. Can I conditionally set this to true, based only the org.jboss.util.id.SerialVersion.version setting? --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: Guessing datasource name
I still think we need a jmx object name alias registry to wean off of the objectnames to simple, purpose oriented names. This would have to be integrated as an aspect on top of the mbeanserver/registry. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, February 01, 2006 12:59 PM To: jboss-development@lists.sourceforge.net Cc: Bill Burke Subject: Re: [JBoss-dev] Re: Guessing datasource name Perhaps we should just byte the bullet and fix this naming confusion? The problem is everybody's existing config that uses it. e.g. JMS and login-config.xml that reference these names. You can certainly fix the stylesheet and change this config in jbossjca-service.xml mbean code=org.jboss.deployment.XSLSubDeployer name=jboss.jca:service=ConnectionFactoryDeployer attribute name=DdSuffix-ds.xml/attribute attribute name=EnhancedSuffixes300:-ds.xml/attribute attribute name=XslUrlstylesheets/ConnectionFactoryTemplate.xsl/attribute attribute name=ValidateDTDsfalse/attribute /mbean --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
This will help get us finalized on a mc and start thinking about the proper abstractions to use it so I'm all for it. 1) Some have been inquiring about whether spring integration setups can also be used. Possibly we could have a spring alias mapping that binds to our integration implementation. Possibly we could even use existing spring integration objects for standard apis like JTA so we don't have to write it for envs we don't readily have for testing. 2) So you are talking about abstractions on top of JTA or on the JTA provider service for interaction outside of JTA? 3) Good. As a part-time dev on the kernel its hard for me to pull all of the pieces together with respect to a usable mc setup so I think a concrete collection of components in an embedded type of profile will help finalize the design. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, February 01, 2006 4:57 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation FYI I am starting work on a prototype of the following three new modules (I am not sure these are good names :-) 1) Integration - Cross (other) container integration spi like how do I bind to jndi?, give me the transaction synchronizer, etc. 2) Services - abstraction of our common container spi, such that other projects can use these interfaces to talk to each other rather than linking directly to implementation e.g. Who knows whether the user wants to use JBossJTA or JBoss Transactions? 3) Embedded - an extension to the kernel module that introduces aop, jmx, profile service and eventually aspectized deployments (all optional) My plans for enhanced embedded bootstrap implementations are: * Explicit - tell me what you want to do - suitable for extension * Classpath - like current MC Standalone bootstrap - suitable for main() usage * URLClassLoader - parse getURLs() and look for config relative to this - suitable for running inside an EJB container, servlet container, etc. * Test - shared base common config + test specific config - suitable for use in JUnit/TestNG I think this has some redundancy with the EJB3 bootstrap methods but it doesn't make sense to have this EJB3 specific. e.g. I want to * bootstrap/configure some JBoss Service inside a servlet context of another JEE container * run tests against a service that requires other services * provide a real standalone distribution of JBoss Messaging * etc. My motivation for this prototype is not to get a product out of it yet. It is to flush out the integration details between the projects. In particular, AOP and MC. I started the new jca project for this purpose as well, but I haven't had any real feedback on this prototype from the AOP team. It also includes a simple AOP proxy replacement for org.jboss.proxy in the aspects module (again a prototype) and POJOs to allow aspects to be configured via DI in the MC. Bill did help me with some pointcut definition enhancements to implement MessageEndpoint properly. I'm hoping if I do this for something less esoteric than JCA then I will get some feedback ;-) On Tue, 2006-01-31 at 22:26, Scott M Stark wrote: How can the scanClasspath() step be optimized/skipped in say an embedded ejb3 project in jbosside where the data obtained during the scan was written out in an optimized metadata store as part of the project say? I don't really follow adding aspects like clustering to deployments based on the location in a filesystem, virtual or otherwise. Just seems like too much meaning being linked to the deployment url/location. I'm busy through tomorrow, but come thu I will just checkin the current vfs stuff I have had sitting in the workspace for months and see what start can be made on pushing this forward. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Tuesday, January 31, 2006 9:28 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation I think going the E-EJB3 route to start is a good idea as it will force us to implement bare-bones implementations that do not have the idea of a classloader or j2ee deployment schemes within them. Once we have e-ejb3 (really e-jboss) in place, it will force us to be careful about adding things like classloading and j2ee packaging as to not break or bloat e-jboss. The way I envision it working is basically how it works with current kernel * This shit must be REALLY FAST. Remember, we're using it with junit tests. * embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer, AOPDeployer, EJB3Deployer, (etc.) and basic services like TM, JNDI, etc. * EJB3StandaloneBootstrap still exists and has three methods: - boot(): This loads embeddded-jboss-beans.xml - scanClasspath(). The scans the entire
[JBoss-dev] jboss-3.2-compatibility-matrix Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-compatibility-matrix?log=log20060202131854 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-common.xml:235: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build Successful - Tests completed with errors or failures.Date of build:02/02/2006 13:18:54Time to build:34 minutes 3 secondsLast changed:02/02/2006 12:34:19Last log entry:Renaming GUIDTest to the correct name, so it can be part of the testsuite Unit Tests: (3563) Total Errors and Failures: (110)
[JBoss-dev] ejb3-4.0-testsuite Build Timed Out
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060202103820 BUILD TIMED OUTAnt Error Message:build timeoutDate of build:02/02/2006 10:38:20Time to build:Last 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 3647)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.4modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaUpdate the jboss LGPL
[JBoss-dev] RE: 3.2.x / 4.0.x compatibility
Yes, it should be conditionally enabled. This was added to deal with hash collisions due to calculations that were not considering the interface/class of the method. -Original Message- From: Dimitris Andreadis Sent: Thursday, February 02, 2006 11:13 AM To: jboss-development@lists.sourceforge.net Cc: Scott M Stark Subject: 3.2.x / 4.0.x compatibility One of the differences I see in the 2 branches, is the useFullHashMode: org.jboss.invocation.MarshalledInvocation /** A flag indicating if the */ static boolean useFullHashMode = false; Which was added around 3.2.4 http://sourceforge.net/docman/display_doc.php?docid=21888group_id=22866 This is 'true' for 4.0.x thus prohibiting interoperability and I don't see this being configured somewhere. Can I conditionally set this to true, based only the org.jboss.util.id.SerialVersion.version setting? --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Remoting 1.4.0 final integration
JBoss Remoting 1.4.0 final was release late last week. I am finishing up integrating this into JBossAS 4.0 branch and HEAD. The items of note with this integration are: 4.0 branch HEAD - Updated build-thirdpary.xml to use remoting 1.4.0_final from repository - removed javax.servlet.jar from jboss all client jar. I think remoting was the reason this was initially added and is no longer needed (since http implementation based on Tomcat connectors now). 4.0 branch only - Added new module, remoting-int. This is same as jbossas module from HEAD, but renamed to better distinguish it. Biggest component of remoting-int is security integration between remoting SSL and using the JBoss security domain. The product of this module is jboss-remoting-int.jar, and is being placed in the lib directory of default and all server config. See JBAS-2698 for more details. The only remaining issue I am aware of is the Tomcat connector jars being available, which is only an issue when http transport within remoting. Jira issue for this is JBAS-2766. --- 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=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Make sure you include the jira issue number in cvs checkins
Also make sure the jira issue number is used in the check in all branches so that the branches the changes have been committed to are clear from the issue version control tab. -Original Message- From: Scott M Stark Sent: Thursday, February 02, 2006 3:54 PM To: 'jboss-development@lists.sourceforge.net' Subject: Make sure you include the jira issue number in cvs checkins Make sure you include the jira issue number for any checkins related to a jira issue so that the changes associated with the issue show up in the Version Control tab of the issue. It also aides in correlating cvs log messages with jira issues. --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Make sure you include the jira issue number in cvs checkins
Make sure you include the jira issue number for any checkins related to a jira issue so that the changes associated with the issue show up in the Version Control tab of the issue. It also aides in correlating cvs log messages with jira issues. --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Make sure you include the jira issue number in cvs checkins
I have been asked to also remind you that a useful comment also be included in each change set since there can be a disconnect between what shows up in the jira issue vs the individual file changes. Scott M Stark wrote: Make sure you include the jira issue number for any checkins related to a jira issue so that the changes associated with the issue show up in the Version Control tab of the issue. It also aides in correlating cvs log messages with jira issues. --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-3.2-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060202175301 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-common.xml:235: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build Successful - Tests completed with errors or failures.Date of build:02/02/2006 17:53:01Time to build:50 minutes 27 secondsLast changed:02/02/2006 14:17:10Last log entry:JBAS-2768, change tests that produce varying resutls based on jdk/os platform to logging warning messages rather than code assertions Unit Tests: (1847) Total Errors and Failures: (2)testFederatedorg.jboss.test.jbossnet.external.ExternalUnitTestCasetestFederatedorg.jboss.test.jbossnet.external.RedeployExternalUnitTestCase Modifications since last build:(first 50 of 14)1.2.2.20modifieddimitristestsuite/src/main/org/jboss/test/cmp2/commerce/QueryTest.javaJBAS-2768, change tests that produce varying resutls based on jdk/os platform to logging warning messages rather than code assertions1.1.2.1modifiedcsuconictestsuite/src/main/org/jboss/test/guid/GUIDTestCase.javaRenaming GUIDTest to the correct name, so it can be part of the testsuite1.11.2.10modifieddimitrisserver/src/main/org/jboss/invocation/MarshalledInvocation.javaJBAS-2767, Conditionally set useFullHashMode to true, when SerialVersion.version == SerialVersion.JBOSS_4021.165.2.198modifiedrcampbelltestsuite/build.xmladded 4.0.3SP1 to compat matrix1.1.2.16modifiedrcampbelltestsuite/imports/server-config.xmlJBAS-2758: pass serialization flag to jboss startup *and* shutdown1.165.2.197modifiedrcampbelltestsuite/build.xmlJBAS-2758: pass serialization flag to jboss startup *and* shutdown1.2.2.22modifiedadrianmessaging/src/main/org/jboss/mq/server/JMSDestinationManager.java[JBAS-2762] - Avoid infinite loop when there is no state manager.1.4.2.3modifieddimitrisjmx/src/main/javax/management/MBeanServerConnection.javasynch with 4.x1.165.2.196modifiedrcampbelltestsuite/build.xmlJBAS-2758: add usage of org.jboss.j2ee.Serialization flag to compatibility matrix1.1.4.3modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/performance/TestCase.javafix compatibility test failures1.1.4.3modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/implementation/TestCase.javafix compatibility test failures1.2.4.4modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/compliance/TestCase.javafix compatibility test failures1.1.4.2modifieddimitriscommon/src/main/org/jboss/util/id/GUID.javaJBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch)1.2.4.2modifieddimitriscommon/src/main/org/jboss/util/id/SerialVersion.javaJBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch)
[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060202231706 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/02/2006 23:17:06Time to build:34 minutes 5 secondsLast changed:12/28/2005 10:48:11Last log entry:Add the 1.2.4SP1 changelog notes. Unit Tests: (1341) Total Errors and Failures: (35)testRemoveObject2org.jboss.cache.aop.ReplicatedObjectGraphAopTesttestDataSourceIntegrationorg.jboss.cache.loader.DataSourceIntegrationTesttestCollectionWithCacheLoaderorg.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.AopLRUPolicyTesttestOptSyncReplorg.jboss.cache.loader.CacheLoaderWithReplicationTesttestReadCommittedorg.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.IsolationLevelReadCommittedTest Modifications since last build:(first 50 of 1320)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.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.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead50JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead75JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead90JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplSyncPessRead50JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplSyncPessRead75JRunitTest.javaAdded replicated
[JBoss-dev] jboss-remoting-testsuite-1.4 build.5 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060202235148Lbuild.5 BUILD COMPLETE-build.5Date of build:02/02/2006 23:51:48Time to build:16 minutes 29 seconds Unit Tests: (138) Total Errors and Failures: (0)All Tests Passed Modifications since last build:(first 50 of 0)
[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=log20060203000916 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/03/2006 00:09:16Time to build:71 minutes 54 secondsLast changed:12/31/2005 20:37:24Last log entry:JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (279) 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 2026)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
