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

[Design of JBoss Collaboration Server] - Re: Current status of Project

by sappenin

anonymous wrote : Seriously though, we are looking to replace our qmail implementation no later than 1Q 2007 and would love to use a Java based mail solution. At a minimum we need IMAP and processing rules sufficient to explode mail to multiple recipients. Virtual domain support would be great too. Andy, Ametzger, Not sure what was discussed "offline", but if any parties are interested, I've been developing on JBMS for the past year, and am open to contributing/consulting....I just need to get a paycheck in order to contribute more than occasionally. David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989455#3989455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989455

19 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : | Problem with this is it requires an integration layer to register the classloader, manage the lifecycle, etc. It's also built around an assumption that different regions of the cache use different classloaders. Overly complex and painful for a simple ear that wants to deploy a cache from the ear and use it. | | It would be nice to make it easy for a user to specify during the configuration stage that the TCCL should be registered as the classloader for the entire cache and that the ordinary create/destroy lifecycle methods should deal with the classloader. | 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 an independent distributed cache usage outside of any ejb3/hibernate/session usage? I guess I'm not clear on what the point of this thread is. The only concern it raises is that if we are promoting indpendent use of jboss cache, it leads to an obvious conflict of versions when an ear is trying to deploy a version of jboss cache that differs from that bundled with the server. This either requires obfuscation of the package names or very careful control of the container class loading setup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989454#3989454 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989454

19 years, 4 months

1
0
0 / 0

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

by bstansberry＠jboss.com

JBC does have a mechanism for encapsulating the classloading aspect (TreeCacheMarshaller) and an API for code that uses it to register the classloader and manage the lifecycle. We need to be sure to use this mechanism for our own services that use JBC (i.e. doing that in Hibernate is the fix for JBCLUSTER-150.) Problem with this is it requires an integration layer to register the classloader, manage the lifecycle, etc. It's also built around an assumption that different regions of the cache use different classloaders. Overly complex and painful for a simple ear that wants to deploy a cache from the ear and use it. It would be nice to make it easy for a user to specify during the configuration stage that the TCCL should be registered as the classloader for the entire cache and that the ordinary create/destroy lifecycle methods should deal with the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989444#3989444 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989444

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Page navigational state update

by roy.russo＠jboss.com

I think this was fixed. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989439#3989439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989439

19 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

We need to separate services from runtime aspects tied to what are in general type scoped contexts. If an aspect needs to deal with typed data associated with a potentially scoped deployment, that aspect has to be presented the class loader to use. It also needs to have a life-cycle associated with the deployment as it needs to be recycled if the type system needs to be updated. In the past we hid these type issues by encapsulating the data in MarshalledObject/MarshalledValue instances so that the common service layers did not in fact see the type. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989422#3989422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989422

19 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Problems with replicating entity queries via JBC

by bstansberry＠jboss.com

Thread for the classloader idea is http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95862. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989419#3989419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989419

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Default classloader for deserialization

by bstansberry＠jboss.com

Right now the default classloader JBC uses for deserializing RPC calls is the CL that loads RpcDispatcher. This thread is to discuss if that's the correct choice. 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. The same effect can be achieved by using the region API and registering the deployment CL for region "/", but: 1) That requires programmatic intervention; a simple -service.xml deployment is insufficient. 2) If forces use of VersionAwareMarshaller, i.e. serializing a region Fqn at the head of each RPC call. Extra overhead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989418#3989418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989418

19 years, 4 months

1
0
0 / 0

[Design of JBossXB] - Need a valid jbossxb release to the maven repo

by scott.stark＠jboss.org

So we don't have a valid release of jbossxb in the maven repo as the jbossxb-1.0.1.TEST release has bogus dependencies on common artifacts. As part of http://jira.jboss.com/jira/browse/JBXB-91, it seems we need a JBossXB-1.0.0.CR8 release just to fix this. I want to take the https://svn.jboss.org/repos/common/jbossxb/tags/1.0.0.CR7/ tag and just correct the dependencies and maven settings to create the valid release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989417#3989417 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989417

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

by mark.little＠jboss.com

"bill.burke(a)jboss.com" wrote : Our JCA implementation already does this: | | log.warn("Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure."); | I'll talk to the team tomorrow, but how to implement it and what to issue in terms of warnings is straightforward. But it will come with some vary clear references to the docs which will explain what's going on. Supporting this makes me uncomfortable. Adding text and warnings so try to prevent users from doing this makes me less uncomfortable ;-) anonymous wrote : | I thought this message had been turned off, I guess it was just clarified I think the old message was something very cryptic like: | | "You are not getting the behavior you expect" | | And this confused the shit outta people. | Yes, that's not a good warning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989415#3989415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989415

19 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"anil.saldhana(a)jboss.com" wrote : Not totally. All the xxx.xxx.TEST maven stuff is what Ruel did for POC. | | So those projects need to have a formal maven release into the repo and all the xxx.TEST stuff thrown away. Yes. jbossxb has no valid maven release so I'll see what I can do about that today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989414#3989414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989414

19 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006