November 2006 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: Cleaned up security project

by scott.stark＠jboss.org

Check that you can build trunk with the latest pom.xml. It has been updated to refer to the jbossxb-1.0.0.CR8 release which I created from the jbossxb-1.0.0.CR7 tag and just fixed the maven dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989530#3989530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989530

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by ben.wang＠jboss.com

"bstansberry(a)jboss.com" wrote : | Would the TCCL in effect when the cache was deployed be a better option? In the AS, this would likely be the default UCL for the deploy dir. If the cache was specifically deployed as part of an scoped ear or sar or even a webapp, it would be the deployment's CL. | I don't quite understand your proposal to handle "scoped" deployment though? Each scoped application will have their own UCL, isn't it? And this is deployment specific. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989525#3989525 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989525

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-880 discussion ...

by genman

It's actually pretty common to want to cache values with a per node TTL. Here are some references ... http://ehcache.sourceforge.net/javadoc/net/sf/ehcache/Element.html#setTim... http://forums.tangosol.com/thread.jspa?threadID=1041&tstart=75 http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/web/filt... I'm actually surprised this isn't supplied as a base expiration policy. I actually registered on the Tangosol to get this Javadoc: | com.tangosol.net | Interface NamedCache | | put | | Object put(Object oKey, | Object oValue, | long cMillis) | | Associates the specified value with the specified key in this cache and allows to specify an expiry for the cache entry. | And you want to vote on it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989519#3989519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989519

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by juha＠jboss.org

FYI, There's another slightly more subtle API change in JDBCPersistenceManager where retrievePreparedTransactions used to return List <Xid,> now returns List <PreparedTxInfo,> PreparedTxInfo is basically a pair <LocalTxId, Xid>. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989514#3989514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989514

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by bstansberry＠jboss.com

If I understand you correctly, that implies that internally the cache stores everything as a byte[] or MarshalledValue or some such. This includes the elements of Fqns, as these can also be typed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989502#3989502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989502

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by scott.stark＠jboss.org

That still sounds potentially too coarse. I would look at the cache as message oriented tree where a usage context has to bind a serialization manager to obtain a typed view of the cache data. When there are puts/gets to the cache, it needs to be done through the context "connection" to the cache messaging layer that has the correct serialization manager. I view a deployment wanting their own cache as wanting their own typed view, and namespace, but they may want to automagically integrate into the deployment env transport that binds distributed cache contexts together. Not overriding the transport/clustered configuration gets into being able to take a deployment and have it inherrit aspects of its environment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989494#3989494 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989494

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by bstansberry＠jboss.com

The region-based configuration thing is somewhat of a holdover from the pre-JGroups-multiplexer days, when a cache was an expensive object due to the need for its own JChannel. It allows multiple deployments with different type systems to use the same underlying cache, as long as they store their data in separate regions. HTTP session repl with FIELD granularity uses this, since MarshalledValue wouldn't work properly with what PojoCache needs. My instinct is that with the multiplexer it makes more sense to have an architecture where deployments that need a cache instantiate their own -- see comments on the second half of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93825 for some thoughts on this. But this takes some thought. It goes in the opposite direction, for example, from an idea Sacha raised last winter about having all data related to a Seam app be stored in the same cache so there could just be one replication event per request. JGroups does provide the needed hooks for applications to do marshalling/unmarshalling of messages as they see fit. JBC makes extensive use of these (as does HAPartition). So JGroups isn't naive in this respect. It's more that JBC is naive, if the overly complex region-based thing isn't used. anonymous wrote : The default configuration of the serialization aspect needs to be triggered by an application level aspect, which could pick up the app thread context class loader. OK, sounds like we're moving toward something like: 1) JBC exposes an API that allows registration of a default classloader but which doesn't trigger the whole region-based marshalling overhead. I suppose registration can be a simple setter in the Configuration object graph. 2) We have a wrapper class that in create() picks up the TCCL and registers it, then calls create on the cache. In destroy() it calls destroy() on the cache and then unregisters the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989478#3989478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989478

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by scott.stark＠jboss.org

Ok, then the disconnect is why control of serialization requires a region based configuration. The first problem would seem to be that even the typed rpc functionality of jgroups should have a serialization api that allows shared use of a channel with marshalling/unmarshalling of types based on application endpoints with different type systems. Serialization is an aspect of the user, not an inherent function of the jbc or jgroups. The default configuration of the serialization aspect needs to be triggered by an application level aspect, which could pick up the app thread context class loader. It seems we are picking up a naive standalone component behavior where serialization is an inherent function of the messaging layer. That is not the case for any service that needs to integrate into jbossas, esb, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989465#3989465 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989465

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by bstansberry＠jboss.com

This thread is about independent usage of JBC, not as part of ejb3/hibernate/httpsession repl where we have an integration layer that can take advantage of the existing region-based marshalling API. Here's the problem: EAR packages class Foo, and also deploys a JBC instance via a -service.xml or -beans.xml. Application places instances of Foo in the cache, which then get replicated. When the replication message is received, Foo needs to be deserialized. This is done by the thread coming up from JGroups. This deserialization is done using the classloader for server/all/lib, which is where the JBC and JGroups jars are located. Thus class Foo is not visible to the classloader. Replication fails with a CNFE. Same problem occurs with state transfer when a 2nd node joins a cluster where there's existing data. Solutions to this problem are: 1) Place Foo.class in server/all/lib. 2) Turn on region-based marshalling and register a classloader with the cache, effectively saying for example, for any replication traffic related to Fqn's below "/a", use this classloader to deserialize the message. If this feature is turned on, all replication messages consist of two components -- first a serialized Fqn that identifies which region the message pertains to (used by the recipient to look up the classloader) and then the regular serialized MethodCall. anonymous wrote : To me this is another wrapper that integrates well with this usage. Its an mbean service/mc bean that performs the same deployment level integration as the other jboss cache based aspects. This is one possible solution, and perhaps the best. The downside to it is it adds the overhead of including the region-identifier Fqn in each replication message -- which isn't really needed if there is only one correct classloader for the whole cache. So, the purpose of this thread is to explore that and possibly other solutions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989459#3989459 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989459

17 years, 10 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - The suspense is killing me...

by sappenin

Andy, Any chance you'll be contributing your MIME code back to the JBMS project? http://linuxintegrators.com/acoliver/code/?permalink=x-0288.html Also, the suspense is killing me?when can you talk about the new "goings on". David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989458#3989458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989458

17 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006