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

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting and remote classloading

by ron.sigal＠jboss.com

On porting JBREM-962 "Remote classloading does not work with Isolated EARs" to JBossAS 5 and Remoting 2.4: "scott.stark(a)jboss.org" wrote : | | "ron.sigal(a)jboss.com" wrote : | | If RemotingClassLoader can't find a class locally, it will try to contact a Connector with a MarshallerLoaderHandler, which will send back a class if it can find it. For Remoting 2.2 and EAP 4.2/4.3, I made it possible to configure a Connector with the object names of a set of loader repositories (which come from jboss-app.xml files), so that MarshallerLoaderHandler can search for classes in scoped EARs. At first I thought you were saying that the TCL was a magic bullet I could use in place of external configuring, but I see that that's probably not the case. So I guess my question is: "Are there equivalent bean names, either for classloaders or repositories, that I can use in place of the JMX object names?". | | | | There are bean names, but the remoting layer should not end up trying to marshall things it does not know about and introduce a dependency on a server specific class loading implementation. The TCL is a magic bullet when the call has passed onto the handler. Outside of that, the remoting layer should not have to deal with class loading. | Without access to classloaders other than its own, Remoting's remote classloading facility would be crippled, which was the genesis of JBREM-962. A user had EJB A and EJB B in two different scoped EARs, and he wanted EJB A to call a method on EJB B that returns an instance of a class that was unavailable to EJB A. With the fix from JBREM-962, the unmarshaller in EJB A can download the missing class by contacting Remoting's MarshallerLoaderHandler running in a Connector "affiliated" with the EJB3 Connector that serves EJB B. But that only works if the user configured the EJB3 Connector that serves EJB B with the name of the right classloader repository. I would argue that in this situation, Remoting's MarshallerLoaderHandler *is* the handler responsible for setting the TCL, though it's outside of the usual channels for mapping applications to classloaders. I guess the basic question is, do we want to continue to support Remoting's independent remote classloader facility? Or should Remoting just depend on the Application Server's RMI classloader facility? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169369#4169369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169369

