[Design of POJO Server] - Updating to latest MC projects
by adrian＠jboss.org
The plan is to do beta releases early next week for all the MC projects
so we can see where we are. Some of the projects will then move CR1
since they have no outstanding tasks.
The main unknowns at the moment are Kabir validating the changes
I did to the metadata passing for MC/AOP and the JBoss MAN tasks.
To see where we are, I've created snapshots for the projects and
started looking at problems.
You can do this yourself with the following diff to jboss-head
| [ejort@warjort jboss-head]$ svn diff
| Index: component-matrix/pom.xml
| ===================================================================
| --- component-matrix/pom.xml (revision 76563)
| +++ component-matrix/pom.xml (working copy)
| @@ -42,16 +42,16 @@
| <version.org.jboss.aop>2.0.0.CR13</version.org.jboss.aop>
| <version.org.jboss.ejb3>0.1.9</version.org.jboss.ejb3>
| <version.org.jboss.jpa>0.1.1</version.org.jboss.jpa>
| - <version.org.jboss.mdr>2.0.0.Beta15</version.org.jboss.mdr>
| + <version.org.jboss.mdr>2.0.0-SNAPSHOT</version.org.jboss.mdr>
| <version.org.jboss.vfs>2.0.0.Beta20</version.org.jboss.vfs>
| - <version.org.jboss.cl>2.0.0.Beta12</version.org.jboss.cl>
| + <version.org.jboss.cl>2.0.0-SNAPSHOT</version.org.jboss.cl>
| <version.org.jboss.cluster>1.1.0.CR2</version.org.jboss.cluster>
| - <version.org.jboss.deployers>2.0.0.Beta18</version.org.jboss.deployers>
| + <version.org.jboss.deployers>2.0.0-SNAPSHOT</version.org.jboss.deployers>
| <version.org.jboss.integration>5.0.0.Beta5</version.org.jboss.integration>
| <version.org.jboss.jbossxb>2.0.0.CR11</version.org.jboss.jbossxb>
| <version.org.jboss.man>2.0.0.Beta15</version.org.jboss.man>
| <version.org.jboss.metadata>1.0.0.Beta34</version.org.jboss.metadata>
| - <version.org.jboss.microcontainer>2.0.0.Beta16</version.org.jboss.microcontainer>
| + <version.org.jboss.microcontainer>2.0.0-SNAPSHOT</version.org.jboss.microcontainer>
| <version.org.jboss.security>2.0.2.CR6</version.org.jboss.security>
| <version.oswego-concurrent.concurrent>1.3.4-jboss-update1</version.oswego-concurrent.concurrent>
| <version.suffix.org.jboss.javaee>.CR1</version.suffix.org.jboss.javaee>
| @@ -1083,7 +1083,7 @@
| <dependency>
| <groupId>org.jboss</groupId>
| <artifactId>jboss-reflect</artifactId>
| - <version>2.0.0.Beta12</version>
| + <version>2.0.0-SNAPSHOT</version>
| </dependency>
|
| <dependency>
| Index: server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java
| ===================================================================
| --- server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (revision 76563)
| +++ server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (working copy)
| @@ -142,7 +142,12 @@
|
| Set<Class<?>> classes = new HashSet<Class<?>>();
| for(Class<? extends Annotation> annotation : annotationOnClass)
| - classes.addAll(env.classIsAnnotatedWith(annotation));
| + {
| + Class<Annotation> annotationClass = (Class<Annotation>)annotation;
| + Set<Element<Annotation, Class<?>>> elements = env.classIsAnnotatedWith(annotationClass);
| + for(Element<Annotation, Class<?>> elt : elements)
| + classes.add(elt.getOwner());
| + }
| for(Class<? extends Annotation> annotation : annotationOnMethod)
| {
| Class<Annotation> annotationClass = (Class<Annotation>)annotation;
| @@ -212,4 +217,4 @@
| }
| }
| }
| -}
| \ No newline at end of file
| +}
| Index: server/src/etc/conf/default/deployers.xml
| ===================================================================
| --- server/src/etc/conf/default/deployers.xml (revision 76563)
| +++ server/src/etc/conf/default/deployers.xml (working copy)
| @@ -206,6 +206,7 @@
| </property>
| </bean>
| <bean name="InMemoryClassesDeployer" class="org.jboss.deployers.vfs.plugins.classloader.InMemoryClassesDeployer"/>
| + <bean name="ClassLoaderClassPathDeployer" class="org.jboss.deployers.vfs.plugins.classloader.VFSClassLoaderClassPathDeployer"/>
| <bean name="ClassLoaderDescribeDeployer" class="org.jboss.deployers.vfs.plugins.classloader.VFSClassLoaderDescribeDeployer">
| <property name="classLoading"><inject bean="ClassLoading"/></property>
| </bean>
| Index: server/src/etc/deployers/metadata-deployer-jboss-beans.xml
| ===================================================================
| --- server/src/etc/deployers/metadata-deployer-jboss-beans.xml (revision 76563)
| +++ server/src/etc/deployers/metadata-deployer-jboss-beans.xml (working copy)
| @@ -11,20 +11,19 @@
| -->
| <bean name="ReferenceMetaDataResolverDeployer" class="org.jboss.deployment.MappedReferenceMetaDataResolverDeployer"/>
|
| - <!-- Generic scanning deployer - using javassist to do lookup
| - <bean name="GenScanDeployer" class="org.jboss.deployers.plugins.annotations.GenericAnnotationDeployer">
| - <property name="output">org.jboss.deployers.spi.annotations.AnnotationEnvironment</property>
| + <!-- Generic scanning deployer - using javassist to do lookup -->
| + <bean name="GenScanDeployer" class="org.jboss.deployers.vfs.plugins.annotations.AnnotationEnvironmentDeployer">
| + <property name="checkInterfaces">false</property>
| </bean>
|
| <bean name="AnnotationMetaDataDeployer" class="org.jboss.deployment.AltAnnotationMetaDataDeployer">
| <property name="metaDataCompleteIsDefault">false</property>
| </bean>
| - -->
|
| <!-- Extract annotations into a standard metadata view -->
| - <bean name="AnnotationMetaDataDeployer" class="org.jboss.deployment.AnnotationMetaDataDeployer">
| + <!--bean name="AnnotationMetaDataDeployer" class="org.jboss.deployment.AnnotationMetaDataDeployer">
| <property name="metaDataCompleteIsDefault">false</property>
| - </bean>
| + </bean-->
|
| <!-- The schema location to JBossXB binding class mappings. We specify the dtd/xsd name
| of the schema as the location to work with legacy dtd as well as namespace based
| Index: testsuite/build.xml
| ===================================================================
| --- testsuite/build.xml (revision 76563)
| +++ testsuite/build.xml (working copy)
| @@ -494,6 +494,8 @@
| <exclude name="org/jboss/test/recover/derby/**"/>
| <exclude name="org/jboss/test/xml/JaxpXPathBaseTestCase*" if="HAVE_JDK_1.4"/>
| <exclude name="org/jboss/test/aop/**"/>
| + <exclude name="org/jboss/test/xml/importing/**"/>
| + <exclude name="org/jboss/test/xml/ExtendedByImportUnitTestCase*"/>
| <classpath refid="tests.compile.classpath"/>
| </javac>
| </target>
|
Three problems I've found so far are:
1) org.jboss.test.xml.ExtendedByImportUnitTestCase
is extending the old MC JBossXB schema initializer code which no longer exists.
For now I've commented this out so I can get the testsuite to compile.
2) ejb3 NPE with the new annotation scanner
Here's an example:
| 2008-08-01 17:26:27,385 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (RMI TCP Connection(78)-127.0.0.1) Error installing to Start: name=jboss.j
| 2ee:ear=jboss-seam-dvd.ear,jar=jboss-seam-dvd.jar,name=AcceptAction,service=EJB3 state=Create
| java.lang.NullPointerException
| at javax.naming.NameImpl.<init>(NameImpl.java:264)
| at javax.naming.CompoundName.<init>(CompoundName.java:187)
| at org.jnp.interfaces.NamingParser.parse(NamingParser.java:62)
| at org.jboss.util.naming.Util.rebind(Util.java:116)
| at org.jboss.ejb3.proxy.factory.BaseSessionProxyFactory.bindProxy(BaseSessionProxyFactory.java:192)
| at org.jboss.ejb3.proxy.factory.stateful.BaseStatefulProxyFactory.start(BaseStatefulProxyFactory.java:104)
| at org.jboss.ejb3.proxy.factory.stateful.StatefulLocalProxyFactory.start(StatefulLocalProxyFactory.java:136)
| at org.jboss.ejb3.session.ProxyDeployer.start(ProxyDeployer.java:135)
| at org.jboss.ejb3.session.SessionContainer.lockedStart(SessionContainer.java:188)
| at org.jboss.ejb3.stateful.StatefulContainer.lockedStart(StatefulContainer.java:286)
| at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:856)
|
Ales says there is a fix for this in ejb3-core, so we need some update
for this fix otherwise there's going to be some regressions in the ejb3 tests.
3) ScopedClassLoaderUnitTestCase
There is a fix for this in the latest jboss-cl release, but the test is currently failing
because one of the test jars is not getting built:
| <testcase classname="org.jboss.test.classloader.test.ScopingUnitTestCase" name="testNestedWarManifest" time="3.222">
| <error message="no protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar" type="java.net.MalformedURLException">java.net.MalformedURLException: no
| protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar
| at java.net.URL.<init>(URL.java:567)
| at java.net.URL.<init>(URL.java:464)
| at java.net.URL.<init>(URL.java:413)
| at org.jboss.test.JBossTestServices.getDeployURL(JBossTestServices.java:211)
| at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352)
| at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276)
| at org.jboss.test.classloader.test.ScopingUnitTestCase.testNestedWarManifest(ScopingUnitTestCase.java:255)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168221#4168221
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168221
17 years, 4 months
[Design of JBossCache] - Eviction redesign
by bstansberry＠jboss.com
Discussion re: any redesign of eviction for JBC 3.
Somewhat quoting myself from a tangent on another thread:
Looking at the eviction system in JBC, it seems nicely set up to work a la carte:
1) An interceptor that generates events and passes them to the region, which queues them. (This is somewhat coupled to #2 via the EvictionPolicy.canIgnoreEvent() call the interceptor makes.)
2) The EvictionPolicy/Algorithm which can process the region's queue of events and determine what to evict, and then evict it.
3) The evict() API on the cache, which is used by EvictionPolicy/Algorithm but also allows self-managed eviction.
4) A thread-management system that kicks off #2.
So, main thing is I think JBC should support these combos from the a la carte menu:
#1 + #2 + #3 + #4 (of course)
#3
#1 + #2 + #3.
The last can be achieved by setting the wakeupIntervalSeconds to 0, which effectively disables #4. An application can then manage eviction itself by:
a) getting the EvictionPolicy associated with the region (which is part of the public API of Region)
b) get the EvictionAlgorithm from that (which is part of the public EvictionPolicy API) c) process() on that (which is part of the public EvictionAlgorithm API).
So, to provide a la carte eviction the main thing is to keep logical equivalents to those 3 API calls I described above available.
I don't see any point in JBC trying to support #1 + #3 (i.e. add a way to bypass the EvictionInterceptor call to EvictionPolicy.canIgnoreEvent()). If someone wants that they can just implement a CacheListener to get events.
The area where things are a bit clunky is the API of EvictionPolicy/EvictionAlgorithm. Currently those are a bit of a mix of API and SPI, with an implementation detail (delegate to EvictionAlgorithm) mixed in. Some initial thoughts on improving this:
1) No one should need to call EvictionAlgorithm except an EvictionPolicy impl. That is, that's an internal implementation detail.
2) Perhaps the EvictionPolicy interface should just be a client interface. That is, just expose what's needed by a thread that wants to run eviction: process()
3) Then add an EvictionPolicySPI interface. That includes methods needed to integrate the policy impl into the cache, plus those needed by the event tracking mechanism (e.g. canIgnoreEvent()).
Separating the SPI from EvictionPolicy is kind of just being anal, but if it doesn't introduce problems I think anal is good. :-) Doing #1 will change the EvictionPolicy interface anyway, so not existing impls will break anyway.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168187#4168187
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168187
17 years, 4 months