February 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: NPE in InvalidationInterceptor.getNodeVersion()

by bstansberry＠jboss.com

Been conversing with myself as I work through this. :-) More issues: http://jira.jboss.com/jira/browse/JBCACHE-1298 My proposed fix to JBCACHE-1298 is as follows: 1) CacheImpl.invalidate() should not create a tombstone if argument DataVersion versionToInvalidate is null. Just return. The cache is already in a state consistent with the intent of the invalidate() call; there's no need to do anything further. 2) If a tombstone does need to be created, the versionToInvalidate should be set as an Option when it is created, rather than putting in a possibly incompatible DefaultDataVersion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132635#4132635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132635

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by anil.saldhana＠jboss.com

Thomas, can you enable some trace on "org.jboss.system" and paste it here? The Security Deployer just deals with the MetaData and creates a top level service bean. It does not do any Classloader circus. There is something that is happening with your web service deployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132632#4132632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132632

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Another major issue I need to do for 5.0.0.RC1 is "refactoring" of the | deployers. Which also needs to include a test in the testsuite for a metadata only deployment (e.g. programmatic construction of a datasource) so we don't have issues like the one Thomas just raised: http://jira.jboss.com/jira/browse/JBAS-5257 with deployers assuming things they shouldn't. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132627#4132627 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132627

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by adrian＠jboss.org

I'm not doing it immediately ;-) Though I would like to get this done sooner rather than later. I still need to fix issues found with the integration of the latest changes into JBossAS. We haven't done a major release of the MC since just after beta3 (there wasn't one for beta4). e.g. Issues like: * classloader config changes (now that classloading is a real spi) * the thread context classloader usage (for beans and deployers) * AOP's use of the in memory vfs (now done properly in a seperate deployer) * etc. I also need to do an implementation of the modularised bootstrap and Tomcat using the classloading dependencies, at least to validate it is possible in a future release even if we don't do them for 5.0.0.GA (i.e. I have the basics correct :-) Another major issue I need to do for 5.0.0.RC1 is "refactoring" of the deployers. e.g. things like the jca repository being in the parsing deployer same with the loader-repository-config generation. (And speaking of jca, that codebase still needs merging from 4.2.x to make sure we have all the latest fixes). Busy, busy, busy... ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132625#4132625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132625

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Profile Service creating temporary files periodically

by scott.stark＠jboss.org

One issue is that we are too aggressively creating the entire JarHandler structure. All the profile service is doing is asking the deploy directory VirtualFile for its children. It does nother with these other than ask for the last modified time. Either lazily initializing the JarHandler or/and tracking previously extracted jars would fix the excessive creation of tmp jars. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132624#4132624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132624

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by scott.stark＠jboss.org

I'm testing the managed/metatype changes locally in the profileservice project for now. I'll update these artifacts/projects in mc next week or so as I'm working on ejb3 stuff this week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132623#4132623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132623

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by adrian＠jboss.org

SInce I'm now about ready to integrate the latest MC (which is pretty close to RC1 status) into the AS, I thought I'd do this splitting up. What I propose to do is move the following to top level projects and either create an CR1 or Beta11 release based on outstanding issues in JIRA. I'd like to get everything to CR1 in the next couple of weeks. i.e. these could be the final releases. Where I make it a CR1, I'll also create branches, leaving trunk for development of the next version. I'm ignoring issues that say "need to write tests" when judging if it should go to CR1. Project: jboss-reflection =================== This is the class/beaninfo stuff, used by at least JBossXB. I'll make this a CR1. Besides all the javassist classinfo stuff (which we aren't going to do for this release) there's two issues. * ClassInfo serialization which I believe Ales has already done but not closed http://jira.jboss.com/jira/browse/JBMICROCONT-128 * A simple bug that I'll fix http://jira.jboss.com/jira/browse/JBMICROCONT-229 Project: jboss-metadata-repository ============================ This is the scoped metadata used by at least AOP All the issues are about writing testing so this can go to CR1, except one which isn't scheduled for this release (LRU cache in CachedMetaDataContext which isn't currently used anywhere anyway :-). Project: jboss-classloader ===================== This is the classloader, classloading and classloading-vfs projects This will remain at beta until all the classloading issues are resolved in JBossAS JIRA. Project jboss-managed =================== This is the metatype and managed projects. I'll leave this at beta since Scott is mainly the one working on this, so I don't know the status. Project: jboss-deployers ==================== This is all the deployers projects. Again this will remain at beta until we've got all the JBossAS issues resolved. Project: OSGi =========== This should really be a top level project. But it isn't included in the release since it is WIP. What remains =========== That will just leave the core microcontainer and related integration projects for aop, drools, jbpm, spring, etc. With the other projects gone, we should look towards creating a CR1 for this, but there's still at least the outstanding issue with JBossXB/Maps and we might want to add some "placeholder code" for Julien's requirement? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132617#4132617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132617

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stats issue

by scott.stark＠jboss.org

I just committed a fix for this along with the duplicate DefaultDS ManagedComponent issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132614#4132614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132614

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use

by adrian＠jboss.org

I just implemented the final major feature required for OSGi. DYNAMIC You can now do | <classloading ...> | <requirements> | <package name="foo" dynamic="true"/> | </requirements> | </classloading> | This is a bit similar to optional, except unlike optional, it will continue to try to resolve import even after the classloader is constructed. Since this feature requires the caching and blacklisting to be disabled the dynamic imports are sorted towards the bottom of the import list (which looks to me like what is required for OSGi as well). When it is eventually resolved, then any caching and blacklisting will be re-enabled. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132613#4132613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132613

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassLoader for a subdeployment

by adrian＠jboss.org

I've implemented this, just like I described above. To make this useful as a Tomcat classloader, the current code that adds a ClassLoaderFactory would instead need to create ClassLoadingMetaData for the war subdeployments. This would also be the same deployer where we specify the default classloading rules for wars. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132612#4132612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132612

18 years, 1 month

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 February 2008