[JBossWS] - Casting porblem
by pablinkus
Hi,
I'm quite new with web services, so perhaps it is a stupid question.
I'm working with JBoss 4.2.2 and I've installed JBossws-native 3.0.5.
I've created a simple web service with he method that receive and List of objects.
Something like this:
public long startTramitadorInstance(String processName, List < Product > productList)
Product is a superclass and I've set in it the @XmlSeeAlso tag with the subclasses.
I use the wscompile included in the jbossws-native package tool to generate classese from the WSDL. And if I call this method from a client and the List is formed for several subclasses of the superclass, I always get an Exception:
Caused by: java.lang.ClassCastException: com..beans.product.Product cannot be cast to com..beans.product.Subproduct
Is that normal? Cann't I use superclasses or abstract classes in the methods of the web service? Am I doing something wrong?
Thanks in advance
Pablo
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217622#4217622
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217622
17 years, 3 months
[Microcontainer] - Re: Ordering a deployer which needs multiple inputs
by alesj
This should work.
Can you post the log from DeployersImpl,
after new deployer is added and it is ordered for its stage;
DeployersImpl::addDeployer
| String stageName = stage.getName();
| List<Deployer> deployers = deployersByStage.get(stageName);
| if (deployers == null)
| deployers = Collections.emptyList();
| deployers = insert(deployers, wrapper);
| deployersByStage.put(stageName, deployers);
|
| this.deployers.add(wrapper);
|
| StringBuilder builder = new StringBuilder();
| builder.append("Added deployer ").append(deployer).append(" for stage ").append(stageName).append('\n');
| for (Deployer temp : getDeployersList(stageName))
| {
| builder.append(temp);
| builder.append("{inputs=").append(temp.getInputs());
| builder.append(" outputs=").append(temp.getOutputs());
| builder.append("}\n");
| }
| log.debug(builder);
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217619#4217619
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217619
17 years, 3 months
[JBoss Cache: Core Edition] - Re: is it possible for MVCCInvocationContext to have null mv
by dukehoops
Manik,
Your explanation makes sense, however I wonder whether that means Hibernate / Hib-JBC2 integration project / JBC3 stack is unusable with REPEATABLE_READ then. Let me explain.
Person, Child are cached entities, parent.children is a cached collection (using Hibernate's Transactional concurrency strategy).
Consider this method:
| public void addChild(parentId){
|
| tx.begin();
|
| Parent p = parentDAO.get(parentId);
| Set<Child> children = p.getChildren();
| Child newChild = new Child();
| children.add(newChild);
| tx.commit();
| }
|
Let's look at what calls hib-jbc integration layer (org.hibernate.cache.jbc2.[collection|entity].TransactionalAccess) will issue for each of the above lines:
1. Parent p = parentDAO.get(parentId);
cache.get(parentIdFqn); //cache miss on very 1st call
//hibernate goes to db to retrieve data and then puts it into cache:
cache.pfer(parentIdFqn, p)
2. Set children = p.getChildren();
//look in collection cache for parent.children with given parentId
cache.get(parentIdCollectionFqn) //miss
//hibernate will look in db, and if db returns nothing, will put an empty collection into cache
cache.pfer(parentIdCollectionFqn, emptyCollection);
3. children.add(newChild);
Hibernate tells 2nd level cache to evict collection cache entry on any collection modification. Specifically above add call will result in removeNode call on tx.commit():
cache.removeNode(parentIdCollectionFqn); //should remove empty Collection from cache to ensure next time step #2 above is executed cache misses and we go to DB.
However, as you point out pfer() will operate in different tx than get() and removeNode(). Therefore, removeNode will not remove the empty collection. Now Node with parentIdCollectionFqn still has emptyCollection as value and so in a subsequent transaction:
tx.begin();
cache.get(parentIdCollectionFqn); //hibernate expects a miss so that new children can be re-read from db
tx.commit();
.. we will actually get a cache hit with stale emptyCollection, one that does not contain newChildId. So as far as Hibernate will be concerned, given parent will have no children. (even though newChild is in db).
So, I understand your explanation and agree that JBC code behaves correctly. But it seems like the problem is that when child is added to a collection in Hibernate, collection cache will see exactly this series of calls:
tx1:
-get()
-pfer()
-removeNode() //expected to ensure cache miss on the subsequent get()
tx2:
-get() //expect a miss
So that means that org.hibernate.cache.jbc2.collection.TransactionalAccess.putFromLoad() should use a Cache method that ensures that a subsequent Cache.removeNode will actually remove, i.e putFromLoad()
- either should use put() instead of pfer()
- or use a new method that is like pfer() but does not suspend TX.
Here's the updated test that I believe issues the same calls that org.hibernate.cache.jbc2.collection.TransactionalAccess would issue with the above service method:
package org.jboss.cache.api;
|
| import org.jboss.cache.config.Configuration;
| import org.jboss.cache.config.Configuration.NodeLockingScheme;
| import org.jboss.cache.factories.UnitTestConfigurationFactory;
| import org.testng.annotations.Test;
|
| import javax.transaction.TransactionManager;
|
| import org.jboss.cache.*;
| import org.jboss.cache.lock.IsolationLevel;
|
| /**
| * Tests that a node that was putFromExternalRead and then removed in TX1 does NOT
| * get returned in subsequent TX2.
| *
| * @author nikita_tovstoles(a)mba.berkeley.edu
| * @since 3.0.3.GA
| */
| @Test(groups = {"functional", "pessimistic"}, sequential = true, testName = "api.RemovedNodeResurrectionInSubsequentTxTest")
| public class RemovedNodeResurrectionInSubsequentTxTest extends AbstractSingleCacheTest {
|
| private static final Fqn A_B = Fqn.fromString("/a/b");
| private static final Fqn A = Fqn.fromString("/a");
| private static final Fqn A_C = Fqn.fromString("/a/c");
| private static final String KEY = "key";
| private static final String VALUE = "value";
| private static final String K2 = "k2";
| private static final String V2 = "v2";
| protected NodeSPI root;
| protected TransactionManager txManager;
|
| public CacheSPI createCache() {
| CacheSPI myCache = (CacheSPI<Object, Object>) new UnitTestCacheFactory<Object, Object>().createCache(UnitTestConfigurationFactory.createConfiguration(Configuration.CacheMode.LOCAL, false), false, getClass());
| myCache.getConfiguration().setCacheMode(Configuration.CacheMode.LOCAL);
| myCache.getConfiguration().setCacheLoaderConfig(null);
| myCache.getConfiguration().setNodeLockingScheme(NodeLockingScheme.MVCC);
| configure(myCache.getConfiguration());
| myCache.start();
| root = myCache.getRoot();
| txManager = myCache.getTransactionManager();
|
| return myCache;
| }
|
| protected void configure(Configuration c) {
| c.setIsolationLevel(IsolationLevel.REPEATABLE_READ);
| }
|
| public void testPferAndEvictInSameTx() throws Exception {
|
| Object val = null;
|
| cache.getRoot().addChild(A);
|
| txManager.begin();
|
| val = cache.get(A_B, KEY); //N1 IF THIS LINE IS EXECUTED, TEST FAILS BELOW AT N2
|
| //put in cache
| cache.putForExternalRead(A_B, KEY, VALUE);
|
| //val = cache.get(A_B, KEY);
| //assert val != null : "get() after pfer() returned " + val; //N2 THIS WILL FAIL IF LINE N1 (ABOVE) IS EXECUTED (NOT COMMENTED OUT)
|
| //evict from cache
| cache.removeNode(A_B); //sometimes MVCCInvocationContext has ref to mvccTCtx, sometimes NOT
|
| //verify eviction
| //val = cache.get(A_B, KEY);
| //assert val == null : "get() after evict() returned " + val;
|
| txManager.commit();
|
| txManager.begin();
| //verify miss
| val = cache.get(A_B, KEY);
| assert val == null : "get() after tx.commit returned " + val;
|
| txManager.commit();
|
| }
| }
|
and corresponding failure expected from JBC core perspective but NOT from Hibernate perspective:
anonymous wrote : java.lang.AssertionError: get() after tx.commit returned value
| at org.jboss.cache.api.RemovedNodeResurrectionInSubsequentTxTest.testPferAndEvictInSameTx(RemovedNodeResurrectionInSubsequentTxTest.java:78)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
| at java.lang.Thread.run(Thread.java:619)
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217616#4217616
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217616
17 years, 3 months