I'm about to check in some changes to bring JPA 2 interfaces into AS
5_x. This will include jpa-api 2.0.Beta-2009081.
I'm also adding AS integration JPA-2 unit tests (JBAS-7376) that are
expected to fail until we complete the JPA 2 support.
There was a request from David, to reduce message size coming to
jboss-svn-commits email list to 250kB. Messages exceeding this limit
will be rejected.
Does anyone have any objection to this?
I built the latest 5_x branch today and tried some of the admin console
new features. New features look good, but one thing that i noticed was
that the logging has probably got worse from what it was earlier?
Every click on any of the links on the left hand side menu of the admin
console, now generates logs like these on the server console:
13:21:29,884 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:35,698 INFO [RuntimeDiscoveryExecutor] Running runtime discovery
scan rooted at [platform]
13:21:35,728 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:35,933 INFO [RuntimeDiscoveryExecutor] Scanned  servers and
found  total descendant Resources.
13:21:45,969 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:49,646 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:51,969 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:54,410 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:21:56,363 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:22:01,994 WARN [HtmlImageRendererBase] ALT attribute is missing for
13:22:05,847 WARN [HtmlImageRendererBase] ALT attribute is missing for
This is apart from the INFO/WARN logs that you notice during the first
login to the admin-console.
 The previous discussion about this
I'm starting on the VFS3 integration into JBossAS (trunk), and thus
branching AS and ultimately all subprojects using VFS (presently there's 11
such projects). This is a pretty big operation, so anyone who wants to
volunteer, feel free to pitch in!
The AS branch is: https://svn.jboss.org/repos/jbossas/branches/vfs3-integration
I'll be keeping this branch up to date with trunk as needed; new branches
will also be created in other subprojects.
Once things are stable, we'll be coordinating releases of all affected
projects at once. It should be interesting. :-)
-------- Original Message --------
Subject: [jboss-cvs] JBossAS SVN: r94625 - branches.
Date: Fri, 9 Oct 2009 18:14:50 -0400
Date: 2009-10-09 18:14:50 -0400 (Fri, 09 Oct 2009)
New Revision: 94625
The Big VFS3 Branch!
Copied: branches/vfs3-integration (from rev 94624, trunk)
Byteman release 1.1.1 is now available from
- consolidates the changes made in 1.1.0 to support dynamic rule
extending support for runtime management of the rule base and rule
simplifying invocation of apps using the agent via the bmjava script
- includes the first batch of a series of sample scripts
supporting JVM monitoring either from program start or via dynamic
rule load and unload
providing detailed feedback on operation of Thread, FileStream,
ClassLoader, and other JVM classes
- fixes about half a dozen small bugs in the 1.1.0 release
The next release of Byteman will be 1.2.0. This will address two related
features which are not currently supported:
- injection through interfaces into the methods of implementing classes
- injection down class hierarchies into overriding method implementations
It will also include the next batch of sample scripts, concentrating on
using byteman for debugging and testing.
On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
> When I discussed that with Gavin, I believe this idea is that you can
> implement the optimistic locking in the following way:
> - when locking an object read the version number (or if already
> loaded keep this one - not sure about that detail)
> - when flushing or right before commit, read the version number again
> from the database and compare.
> If they are different => exception
> A provider may but is not forced to acquire the lock
> Note that today we implement Optimistic in a pessimistic way (ie que
> acquire the DB lock right away).
> So there are three levels really
> no lock => we check versions upon UPDATE operations
> optimistic => we check versions on reads as well and verify consistency
> pessimistic => we lock at the DB level.
Currently, the Hibernate EM depends on Hibernate core for locking (as it
should). I have a few questions about how achieve the above locking
with Hibernate core and about what changes are needed.
The JPA 2 locking operations that we need support for are:
OPTIMISTIC (equal to READ) - should read the version initially and
confirm that it hasn't changed at transaction commit time. We should
throw OptimisticLockException if the version has changed. I think that
we need a new LockMode for this (similar to LockMode.READ). For
extended persistence context (meaning that the duration is beyond the
end of transaction), I think that we use the entity value from the
extended persistence context as is but should still confirm that it
hasn't changed at commit time (optimistically assume that it hasn't
OPTIMISTIC_FORCE_INCREMENT (equal to WRITE) - should read the version
initially. At transaction commit time, confirm that the version hasn't
changed as we increment it via update. We should throw
OptimisticLockException if the version has changed. I think that we
need a new LockMode for this (similar to LockMode.READ and
LockMode.FORCE). Same rules as above for extended persistence context.
PESSIMISTIC_WRITE - Should obtain a database write lock on the entity.
Hibernate LockMode.Upgrade could be used for this on dialects that
support it. For dialects that don't support LockMode.Upgrade, a
PessimisticLockException should be thrown.
PESSIMISTIC_READ - Should obtain a shared database read lock on the
entity (for the duration of the database transaction). How should we
support this? The JPA 2 specification allows the PESSIMISTIC_WRITE
behavior to be used.
PESSIMISTIC_FORCE_INCREMENT - Same as PESSIMISTIC_READ but with an
increment version at transaction commit time (even if entity isn't
updated). I think that we need a new LockMode for this. We need a way
to throw an exception if not supported.
For pessimistic locks, only lock element collections and relationships
owned by the entity, if property javax.persistence.lock.scope is set to
Assuming we do the above, we need to release note that READ/WRITE locks
are obtained in optimistic manner which is a change from our JPA 1 support.
Any volunteers willing to help with JPA 2 implementation (coding,
testing, moral support) are welcome to join in. :-)
The original message was received at Tue, 20 Oct 2009 07:41:47 -0400 from [18.104.22.168]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
... while talking to lists.jboss.org.:
>>> MAIL FROM:"Mail Administrator" <postmaster(a)lists.jboss.org>
<<< 505 "Mail Administrator" <postmaster(a)lists.jboss.org>... Refused
I have setup a cluster partition in Jboss and trying to retrieve HAPartition
object from ClusterPartition mbean. Below is my code:
ArrayList<MBeanServer> list = MBeanServerFactory.findMBeanServer(null);
for (MBeanServer server : list)
String onStr = "jboss:service=DefaultPartition";
ObjectName objectName = new ObjectName(onStr);
Set mbeans = server.queryMBeans(objectName, null);
Object partitionObj = server.invoke(theName, "getHAPartition",
org.jboss.ha.framework.server.HAPartitionImpl partition =
(org.jboss.ha.framework.server.HAPartitionImpl) partitionObj; //this line
The last line in above code is throwing ClasscastException: Cannot Cast
org.jboss.ha.framework.server.HAPartitionImpl cannot be cast to
I have same version of jbossha.jar in jboss lib and war's web-inf/lib
folder. I am not sure why it is throwing classcast exception. Any help is
Thanks in advance !!!
View this message in context: http://www.nabble.com/ClasscastException%3A-Cannot-Cast-org.jboss.ha.fram...
Sent from the JBoss - Dev mailing list archive at Nabble.com.