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

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

by bstansberry＠jboss.com

Seems this is only an issue when a scoped classloader is used. If one isn't used, the classloader that loaded JGroups sees the classes without any problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989571#3989571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989571

19 years, 4 months

1
0
0 / 0

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

by bstansberry＠jboss.com

"scott.stark(a)jboss.org" wrote : At some level, but it does not have to be the core. Having the namespace be typed and potentially scoped I'm sure complicates interaction of what might be shared/common aspects. If the cache is used in pure in memory mode, there should be no need to serialize the data. If you through in a cache loader, then you have another serialization path. It certainly needs the correct class loader, but its separate from the current jgroups message issue. Is there a common serialization abstraction for these two cases? | Currently no. There is some recent discussion around unifying this somewhat (see http://jira.jboss.com/jira/browse/JBCACHE-879.) I'm not aware of any serialization problems related to classloaders, presumably because cacheloader operations are typically performed by application threads where the TCCL has visibility to the required classes. That could certainly break down though in a more exotic use case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989552#3989552 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989552

19 years, 4 months

1
0
0 / 0

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

by bstansberry＠jboss.com

"ben.wang(a)jboss.com" wrote : | 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. The concept there was that if a cache was deployed as part of an ear with a scoped classloader, the default classloader for deserializing messages would be the ear's classloader. So the cache would be able to deserialize any class visible to the ear. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989551#3989551 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989551

19 years, 4 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Include= multiple packages?

by clebert.suconic＠jboss.com

thanks :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989548#3989548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989548

19 years, 4 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Runtime profiler operation

by clebert.suconic＠jboss.com

I believe you didn't close the files with a stop... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989547#3989547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989547

19 years, 4 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Include= multiple packages?

by bhazer

"clebert.suconic(a)jboss.com" wrote : Let me know if you have any problems. Thanks. It worked like a charm. Love the lighting fast replies on this forum. Notice how the thanks don't come as fast? Sorry View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989544#3989544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989544

19 years, 4 months

1
0
0 / 0

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

by anil.saldhana＠jboss.com

I can build the trunk. I am going to be creating the sub projects in security along the lines of common. Thanks for doing the xb release as well as the research on maven publish to repositories(we need that) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989543#3989543 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989543

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 : 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. At some level, but it does not have to be the core. Having the namespace be typed and potentially scoped I'm sure complicates interaction of what might be shared/common aspects. If the cache is used in pure in memory mode, there should be no need to serialize the data. If you through in a cache loader, then you have another serialization path. It certainly needs the correct class loader, but its separate from the current jgroups message issue. Is there a common serialization abstraction for these two cases? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989537#3989537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989537

19 years, 4 months

1
0
0 / 0

[Design of JBoss Build System] - Integrating with the maven repo

by scott.stark＠jboss.org

So as part of doing the jbossxb-1.0.0.CR8 release I dug a bit more into the maven deploy stuff so that I could deploy to the repository.jboss.com/maven2 cvs repository using mvn rather than copying files around. What I ended up doing is adding a local copy to file distributionManagement section withe a cvs-file-repository repository that references the local repository.jboss.com/maven2 cvs checkout: | ... | <distributionManagement> | <repository> | <id>cvs-file-repository</id> |  | <url>file://${maven.cvs.root}</url> | </repository> | </distributionManagement> | </project> | the maven.cvs.root is defined in the local settings.xml under a local-properties profile that is defined as active: | <settings> | <localRepository>/usr/Repository/maven2</localRepository> | <profiles> | <profile> | <id>local-properties</id> | <properties> | <maven.cvs.root>/usr/Repository/repository.jboss.com/maven2</maven.cvs.root> | </properties> | </profile> | </profiles> | | <activeProfiles> | <activeProfile>local-properties</activeProfile> | </activeProfiles> | </settings> | I still have to checkin the files via cvs. I guess the correct way is to move to using the mvn release:* plugins with full scm integration and a repository accessible via ssh rather than going through cvs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989534#3989534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989534

19 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

I created https://svn.jboss.org/repos/common/jbossxb/tags/1.0.0.CR8/ tag to fix the project maven dependencies and released this to the maven2 and jbossbuild repos. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989531#3989531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989531

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