17 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: JBAS-5673 - Metadata processing

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | If it works, yes ;). | I spent some time testing that and it looks quite ok. Although i had to fight a bit with the WebServiceRefHandler, as the loadXml does not really do everything which is needed. Therefore i did a simple one for web processing, because i need to put the injectors to this EncInjections map i mentioned above. Furthermore i reuse the correct PersistenceUnitResolver, which does not seem to work properly, but at least it's the right one ;) So then i have one remaining question, because you said: anonymous wrote : | The only annotation scanning in the web container would be dynamic elements not available via metadata such as jsp beans, etc. | What is etc. ? :) I mean how can we determine dynamic beans? because i'm afraid that doing something like: | if (injectors == null && className.endsWith("_jsp")) | { | // process the dynamic bean annotations | } | is not enough then. I saw that jsf injection is done somewhere else, so what else do we need to consider there ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169368#4169368 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169368

17 years, 8 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem with JBoss Profiler 2 Beta install.

by aprobe

Thanks, cleaning up the extra jboss-profiler-*.jar files I put in AS/bin did the trick. The profiler is up and running. Also, running the client from the build/dist directory (where all the jar files are) did the trick with the client. Now I just have to get an app running to profile... Thanks again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169363#4169363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169363

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

Prabhat, you can find a patch with the config changes in https://jira.jboss.org/jira/browse/JBCLUSTER-206 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169362#4169362 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169362

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Ejb3Deployment.resolveMessageDestination

by scott.stark＠jboss.org

I'm saying the MessageDestinationResolver should just be dropped as the message ref should have had its resolvedJndiName set, same as for ejb refs. We have already removed the ejb resolver from the ejb3 deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169359#4169359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169359

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Ejb3Deployment.resolveMessageDestination

by wolfc

I'm not too thrilled with this solution. It pollutes both EJB3 and metadata. I would rather see MessageDestinationResolver refactored in the same style as PersistenceUnitDependencyResolver. interfaces MessageDestinationResolver { | String resolveMessageDestination(DeploymentUnit unit, String link); | } With the default impl returning the resolved jndi name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169358#4169358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169358

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by bstansberry＠jboss.com

I know you're unavailable soon, so if you don't have time to do this stuff, let me know. If you have limited time, would prefer you spend it getting the config changes you mentioned to Prabhat; I can get him the binary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169357#4169357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169357

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by bstansberry＠jboss.com

Further to the last post: Since it's now configurable, this: queryCacheLocalWritesOnly = StandardQueryCache.class.getName().equals(regionName) && this.cacheProperties.isQueryCacheLocalWritesOnly(); Can now become this: queryCacheLocalWritesOnly = regionName.contains(StandardQueryCache.class.getName()) && this.cacheProperties.isQueryCacheLocalWritesOnly(); This will handle the case where the user provided a region prefix for the SessionFactory but the StandardQueryCache is still used, i.e. the passed in regionName becomes: regionprefix.org.hibernate.cache.StandardQueryCache I didn't do it that way in the EJB3 code because localWritesOnly was a last minute workaround that couldn't be disabled, so I wanted to limit it to the one case I knew we couldn't handle. The hibernate.treecache.standardquerycache.local.writes.only property gives us more freedom to do it right. Further, I think queryCacheLocalWritesOnly = regionName.contains(StandardQueryCache.class.getName()) && this.cacheProperties.isQueryCacheLocalWritesOnly(); should move above the if (cache.getUseRegionBasedMarshalling()) code block. This functionality is no longer so closely related to marshalling issues; it's also a (configurable) performance optimization. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169356#4169356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169356

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by bstansberry＠jboss.com

Only other comment is on the hibernate.treecache.querycache.local.writes.only, which only affects things if the cache region is StandardQueryCache. (Correctly so, as the use of that class in the region name is what lets us know its a query region.) Function of the property is basically to turn off the local-writes behavior if the user knows it's safe. Perhaps the property name should be hibernate.treecache.stdquerycache.local.writes.only or hibernate.treecache.standardquerycache.local.writes.only to reflect the fact that the property has a very limited scope. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169355#4169355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169355

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by bstansberry＠jboss.com

Looked through your changes. I like the CacheProperties class. :) Only thing I see is we need to override localPutsOnly if the we are caching timestamps. Following patch does that: | Index: /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/JBCCache.java | =================================================================== | --- /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/JBCCache.java (revision 76762) | +++ /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/JBCCache.java (working copy) | @@ -33,6 +33,7 @@ | import org.hibernate.cache.Cache; | | import org.hibernate.cache.CacheException; | | import org.hibernate.cache.StandardQueryCache; | | +import org.hibernate.cache.UpdateTimestampsCache; | | import org.jboss.cache.Fqn; | | import org.jboss.cache.config.Option; | | import org.jboss.cache.lock.TimeoutException; | | @@ -57,6 +58,7 @@ | private final Fqn regionFqn; | | private final TransactionManager transactionManager; | | private boolean queryCacheLocalWritesOnly; | | + private boolean localPutsOnly; | | | | private final CacheProperties cacheProperties; | | | | @@ -95,6 +97,8 @@ | { | | log.debug("TreeCache is not configured for region based marshalling"); | | } | | + | | + this.localPutsOnly = this.cacheProperties.isLocalPutsOnly() && (regionName.contains(UpdateTimestampsCache.class.getName()) == false); | | } | | | | public Object get(Object key) throws CacheException { | | @@ -135,7 +139,7 @@ | public void put(Object key, Object value) throws CacheException { | | Transaction tx = suspend(); | | try { | | - if (queryCacheLocalWritesOnly || cacheProperties.isLocalPutsOnly()) { | | + if (queryCacheLocalWritesOnly || localPutsOnly) { | | Option option = new Option(); | | option.setCacheModeLocal(true); | | // Overloaded method isn't available, so have to use InvocationContext | | Index: /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/OptimisticJBCCache.java | =================================================================== | --- /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/OptimisticJBCCache.java (revision 76762) | +++ /home/bes/dev/cluster/hibernate-jbc-cacheprovider/trunk/src/main/java/org/jboss/hibernate/jbc/cacheprovider/OptimisticJBCCache.java (working copy) | @@ -31,6 +31,7 @@ | import org.hibernate.cache.OptimisticCache; | import org.hibernate.cache.OptimisticCacheSource; | import org.hibernate.cache.StandardQueryCache; | +import org.hibernate.cache.UpdateTimestampsCache; | import org.jboss.cache.Fqn; | import org.jboss.cache.optimistic.DataVersion; | import org.jboss.cache.config.Option; | @@ -59,6 +60,7 @@ | private final Fqn regionFqn; | private OptimisticCacheSource source; | private boolean queryCacheLocalWritesOnly; | + private boolean localPutsOnly; | | private final CacheProperties cacheProperties; | | @@ -95,6 +97,8 @@ | { | log.debug("TreeCache is not configured for region based marshalling"); | } | + | + this.localPutsOnly = this.cacheProperties.isLocalPutsOnly() && (regionName.contains(UpdateTimestampsCache.class.getName()) == false); | } | | | @@ -128,7 +132,7 @@ | Option option = new Option(); | option.setFailSilently( true ); | option.setDataVersion( NonLockingDataVersion.INSTANCE ); | - option.setCacheModeLocal(queryCacheLocalWritesOnly); | + option.setCacheModeLocal(queryCacheLocalWritesOnly || localPutsOnly); | cache.remove( new Fqn( regionFqn, key ), "ITEM", option ); | | option = new Option(); | @@ -137,7 +141,7 @@ | ? new DataVersionAdapter( currentVersion, currentVersion, source.getVersionComparator(), source.toString() ) | : NonLockingDataVersion.INSTANCE; | option.setDataVersion( dv ); | - option.setCacheModeLocal(queryCacheLocalWritesOnly); | + option.setCacheModeLocal(queryCacheLocalWritesOnly || localPutsOnly); | cache.put( new Fqn( regionFqn, key ), ITEM, value, option ); | } | catch (Exception e) { | @@ -188,7 +192,7 @@ | Option option = new Option(); | option.setFailSilently( true ); | option.setDataVersion( NonLockingDataVersion.INSTANCE ); | - option.setCacheModeLocal(queryCacheLocalWritesOnly); | + option.setCacheModeLocal(queryCacheLocalWritesOnly || localPutsOnly); | cache.put( new Fqn( regionFqn, key ), ITEM, value, option ); | } | catch (TimeoutException te) { I can check that in if it won't step on you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169353#4169353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169353

17 years, 8 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 August 2008