On demand JCA and JTA for the web-profile
by Adrian Brock
See:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189122#4189122
This will be the first real use of the "new" on-demand processing.
The idea is that unless the webapp looks up a user transaction
or transaction synchronization registry (there's a sticking point
there) or the admin deploys a transactional datasource,
then jca and jta won't bootstrap by default.
This won't effect the other configurations since we always provide
a transactional datasource out-of-the-box for jms persistence
and other services reference the transaction manager anyway
so they will always bootstrap.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 2 months
Help fix the testsuite or we rollback to r79434
by Dimitris Andreadis
The status of the testsuite has been deteriorating since the build of Oct 14th:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
http://anonsvn.jboss.org/repos/jbossas/trunk : 79434
For everyone that checked in stuff since then (akostadinov, alesj, ALRubinger, dimitris,
bstansberry, kabir, scott, emuckenhuber, anil, remy), if the testsuite runs do not improve
by Monday, I'll rollback to r79434.
/D
15 years, 7 months
metadata 1.0.0.CR9
by Alexey Loubyansky
I didn't make it GA since there is still the issue with
[default-]activation-config.
In CR9 I went through the classes that are annotated with XmlType and
added propOrder to avoid inconsistencies between schema specified
element ordering and Java annotation processing. Except
metadata.rar.jboss.mcf package. Is jboss-ds_5_0.dtd maintained and up to
date? If so I'll fix propOrder there as well for the GA, otherwise the
JCA team should take care of it.
The AS trunk has been updated to use metadata 1.0.0.CR9.
Alexey
15 years, 8 months
remaining AS5 updates
by Dimitris Andreadis
Upgrade EJB3 to its final version for AS5 Carlo
Upgrade jpa-deployers to 1.0.0.GA Carlo
Upgrade jboss-metadata to 1.0.0.GA Alexey
Upgrade seam-integration to 5.0.0.GA Ales
Upgrade jboss-microcontainer to 2.0.0.GA Ales
Upgrade jboss-deployers to 2.0.0.GA Ales
Upgrade jboss-classloading to 2.0.0.GA Ales
Upgrade JBoss Cache to 3.0.1.GA Brian
/D
15 years, 8 months
WebIntegrationUnitTestCase
by Dimitris Andreadis
The org.jboss.test.web.test.WebIntegrationUnitTestCase passes when run under jdk5, but break
under jdk6:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Something to do with the xml parsing:
vfszip:/qa/hudson_ws/workspace/JBoss-AS-5.0.x-TestSuite-jrockit16-jrockit16/trunk/testsuite/output/lib/jbosstest-web.ear
-> org.jboss.xb.binding.JBossXBRuntimeException: Requested element
{http://java.sun.com/xml/ns/j2ee}description is not allowed in this position in the
sequence. The next element should be {http://java.sun.com/xml/ns/j2ee}role-name
15 years, 8 months
Braindead logging WAS [Fwd: [jboss-cvs] JBossAS SVN: r81764 - trunk/server/src/main/org/jboss/deployment.]
by Adrian Brock
Why? Do you know how inefficient it is to invoke
isXXXEnabled() inside a loop?
This thing gets invoked for every file/subdeployment
that gets deployed and for each one iterates over a big list
of things to ignore.
-------- Forwarded Message --------
From: jboss-cvs-commits(a)lists.jboss.org
Reply-To: jboss-cvs-commits(a)lists.jboss.org
To: jboss-cvs-commits(a)lists.jboss.org
Subject: [jboss-cvs] JBossAS SVN: r81764 -
trunk/server/src/main/org/jboss/deployment.
Date: Fri, 28 Nov 2008 06:50:47 -0500
Author: alesj
Date: 2008-11-28 06:50:46 -0500 (Fri, 28 Nov 2008)
New Revision: 81764
Modified:
trunk/server/src/main/org/jboss/deployment/FileNameVirtualFileFilter.java
Log:
Undo Adrian's 'fix'.
Modified: trunk/server/src/main/org/jboss/deployment/FileNameVirtualFileFilter.java
===================================================================
--- trunk/server/src/main/org/jboss/deployment/FileNameVirtualFileFilter.java 2008-11-28 10:55:58 UTC (rev 81763)
+++ trunk/server/src/main/org/jboss/deployment/FileNameVirtualFileFilter.java 2008-11-28 11:50:46 UTC (rev 81764)
@@ -58,8 +58,6 @@
*/
public boolean accepts(VirtualFile file)
{
- boolean trace = log.isTraceEnabled();
-
String pathName = file.getPathName();
for (Map.Entry<String, Set<String>> entry : excludes.entrySet())
{
@@ -70,7 +68,7 @@
Set<String> value = entry.getValue();
if (value == null || value.contains(simpleName))
{
- if (trace)
+ if (log.isTraceEnabled())
log.trace("Excluding " + pathName);
return false;
_______________________________________________
jboss-cvs-commits mailing list
jboss-cvs-commits(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-cvs-commits
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 8 months
SchedulerUnitTestCase
by Adrian Brock
I've tried to make this test more robust to timing issues.
Basically I've multiplied the times between events by 10
so each "tick" of the test is now 5 seconds.
I also modified the test such that it does its assertions
"halfway" between the events.
e.g.
Time - event
0.0 - notification 1
2.5 - check notification 1
5.0 - notification 2
7.5 - check notification 2
etc.
That should hopefully avoid the assertions happening
at about the same time as the events themselves
(or more accurately with the previous code the next one)
and therefore randomly seeing the wrong state.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 8 months
Weird svn Hudson error
by Carlo de Wolf
Has anyone seen this before? I've run out of work-arounds.
started
Checking out svn://anar/anonsvn.jboss.org-jbossas/projects/ejb3/trunk
ERROR: Failed to check out svn://anar/anonsvn.jboss.org-jbossas/projects/ejb3/trunk
org.tmatesoft.svn.core.SVNException: svn: Failed to find time on revision 61293
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:63)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:50)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.handleFailureStatus(SVNReader.java:261)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:240)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:270)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.read(SVNRepositoryImpl.java:1267)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getDatedRevision(SVNRepositoryImpl.java:186)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:426)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:808)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:483)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:428)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:410)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:406)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:483)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:413)
at hudson.FilePath.act(FilePath.java:363)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:398)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:345)
at hudson.model.AbstractProject.checkout(AbstractProject.java:634)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:260)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:234)
at hudson.model.Run.run(Run.java:793)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:205)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:88)
finished: FAILURE
Carlo
15 years, 8 months
JBoss_5_0.xsd is wrong
by Adrian Brock
As part of a test of this
https://jira.jboss.org/jira/browse/JBAS-6013
I've created a test that uses the jboss_5_0.xsd
for an MDB.
The test works but the
org.jboss.test.xml.DDValidatorUnitTestCase
is saying my jboss.xml is invalid
The reason is that the xsd says I can't have
an <activation-config/> in jboss.xml
This is obviously wrong since it works
and JBossMessageDrivenMetaData has such an element.
In fact, there are many things you can now have
in jboss.xml (virtually anything from ejb-jar.xml)
that are not listed in this schema.
I'm going to commit this and leave it to somebody
working on the metadata project to fix the schema
and therefore the test.
Using this class
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/common/jbossxb/trunk/src/test/...
with the SchemaBinding created by the schema builder
will help in seeing the difference in the actual
versus the documented schema.
Under the new rules, I should be allowed to
break the testsuite if it shows something is broken.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 8 months
