View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050214005040Lbuild.798
BUILD COMPLETE - build.798Date of build: 02/14/2005 00:50:40Time to build: 22 minutes 10 secondsLast changed: 02/14/2005 00:05:35Last log entry: moved labels into reso
I published Patrick's work for you to see. (as it didn't go through the forum
so well :) )
http://www.jboss.org/products/jbossportal/themePatrick.zip
Thanks again Patrick.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3866415#3866415
Reply to the post :
ht
After a quick scan of the Fqn implementation, I noticed that the hashCode()
method doesn't use a cached implementation technique.
Is this done intentionally to allow the underlying objects that make up the Fqn
instance to change their hash codes? I can see why this might be required to
keep the
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050213192314Lbuild.797
BUILD COMPLETE - build.797Date of build: 02/13/2005 19:23:14Time to build: 20 minutes 10 secondsLast changed: 02/13/2005 18:55:50Last log entry: Add tests of how an ex
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050213182006Lbuild.796
BUILD COMPLETE - build.796Date of build: 02/13/2005 18:20:06Time to build: 20 minutes 48 secondsLast changed: 02/13/2005 17:50:29Last log entry: fixed form mappings so
That definitely breaks the connection pooling as the selection of the
InternalManagedConnectionPool is based on a Subject that does not have the
PasswordCredential, but the pools map key is a Subject with this added in.
There would have to be another pooling criteria key that only validated the
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050213164420Lbuild.795
BUILD COMPLETE - build.795Date of build: 02/13/2005 16:44:20Time to build: 30 minutes 59 secondsLast changed: 02/13/2005 16:30:26Last log entry: updated for change fro
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0?log=log20050213153824Lbuild.376
BUILD COMPLETE - build.376Date of build: 02/13/2005 15:38:24Time to build: 19 minutes 3 secondsLast changed: 02/13/2005 12:39:37Last log entry: Fix prefixed xmlName, xm
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050213142710Lbuild.794
BUILD COMPLETE - build.794Date of build: 02/13/2005 14:27:10Time to build: 30 minutes 28 secondsLast changed: 02/13/2005 13:52:19Last log entry: Added for non-scoped t
I'd like to see reverse xdoclet support, so I can very easily show my bosses
that application currently running on Bea can run easily on jBoss (without the
runtime deployment converter, cause that scares them although it works for some
applications)
View the original post :
http://www.jboss.or
It's compliant with 3.0. Look at the jbpm forums on SF for some topics on this
issue.
Ronald
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3866401#3866401
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3866401
--
I created the following jira issue that I want to discuss how to best achieve
here
http://jira.jboss.com/jira/browse/JBAS-1461
The problem is that services are still embedding xml parsing of attribute
configuration document fragments in the service code itself. The example
jboss-service.xml doc
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0?log=log20050213104904Lbuild.375
BUILD COMPLETE - build.375Date of build: 02/13/2005 10:49:04Time to build: 40 minutes 47 secondsLast changed: 02/13/2005 10:29:04Last log entry: Fix layout of generated
Hi;
In section 8.1 of the TreeCache documentation (and related
docs/design/EvictionPolicy.txt), it says that when a node is evicted, it will
only be removed if it does not have children.
I understand why this is desirable in some cases, but I have a slightly
different requirement.
In my case,
I have successfully used the stand-alone implementation of remoting 1.0.1 beta
in a prototype and now want to replace the stand-alone server with JBoss AS
4.0.1
Research / trial and error led me to the need to replace jboss-common.jar in
{JBOSS_HOME}\lib with the one distributed with the stand-
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20050213044233Lbuild.87
BUILD COMPLETE - build.87Date of build: 02/13/2005 04:42:33Time to build: 43 minutes 35 secondsLast changed: 02/12/2005 19:04:38Last log entry: Update the get
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-jdk-matrix?log=log20050213035754Lbuild.54
BUILD COMPLETE - build.54Date of build: 02/13/2005 03:57:54Time to build: 23 minutes 21 seconds
Unit Tests: (0) Tot
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20050213013339Lbuild.70
BUILD COMPLETE - build.70Date of build: 02/13/2005 01:33:39Time to build: 99 minutes 36 seconds
Unit Tests: (1936) T
18 matches
Mail list logo