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

[Design of JBossCache] - Re: Ordering of Synchronizations between JBC and Hibernate

by bstansberry＠jboss.com

Not for 1.4.1, unless you want to add it. The JBossTS changes Kevin Conner mentioned offline should suffice for AS 4.2. It is ugly, but in the end we need something that imposes ordering of operations between Hibernate and JBC. Making JBC a resource of the transaction and leaving Hibernate as a synchronization would also do this. But is that doable for 2.0? I doubt it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995139#3995139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995139

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Going to pull the vfs packages into a separate project

by scott.stark＠jboss.org

The vfs code has been removed from the mc trunk and replaced with references to the jboss-vfs.jar from thirdparty. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995121#3995121 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995121

19 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Source artifacts and jbossas version

by tom.elrod＠jboss.com

Pretty much any alpha release of remoting is due to either bug fixes or added features for messaging. Any Beta, CR, or GA release of remoting should be posted as full release (i.e. to sourceforge) and include source (as well as doc, samples, etc.). Don't know what version of remoting jbossws is up to now (last I heard, was a 1.4.x version). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995118#3995118 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995118

19 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by scott.stark＠jboss.org

"charles.crouch(a)jboss.com" wrote : | Questions about next steps: | | 1) Does the additional work on the repository outlined above prevent progress on writing tests for the use cases we're going to need wrt basic DataSource management? I presume that the work remaining would actually prevent the tests from passing, but thats the next step :-). I guess we could stub out aspects of the repository to get the test to pass, but at the moment I'm more interested in the tests being written than having them pass. | | 2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api? | It can be. The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values. The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties. The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step. "charles.crouch(a)jboss.com" wrote : | 3) The tests for the DataSource use cases should go in here? | http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/tests/org/jboss/t... | | Presumably the idea is that we can create our own mock impls or use the one Adrian has provided: | http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/mana... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995110#3995110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995110

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Inconsistent handling of vfs* urls by VFS

by bill.burke＠jboss.com

Ok, i'll take a look. Just seemed weird to use a different VFS as the basis of another VFS as relative paths would be different and such. That's why I avoided it as it seemed a lot of refactoring would have been involved. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995108#3995108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995108

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Inconsistent handling of vfs* urls by VFS

by scott.stark＠jboss.org

This is needed to use this version of the vfs with jboss5. There are currently some class loading issues because of this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995106#3995106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995106

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Inconsistent handling of vfs* urls by VFS

by bill.burke＠jboss.com

never added that. Was still pondering the best way to implement it. Since the unit tests passed and jboss booted ok, didn't think it mattered for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995105#3995105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995105

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Inconsistent handling of vfs* urls by VFS

by scott.stark＠jboss.org

You cannot take a VirtualFile and use its URL to obtain a VirtualFile currently. See the vfs project src/test/java/org/jboss/test/virtual/test/FileVFSUnitTestCase.testFindClassesInFilesOnlyWar test where such a usage fails with: | java.io.IOException: No context factory for vfsfile:/home/svn/JBossMC/vfs/target/classes/vfs/test/filesonly.war/WEB-INF/classes | at org.jboss.virtual.VFS.getVFS(VFS.java:129) | at org.jboss.test.virtual.support.ClassPathIterator.<init>(ClassPathIterator.java:78) | at org.jboss.test.virtual.test.FileVFSUnitTestCase.testFindClassesInFilesOnlyWar(FileVFSUnitTestCase.java:356) | at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) | at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995104#3995104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995104

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Security domain annotation override from jboss-app.xml

by anil.saldhana＠jboss.com

There is a need for an security domain annotation override for jboss-app.xml According to Bill anonymous wrote : The EJB Container is based on AOP which allows annotation overrides. | The DD parsing looks for security-domain with the jboss.xml file. If it exists, then it allocates a SecurityDomain annotation and adds it to the EJB Container's annotation override facility which in turn is picked up by AOP at interceptor bind time. Now for the jboss-app.xml override, anonymous wrote : What really needs to be done is a refactoring of the metadata parsing like it is in other deployers. That XML is parsed in a different, separate deployer. Then you can write an additional deployer that acquires metadata from the EAR level and augments the metamodel. That way the EJB deployment process is as isolated from EAR specific processing as possible. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995097#3995097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995097

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Ordering of Synchronizations between JBC and Hibernate

by manik.surtani＠jboss.com

Basically you're suggesting Hibernate passes in a Synchronization Handler for the invocation, which we use instead of our own ordered sync handler? Hacky, but probably the easiest fix for 1.4.1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995078#3995078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995078

19 years, 3 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 December 2006