RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJB Container] - Problemwith order of entity cache operations with Hibernate
by Brian Stansberry
+10 on JBC/Hibernate integration testing.
The EJB3 testsuite has one test in this area, which luckily uncovered
the issue. Only uses the TM that's integrated in the AS; it was a lucky
hit.
There should be more EJB3 tests as well, but the primary place for it
should be in Hibernate/JBC. E.g. this issue quite likely impacts
non-EJB3 Hibernate as well.
That's how we find such a thing. Anyone have any good thoughts on what
to do about it? Perhaps Hibernate exposes something like JBC's
OrderedSynchronizationHandler, which the JBC integration can use to
insert it's synchronization at the correct point?
Manik Surtani wrote:
> Hmm, the *correct* approach to dealing with this would be to
> put together a series of integration tests for JBoss Cache
> and Hibernate, exercising such scenarios with different TMs,
> and making sure these are run with every release of Hibernate
> and JBC. Either that, or we assume the EJB3 test suite
> covers this, and I presume this is how you uncovered this issue?
>
>
>> FYI; just posted on the EJB3 forum.
>>
>> bstansberry(a)jboss.com wrote:
>>> There appears to be a difference in behavior between JBossTM and
>>> JBossTS that's leading to failures with JBoss Cache as the 2nd
>>> level entity cache.
>>>
>>> JBC handles replication of transaction-scoped cache changes by
>>> registering as a transaction Synchronization and replicating the
>>> changes during the beforeCompletion() callback. This is failing
>>> with JBossTS because the beforeCompletion() callback is being
>>> executed *before* the Hibernate flush activity that updates the
>>> cache. No activity at time of beforeCompletion() == no
>>> replication of the tx's changes.
>>>
>>> 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Running
>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
>>> 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up
>>> transactional context. 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
>>> TransactionImple < ac, BasicAction:
> -3f57ff9b:a5b:455d4cd6:10 status:
>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
>>> 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] No
>>> modifications in this tx. Skipping beforeCompletion() 2006-11-16
>>> 23:48:41,250 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] processing
>>> flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>> [org.hibernate.engine.Collections] Collection found:
>>> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
>>> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>> 23:48:41,265 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1
>>> (re)creations, 0 updates, 0 removals to 1 collections ...
>>> followed by puts into the cache
>>>
>>> When I switched the AS back to using JBossTM, the problem went away
>>> -- the Hibernate flush activity occurred first, and then the
>>> beforeCompletion() call to JBC.
>>>
>>> I'm speculating that Hibernate is also using a Synchronization to
>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>> registered Synchronizations in a different order.
>>>
>>> At this point, replication of clustered EJB3 entities is basically
>>> broken.
>>>
>>> View the original post :
>>>
>> http://www.jboss.com/index.html?
>> module=bb&op=viewtopic&p=3986745#3986745
>>>
>>> Reply to the post :
>>>
>> http://www.jboss.com/index.html?
>> module=bb&op=posting&mode=reply&p=398674
>> 5
>>> _______________________________________________
>>> jboss-dev-forums mailing list
>>> jboss-dev-forums(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 5 months
Updating documentation for JBC 2.0.0
by Manik Surtani
Guys,
Please have a look at JBCACHE-764 [1] which summarises my thoughts
for better documentation in JBoss Cache 2.0.0. Let me know what you
think. In the end we want something that is a bit more cohesive than
the current docs [2], but not being nearly as verbose as the current
set (especially sections like eviction policies [3]).
Hopefully I will have time to get a skeleton of such updated docs in
place next week and in time for ALPHA2, most of the content should
just be re-writes from the current docs with relevant updates.
[1] http://jira.jboss.com/jira/browse/JBCACHE-764
[2] http://labs.jboss.com/file-access/default/members/jbosscache/
freezone/docs/1.4.1/TreeCache/en/html/index.html
[3] http://labs.jboss.com/file-access/default/members/jbosscache/
freezone/docs/1.4.1/TreeCache/en/html/eviction_policies.html
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 5 months
RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
by Galder Zamarreno
+1
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:msurtani@redhat.com]
Sent: 07 November 2006 10:01
To: Galder Zamarreno
Cc: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
Hi,
Interesting that enabling a marshaller even helps with non-replicated
cases where a marshaller is NOT needed! :-)
I suspect this is emergent behaviour since enabling the marshaller
allows you to attach classloaders for regions (throws exceptions
otherwise). So the *intended* behaviour is for this to work with
replication only; if we want to make this a *feature* (and I suspect
we do) we should refactor and document accordingly.
If we have a UT for this and know that this works, we could add a FAQ
for this for the 1.4.x series, and engineer it properly in 2.0.0.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: msurtani(a)redhat.com
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 3 Nov 2006, at 13:05, Galder Zamarreno wrote:
> In this specific case, it was a second level cache for EJB3 entity
> beans, so I guess there's not much of a problem in evicting on
> undeployment.
>
> This is a different use case to the one where you start JBC, state
> transfer occurs and you don't have all the classloaders.
>
> I guess another use for marshalling would be with isolated
> deployments, where JBC classloader is located in the default
> repository and u have several isolated applications populating that
> cache.
>
> However, in this particular case about 2nd level cache
> redeployment, do you think it's necessary to use marshalling? A
> simple evict everything on undeployment would be sufficient. What
> do you think?
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
> -----Original Message-----
> From: Brian Stansberry
> Sent: 02 November 2006 16:58
> To: Galder Zamarreno; 'jbosscache-dev(a)lists.jboss.org'
> Subject: RE: [jbosscache-dev] easing the path for clients to
> getaroundredeployment class loading issues in JBC
>
> Yeah, it works if it's OK that all the cached data was lost :-).
> With a replicated cache, the node going through redeploy evicts
> everything but can then recover it from another node. With local
> cache, it's evicted and gone. Actually, not technically evicted,
> just removed w/o going through the interceptor chain.
>
> If they want to keep the cached data, they'd need to store it in
> the cache as a byte[] or something and deserialize after redeploy.
> Or, use a non-passivating cache loader and recover from the cache
> loader. Or use a passivating cache loader and manually evict()
> each node before undeploying.
>
> Don't think I'll document this particular use, because calling
> inactivateRegion() as a shortcut for calling evict() is not really
> what the method's meant for. But I'm sure the docs in general on
> how to use this could be improved.
>
> Galder Zamarreno wrote:
>> I have just tried it with a local cache and it worked.
>>
>> One of the customers was using JBC 1.0, so the work was not in
>> vain :)
>>
>> It might be worth adding the redeployment case to the
>> documentation in the marshaller section.
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>> Galder Zamarreno
>> Sent: 02 November 2006 16:31
>> To: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
>> Subject: RE: [jbosscache-dev] easing the path for clients to
>> getaroundredeployment class loading issues in JBC
>>
>> I did suggest this to Manik, but he told me that marshalling
>> would not work on local caches, but only in replicated ones.
>> I might have misunderstood him.
>>
>> The doc focuses on the state transfer issues when class
>> loaders are not still available.
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: 02 November 2006 15:58
>> To: Galder Zamarreno; jbosscache-dev(a)lists.jboss.org
>> Subject: RE: [jbosscache-dev] easing the path for clients to
>> get aroundredeployment class loading issues in JBC
>>
>> There's already an API for this kind of use case. I'm going
>> to speak in 1.x terms here:
>>
>> // Config for cache startup
>> TreeCache.setUseRegionBasedMarshalling(true);
>> TreeCache.inactiveOnStartup(true); // suppresses initial
>> state transfer
>>
>> // Deploy phase -- app creates a region and registers it's
>> classloader TreeCache.registerClassloader(Fqn, ClassLoader);
>> // Then transfer the state for the region, since you've now
>> go the correct classloader TreeCache.activateRegion(Fqn);
>>
>> // Operate normallly
>>
>> // Undeploy phase -- deactivate the region, which evicts all nodes
>> TreeCache.inactivateRegion(Fqn)
>> // Don't leak a classloader ref
>> TreeCache.unregisterClassloader(Fqn);
>>
>> - Brian
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> Hi,
>>>
>>> I have seen couple of people with the same issue in the past few
>>> weeks. I already had a chat with Manik but it was more about solving
>>> the problem at the time rather than thinking how we can make it
>>> easier for the customers to get around it.
>>>
>>> Applications which are redeployed and interact with the cache are
>>> quite likely to encounter class loading issues. They tend to enter
>>> data in the cache, they get redeployed, try accessing the data
>>> entered previously and you end up with a ClassCastException.
>>>
>>> For caches managed by Hibernate, this is not a problem cos Hibernate
>>> does the cleanup on undeployment, asking clients to close the
>>> session.
>>>
>>> In the rest of cases, clients have to iterate over evict() calls.
>>> This will be solved in JBC 2.0 with evictSubtree() method that can
>>> be recursive.
>>>
>>> However, clients still need to code an MBean which is part of the
>>> lifecycle of the deployment, and upon destroy, it calls
>>> evictSubtree().
>>>
>>> The cache configuration would have to depend on this MBean in case
>>> the cache deployment is done inside the client's application.
>>> Otherwise, we could assume that undeployment of JBC is quite likely
>>> due to AS undeployment in which case there's no need for cleanup.
>>>
>>> Have you got any ideas of anything else that could be done in JBC to
>>> help speed up this implementation and make it less of daunting task
>>> for the customer?
>>>
>>> I guess the main part is documenting all this.
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 5 months
JBossCache_2_0_0_ALPHA1 tagged.
by Manik Surtani
... and ready to go.
Brian, do you want to take it from here to get this into AS5 beta?
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 5 months
FW: [jboss-dev-forums] [Design of the JBoss EJB Container] - Problemwith order of entity cache operations with Hibernate
by Brian Stansberry
FYI; just posted on the EJB3 forum.
bstansberry(a)jboss.com wrote:
> There appears to be a difference in behavior between JBossTM and
> JBossTS that's leading to failures with JBoss Cache as the 2nd level
> entity cache.
>
> JBC handles replication of transaction-scoped cache changes by
> registering as a transaction Synchronization and replicating the
> changes during the beforeCompletion() callback. This is failing with
> JBossTS because the beforeCompletion() callback is being executed
> *before* the Hibernate flush activity that updates the cache. No
> activity at time of beforeCompletion() == no replication of the tx's
> changes.
>
> 2006-11-16 23:48:41,250 TRACE
> [org.jboss.cache.interceptors.TxInterceptor] Running beforeCompletion
> on gtx GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
> 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor]
> Setting up transactional context. 2006-11-16 23:48:41,250 TRACE
> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
> TransactionImple < ac, BasicAction: -3f57ff9b:a5b:455d4cd6:10 status:
> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
> 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] No
> modifications in this tx. Skipping beforeCompletion() 2006-11-16
> 23:48:41,250 DEBUG
> [org.hibernate.event.def.AbstractFlushingEventListener] processing
> flush-time cascades 2006-11-16 23:48:41,250 DEBUG
> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
> checking collections 2006-11-16 23:48:41,265 DEBUG
> [org.hibernate.engine.Collections] Collection found:
> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
> (initialized) 2006-11-16 23:48:41,265 DEBUG
> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
> 23:48:41,265 DEBUG
> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1
> (re)creations, 0 updates, 0 removals to 1 collections ...
> followed by puts into the cache
>
> When I switched the AS back to using JBossTM, the problem went away
> -- the Hibernate flush activity occurred first, and then the
> beforeCompletion() call to JBC.
>
> I'm speculating that Hibernate is also using a Synchronization to
> manage the flush, and that JBossTA and JBossTS make the calls to
> registered Synchronizations in a different order.
>
> At this point, replication of clustered EJB3 entities is basically
> broken.
>
> View the original post :
>
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986745#3986745
>
> Reply to the post :
>
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=398674
5
> _______________________________________________
> jboss-dev-forums mailing list
> jboss-dev-forums(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
17 years, 5 months
RE: JBoss 2.0.0.alpha2
by Ben Wang
Yes, I have verified AOP 2.0.ALPHA2 will work with JBC head fine. So I have gone ahead and check it in. We will deal with version incompatability after next week when the AS 5 "beta" is out.
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, November 17, 2006 8:43 AM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Fwd: JBoss 2.0.0.alpha2
Ben, do you want to incorporate this into HEAD and see if it works ok with PojoCache builds?
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
Begin forwarded message:
> From: "Kabir Khan" <kabir.khan(a)jboss.com>
> Date: 16 November 2006 21:41:35 GMT
> To: "'Brian Stansberry'" <brian.stansberry(a)jboss.com>, "'JBoss.org
> development list'" <jboss-development(a)lists.jboss.org>
> Cc: "'Dimitris Andreadis'" <dimitris(a)jboss.org>, "'Manik Surtani'"
> <manik.surtani(a)jboss.com>, "'Ben Wang'" <ben.wang(a)jboss.com>
> Subject: JBoss 2.0.0.alpha2
>
> I have tagged JBoss 2.0.0.alpha2 in svn, and added the jars to the
> thirdparty repository. I've updated the microcontainer and jboss trunk
> builds to use this new version. All jboss testsuite tests not
> involving EJB
> 2 pass.
>
> I'll look at creating a standalone download next week, since since the
> past release we are now using jboss retro for JDK 1.4 support, which
> has implications for packaging for JBoss 4 which I have not had the
> time to investigate.
>
> Cheers,
>
> Kabir
>
>> -----Original Message-----
>> From: Brian Stansberry [mailto:brian.stansberry@jboss.com]
>> Sent: 16 November 2006 19:17
>> To: jbosscache-dev(a)lists.jboss.org
>> Cc: Kabir Khan; Dimitris Andreadis
>> Subject: FW: [jbosscache-dev] 2.0.0.Alpha is close
>>
>> Posting Kabir's reply to the list. Kabir, I'll defer to Manik/Ben on
>> the timing question.
>>
>> Kabir Khan wrote:
>>> I was planning on tagging an aop 2.0.0.alpha2 release tomorrow
>>> lunchtime (GMT). (Please forward to your list as I cannot
>> post there).
>>> Is this too late for you? If it is, I might be able to do it later
>>> tonight.
>>>
>>>> -----Original Message-----
>>>> From: Brian Stansberry [mailto:brian.stansberry@jboss.com]
>>>> Sent: 16 November 2006 18:57
>>>> To: Manik Surtani; jbosscache-dev(a)lists.jboss.org
>>>> Cc: Kabir Khan; Dimitris Andreadis
>>>> Subject: RE: [jbosscache-dev] 2.0.0.Alpha is close
>>>>
>>>> We need to resolve last night's question of the jboss-aop
>> release to
>>>> integrate for this alpha. Not a final resolution (it's an alpha,
>>>> after all), but something. AS 5 needs a tagged release that when
>>>> built will produce a jar that works in the AS.
>>>>
>>>> My recommendation is we incorporate the AS's
>> jboss-aop-jdk50.jar in
>>>> JBC HEAD. The main purpose of this alpha is for AS 5
>> integration, so
>>>> at this point I think the jar that AS 5 needs should be the one
>>>> that's bundled in JBC. We can always come up with a more complex
>>>> solution later.
>>>>
>>>> Problem is, the AS's jboss-aop-jdk50.jar is a snapshot.
>> I'm assuming
>>>> it's going to be replaced with a tagged release soon
>> (Kabir??). So,
>>>> there is a timing issue.
>>>>
>>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>>> Getting very close to being able to tag this alpha. I'm taking a
>>>>> cpl of hrs break (attending this:
>> http://www.red-bean.com/ospowiki/
>>>>> LondonOpenSourceJam) while the entire test suite runs on
>> dev02. I
>>>>> expect 3 or 4 eviction based tests to still fail which I
>> will look
>>>>> into when I return.
>>>>>
>>>>> Will probably tag it first thing tomorrow AM (about 10:00
>>>>> GMT) though, so gives you folk in the US a bit more time
>> if you want
>>>>> to get something more in.
>>>>>
>>>>> Cheers,
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
>>
>> IT executives: Red Hat still #1 for value
>> http://www.redhat.com/promo/vendor/
>>
>
>
17 years, 5 months
Fwd: JBoss 2.0.0.alpha2
by Manik Surtani
Ben, do you want to incorporate this into HEAD and see if it works ok
with PojoCache builds?
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
Begin forwarded message:
> From: "Kabir Khan" <kabir.khan(a)jboss.com>
> Date: 16 November 2006 21:41:35 GMT
> To: "'Brian Stansberry'" <brian.stansberry(a)jboss.com>, "'JBoss.org
> development list'" <jboss-development(a)lists.jboss.org>
> Cc: "'Dimitris Andreadis'" <dimitris(a)jboss.org>, "'Manik Surtani'"
> <manik.surtani(a)jboss.com>, "'Ben Wang'" <ben.wang(a)jboss.com>
> Subject: JBoss 2.0.0.alpha2
>
> I have tagged JBoss 2.0.0.alpha2 in svn, and added the jars to the
> thirdparty repository. I've updated the microcontainer and jboss trunk
> builds to use this new version. All jboss testsuite tests not
> involving EJB
> 2 pass.
>
> I'll look at creating a standalone download next week, since since
> the past
> release we are now using jboss retro for JDK 1.4 support, which has
> implications for packaging for JBoss 4 which I have not had the
> time to
> investigate.
>
> Cheers,
>
> Kabir
>
>> -----Original Message-----
>> From: Brian Stansberry [mailto:brian.stansberry@jboss.com]
>> Sent: 16 November 2006 19:17
>> To: jbosscache-dev(a)lists.jboss.org
>> Cc: Kabir Khan; Dimitris Andreadis
>> Subject: FW: [jbosscache-dev] 2.0.0.Alpha is close
>>
>> Posting Kabir's reply to the list. Kabir, I'll defer to
>> Manik/Ben on the timing question.
>>
>> Kabir Khan wrote:
>>> I was planning on tagging an aop 2.0.0.alpha2 release tomorrow
>>> lunchtime (GMT). (Please forward to your list as I cannot
>> post there).
>>> Is this too late for you? If it is, I might be able to do it
>>> later tonight.
>>>
>>>> -----Original Message-----
>>>> From: Brian Stansberry [mailto:brian.stansberry@jboss.com]
>>>> Sent: 16 November 2006 18:57
>>>> To: Manik Surtani; jbosscache-dev(a)lists.jboss.org
>>>> Cc: Kabir Khan; Dimitris Andreadis
>>>> Subject: RE: [jbosscache-dev] 2.0.0.Alpha is close
>>>>
>>>> We need to resolve last night's question of the jboss-aop
>> release to
>>>> integrate for this alpha. Not a final resolution (it's an alpha,
>>>> after all), but something. AS 5 needs a tagged release that when
>>>> built will produce a jar that works in the AS.
>>>>
>>>> My recommendation is we incorporate the AS's
>> jboss-aop-jdk50.jar in
>>>> JBC HEAD. The main purpose of this alpha is for AS 5
>> integration, so
>>>> at this point I think the jar that AS 5 needs should be the one
>>>> that's bundled in JBC. We can always come up with a more complex
>>>> solution later.
>>>>
>>>> Problem is, the AS's jboss-aop-jdk50.jar is a snapshot.
>> I'm assuming
>>>> it's going to be replaced with a tagged release soon
>> (Kabir??). So,
>>>> there is a timing issue.
>>>>
>>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>>> Getting very close to being able to tag this alpha. I'm taking a
>>>>> cpl of hrs break (attending this:
>> http://www.red-bean.com/ospowiki/
>>>>> LondonOpenSourceJam) while the entire test suite runs on
>> dev02. I
>>>>> expect 3 or 4 eviction based tests to still fail which I
>> will look
>>>>> into when I return.
>>>>>
>>>>> Will probably tag it first thing tomorrow AM (about 10:00
>>>>> GMT) though, so gives you folk in the US a bit more time
>> if you want
>>>>> to get something more in.
>>>>>
>>>>> Cheers,
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
>>
>> IT executives: Red Hat still #1 for value
>> http://www.redhat.com/promo/vendor/
>>
>
>
17 years, 5 months
FW: [jbosscache-dev] 2.0.0.Alpha is close
by Brian Stansberry
Posting Kabir's reply to the list. Kabir, I'll defer to Manik/Ben on
the timing question.
Kabir Khan wrote:
> I was planning on tagging an aop 2.0.0.alpha2 release tomorrow
> lunchtime (GMT). (Please forward to your list as I cannot post
> there). Is this too late for you? If it is, I might be able to do it
> later tonight.
>
>> -----Original Message-----
>> From: Brian Stansberry [mailto:brian.stansberry@jboss.com]
>> Sent: 16 November 2006 18:57
>> To: Manik Surtani; jbosscache-dev(a)lists.jboss.org
>> Cc: Kabir Khan; Dimitris Andreadis
>> Subject: RE: [jbosscache-dev] 2.0.0.Alpha is close
>>
>> We need to resolve last night's question of the jboss-aop release to
>> integrate for this alpha. Not a final resolution (it's an alpha,
>> after all), but something. AS 5 needs a tagged release that when
>> built will produce a jar that works in the AS.
>>
>> My recommendation is we incorporate the AS's jboss-aop-jdk50.jar in
>> JBC HEAD. The main purpose of this alpha is for AS 5 integration, so
>> at this point I think the jar that AS 5 needs should be the one
>> that's bundled in JBC. We can always come up with a more complex
>> solution later.
>>
>> Problem is, the AS's jboss-aop-jdk50.jar is a snapshot. I'm assuming
>> it's going to be replaced with a tagged release soon (Kabir??). So,
>> there is a timing issue.
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> Getting very close to being able to tag this alpha. I'm taking a
>>> cpl of hrs break (attending this: http://www.red-bean.com/ospowiki/
>>> LondonOpenSourceJam) while the entire test suite runs on dev02. I
>>> expect 3 or 4 eviction based tests to still fail which I will look
>>> into when I return.
>>>
>>> Will probably tag it first thing tomorrow AM (about 10:00
>>> GMT) though, so gives you folk in the US a bit more time if you
>>> want to get something more in.
>>>
>>> Cheers,
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
17 years, 5 months
RE: [jbosscache-dev] 2.0.0.Alpha is close
by Brian Stansberry
We need to resolve last night's question of the jboss-aop release to
integrate for this alpha. Not a final resolution (it's an alpha, after
all), but something. AS 5 needs a tagged release that when built will
produce a jar that works in the AS.
My recommendation is we incorporate the AS's jboss-aop-jdk50.jar in JBC
HEAD. The main purpose of this alpha is for AS 5 integration, so at
this point I think the jar that AS 5 needs should be the one that's
bundled in JBC. We can always come up with a more complex solution
later.
Problem is, the AS's jboss-aop-jdk50.jar is a snapshot. I'm assuming
it's going to be replaced with a tagged release soon (Kabir??). So,
there is a timing issue.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Getting very close to being able to tag this alpha. I'm
> taking a cpl of hrs break (attending this:
> http://www.red-bean.com/ospowiki/
> LondonOpenSourceJam) while the entire test suite runs on
> dev02. I expect 3 or 4 eviction based tests to still fail
> which I will look into when I return.
>
> Will probably tag it first thing tomorrow AM (about 10:00
> GMT) though, so gives you folk in the US a bit more time if
> you want to get something more in.
>
> Cheers,
17 years, 5 months