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

[Design of JBoss Web Services] - Re: VirtualFileAdaptor behavior seems incorrect

by scott.stark＠jboss.org

I see you added a test that did not show the problem. I went through the server code to see exactly how the VirtualFile being passed to the ws VirtualFileAdaptor was being created. The issue is that a VirtualFile with a DelegatingHandler pointing to the client jar is asked for itself using getChild(""), and its this VirtualFile that is passed to the VirtualFileAdaptor. It is this file that | public void testVirtualFileAdaptorEarInnerJar() throws Exception | { | URL rootURL = getResource("/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear"); | VFS vfs = VFS.getVFS(rootURL); | VirtualFile file = vfs.getChild("interop_W2JREMarshallTest_appclient_vehicle_client.jar"); | assertNotNull(file); | VirtualFile file2 = file.getChild(""); | assertNotNull(file2); | VirtualFileAdaptor adaptor = new VirtualFileAdaptor(file2); | // serialize | adaptor = serializeDeserialize(adaptor, VirtualFileAdaptor.class); | VirtualFileAdaptor child = adaptor.findChild("MarshallTest.xml"); | assertNotNull(child); | } | | java.io.IOException: Child not found interop_W2JREMarshallTest_appclient_vehicle_client.jar for ZipEntryHandler@15675922[path= context=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar real=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar], available children: [ZipEntryHandler@12612903[path=META-INF context=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar real=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar/META-INF], ZipEntryHandler(a)4945063[path=MarshallTest.xml context=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar real=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar/MarshallTest.xml], ZipEntryHandler@14126576[path=com context=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar real=vfszip:/Users/svn/JBossAS/projects/vfs/trunk/target/test-classes/vfs/test/interop_W2JREMarshallTest_appclient_vehicle.ear/interop_W2JREMarshallTest_appclient_vehicle_client.jar/com]] | at org.jboss.virtual.VirtualFile.findChild(VirtualFile.java:409) | at org.jboss.test.virtual.support.VirtualFileAdaptor.getFile(VirtualFileAdaptor.java:83) | at org.jboss.test.virtual.support.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:91) | at org.jboss.test.virtual.test.JARSerializationUnitTestCase.testVirtualFileAdaptorEarInnerJar(JARSerializationUnitTestCase.java:264) | See http://jira.jboss.com/jira/browse/JBVFS-36. The current testVirtualFileAdaptorEarInnerJar should have other tests that validate basic navigation assertations as serialization really is not the issue here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159738#4159738 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159738

16 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by alessio.soldano＠jboss.com

"alex.loubyansky(a)jboss.com" wrote : Yes, that's the one. It's in the release now. I assumed the reference should always have an injection target (field or method). | So, how should it the reference in on the class be handled in this case? I think no injection is supposed to happen for this kind of references; we have the reference bound to jndi but no injection. For instance our testcase simply does the lookup for those references. Btw can I reopen EJBTHREE-1424 or you prefer me to create a new issue? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159736#4159736 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159736

16 years

1
0
0 / 0

[Design of JBoss ESB] - Writing Integration Tests with the AbstractTestRunner

by tfennelly

Writing Integration Tests with the AbstractTestRunner View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159734#4159734 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159734

16 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Please subscribe to jbpm-dev@lists.jboss.org

by camunda

Why do we use a mailing list again? I thought we use a forum instead? And why does the forum send a mail to this list? Now I get every forum-mail twice :-/ Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159731#4159731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159731

16 years

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: XPost - Remoting from unsigned applet - ClassLoader secu

by ron.sigal＠jboss.com

D'oh. Don't know what I was thinking. One of the things I did for the Remoting 2.4.0.GA release was wrap all security sensitive calls inside java.security.AccessController.doPrivileged() calls. Most of these calls go through a SecurityUtility, which currently has 61 methods. Each method is called by one or more places in the Remoting code, so there are dozens of places that could cause security violations. But now that the work is done, Remoting 2.4.0.GA can run in the presence of a security manager, provided sufficient permissions are granted. There are sample permission files (for the default application security manager) in the distribution, downloadable from http://www.jboss.org/jbossremoting/downloads . Also, there is a discussion in Section 5.9. "Running with a security manager" of the Remoting Guide (http://www.jboss.org/jbossremoting/docs/guide/html/index.html). Now, these changes weren't made with unsigned applets in mind, and I can't tell you a lot about security in unsigned applets. However, it looks like the Applet Java Plug-in starts JVMs that (at least in jdk 1.6) can be configured to run unsigned applets with permissions beyond the classical applet sandbox. In particular, the "JavaTM Network Launching Protocol & API Specification (JSR-56)" version 6.0.10 says anonymous wrote : | The sandbox environment described above is the default set of permissions granted to an untrusted application or applet. The JNLP Client may allow the user or system administrator to configure alternative permission sets for untrusted applications and applets. | So it sounds like it might be possible, with the right permission configuration, to get Remoting 2.4.0.GA to run in unsigned applets. James, if you investigate and learn more, I'd like to hear your conclusions. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159710#4159710 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159710

16 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Coverage on tests

by clebert.suconic＠jboss.com

I have compiled a list for missing tests or missing coverage: http://wiki.jboss.org/auth/wiki/JBossMessagingCoverageTests I have used a WIKI, so we can all update it as we go, and I haven't linked it anywhere as the page should disappear when we complete writing the tests. For this I have used a mix of manual steps (Find reference of classes, and look for specific methods), looking at the list of methods and things done / comparing to the implementation. And also.. I've executed only the isolated test to find what is the covered by specific tests. Example: ant clean; ant -Dtest-mask=PostOfficeTest emma or if you want to run it faster rm build/emma/coverage.emma; ant -Dtest-mask=PostOfficeTest emma With that you can see exactly what methods are not being tested by PostOfficeTest. Just look for the class on the report. Emma was not in the center of what I did, but it was a good help. Also I will redo/refine the search next week after we have written more tests, making sure we are not missing anything. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159708#4159708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159708

16 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: C++ Clinets for JBOSS Messaging

by clebert.suconic＠jboss.com

JBoss Messaging 1.4 or 2.0 don't support AMQP yet. We have it planned for 2.0. BTW: If you don't mind I will move this Thread to the User's forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159702#4159702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159702

16 years

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

You're seeing those because of this kind of thing on the ndoe and/or the other node: "IncomingPacketHandler (channel=portal.hibernate)" daemon prio=1 tid=0x0000002b70482b30 nid=0x6d11 in Object.wait() [0x0000000042573000..0x0000000042575ab0] | at java.lang.Object.wait(Native Method) | - waiting on <0x0000002b2dc22680> (a org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock) | at org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock.attempt(ReadWriteLockWithUpgrade.java:389) | - locked <0x0000002b2dc22680> (a org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock) | at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:199) | at org.jboss.cache.Node.acquireWriteLock(Node.java:562) | at org.jboss.cache.Node.acquire(Node.java:509) | at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:160) | at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:84) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) | at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:85) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) | at org.jboss.cache.interceptors.TxInterceptor.handleOptimisticPrepare(TxInterceptor.java:452) | at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:336) | at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) | at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) | at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919) | at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196) That thread is the one that carries messages up from the network layer to JBoss Cache. As you can see, it's blocking waiting for a lock. While those threads block, messages don't get transmitted, leading to the blocking you see on the other threads. The real problem here is the 2 JBC instances are fighting over a lock -- and unnecessarily so - they are both trying to cache the same data that's been directly read from the db. Logicaly, that needn't trigger any cluster traffic at all. The old Hibernate 3.2.x / JBC 1.x integration code is quite poor. Totally redone for Hibernate 3.3. But that doesn't help you. :( How critical is this? I'm tempted to extract a version of the TreeCacheProvider out of the EAP code, improve it a bit and package it as an independent library. Will help with your issue, and be a small benefit to the community. Won't be as good as the Hibernate 3.3 stuff, but better than what you've got. But I really don't have the cycle to do it, not until AS 5 is done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159700#4159700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159700

16 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: C++ Clinets for JBOSS Messaging

by jmsid4jboss

Thank you for you response. Can a RHM client be able to send messages to JBOSS Messaging as both of them use AQMP. Please advice we are planning to use JBOSS 4.2.2. I read the below from this URL http://www.jboss.org/rhmessaging/jbm-rhm-faq.html Furthermore, because both JBoss Messaging and Red Hat Messaging include JMS-compatible clients, applications may select to use either project's JMS client when constructing their applications, based on the needs and environment of that application http://www.jboss.org/rhmessaging/jbm-rhm-faq.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159697#4159697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159697

16 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: C++ Clinets for JBOSS Messaging

by clebert.suconic＠jboss.com

We're planning C++ clients on JBM 2.0. with JBM 1.4, you could instantiate Java using JNI from your C++ client, and use a regular Java client, or use a WebService/REST deployed on JBAS with C++. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159693#4159693 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159693

16 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008