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

[Design the new POJO MicroContainer] - Re: VFS serialization

by alesj

I don't think you need to put in the whole VF. Just put some serializable structure info, either URLs or resources path Strings. And you can construct the actual VF when needed, leaving the performance issues to the VFS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133863#4133863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133863

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS serialization

by adrian＠jboss.org

It depends what the VirtualFile reference means. It isn't valid in general, just as File handles aren't serializable, but (I think?) the VFS will try to reconstruct the path from what it knows for files. If it is deployed on the server side and references the file on the server rather than on the client (and they use different file systems), it doesn't mean anything. It's broken. If it sent a VFS file that used a webdav protocol that said "get your resources from this server" then that would be a different issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133846#4133846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133846

18 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by adrian＠jboss.org

Actually, it might be better to just implement a single XAResource and get each MDB deployment to add/remove() via the resource adapter rather than you trying to work out what changed in a list of XAResources. It could also do with some kind of | close(); | to say you've finished with the XAResource and reclaim the resources although that's currently an issue with the ResourceAdapter api. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133837#4133837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133837

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS serialization

by alessio.soldano＠jboss.com

To answer your question about who's responsible for putting that VF there, consider we deploy a client app on server side ant this causes some data structure referencing resources through vf to be bound to jndi. Then on client side we perform jndi look up and the resources are not available any more through the vf. Thus we're wondering whether it's a valid solution to use the vf to reference resources whose reference has to survive jndi registration/look up. And getting to this would eventually require the vf to be actually serializable. If this way of proceeding is not valid, we could go for different solutions, for example something like what you suggest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133835#4133835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133835

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - aop-mc-int tests failing on annotation parsing

by adrian＠jboss.org

The aop-mc-int tests rerun the mc tests with the aop configuration. The parsing of annotations to create metadata is failing in these tests. Ales can either you or Kabir take a look at it and decide whose problem it is, Thanks. Note also this issue with Maven problems: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133819#4133819 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133834#4133834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133834

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: A compilation error in Remoting 2

by trustin

What do you think, Ron? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133830#4133830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133830

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reflection and MetaDataRepository refactoring

by adrian＠jboss.org

Since this has been more work than I thought, I'm going to do beta10 releases of these projects and validate it integrates back into the microcontainer, aop and jbossxb projects before doing the CR1s. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133824#4133824 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133824

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reflection and MetaDataRepository refactoring

by adrian＠jboss.org

Additionally, the DependencyBuilderListItem also needs a removeDependency() method, but I'll take that up with Kabir seperately. He needs to write a proper test for redeploying changing aop dependencies without undeploying the bean which will show why this a problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133823#4133823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133823

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Reflection and MetaDataRepository refactoring

by adrian＠jboss.org

The devil is always in the detail ;-) I've found a couple of other wrong dependencies while splitting out this code. The first is the ArrayInfo using the Signature class from the metadata repository to determine primitive array class information. This should clearly be delegating to PrimitiveInfo in both cases. The second is this horrible method in BeanInfo | /** | * Bean may have additional dependencies | * that the kernel cannot initially resolve. (currently defined by ClassAdapter) | * | * @param metaData the metadata | * @return the list of dependencies | */ | List<DependencyBuilderListItem<?>> getDependencies(MetaData metaData); | This has always bothered me since we first started the aop integration. It doesn't really belong there. It's really part of the Kernel api. The original intention isn't even used (instance ClassAdapters for AOP instance containers). And the latest rev has some horrible opaque type which is seen here in the <?> which is actually the KernelControllerContext. The issue came up again since it causes jboss-reflection to be based on the metadata repository for no logical reason. I'm finally going to bite the bullet and move this api to the kernel project and remove all reference to the DependencyBuilder from the reflection project. Like I said only aop-mc-int implements it and then only from the MC Pojo lifecycle. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133822#4133822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133822

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Problem running tests in microcontainer/aop-mc-int

by adrian＠jboss.org

I can't get the tests to run in aop-mc-int. Output using mvn -X test -Ptests-no-weave | [DEBUG] Artifact not found - using stub model: Unable to determine the latest version | | org.apache.maven.plugins:maven-surefire-report-plugin:pom:LATEST | | | [DEBUG] Using defaults for missing POM org.apache.maven.plugins:maven-surefire-report-plugin:pom:LATEST | [DEBUG] maven-surefire-report-plugin: using locally installed snapshot | [DEBUG] Artifact not found - using stub model: Unable to determine the release version | | org.apache.maven.plugins:maven-surefire-report-plugin:pom:RELEASE | | | [DEBUG] Using defaults for missing POM org.apache.maven.plugins:maven-surefire-report-plugin:pom:RELEASE | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] The plugin 'org.apache.maven.plugins:maven-surefire-report-plugin' does not exist or no valid version could be found | [INFO] ------------------------------------------------------------------------ | [DEBUG] Trace | org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-surefire-report-plugin' does not exist or no valid version could be found | I've got this workaround which is to disable the reference to the plugin | Index: pom.xml | =================================================================== | --- pom.xml (revision 70351) | +++ pom.xml (working copy) | @@ -396,13 +396,13 @@ | </execution> | </executions> | </plugin> | - <plugin> | +  | </plugins> | </build> | </profile> | @@ -665,4 +665,4 @@ | </build> | </profile> | </profiles> | -</project> | \ No newline at end of file | +</project> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133819#4133819 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133819

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