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

[Design the new POJO MicroContainer] - Re: Another problem with jar urls

by bill.burke＠jboss.com

I could do this after Nov 20th. I've already done it once. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985601#3985601 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985601

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Current behavior of DeploymentUnit.getAttachment

by scott.stark＠jboss.org

Right, but we need to have a distinction between resource visibility and hierarchical metadata. Until we get aligned on metadata being a more properly defined aspect of the vdf we kind of have a free for all in terms of who is doing what in the processing of deployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985600#3985600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985600

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Another problem with jar urls

by scott.stark＠jboss.org

As an intermediate change between doing a full vfs* url and the current jar: url, it would be better to just drop jar urls altogether. There is nothing good about them. After the beta next week I'll look at refactoring the jar handling to drop this as well as to allow for alternate jar handler implementations like truzip as I don't trust that we have sufficient control over the current java JarFile impl because of its native elements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985596#3985596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985596

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Problem with VFS AbstractJarHandler / JarEntryHandler

by scott.stark＠jboss.org

Sure go ahead. The to URL should be returning the proper directory form and there is a org.jboss.test.virtual.test.FileVFSUnitTestCase.testDirURLs test in the mc container tests that should be expanded to pickup the current failing behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985593#3985593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985593

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: JBC and RPC

by bstansberry＠jboss.com

Yes, it would impact things, although hopefully not in a problematic way. I haven't thought it through, but I'd think what I described above could be added in a later 5.x release without any overly-bad compatibility issues. We'd just have to make sure that webapps configured the old way still work. That's really an issue in the AS code. For 2.0.0 if we can think a bit about the Cloneable implementation of the configuration classes, that would be great. I added a JIRA -- http://jira.jboss.com/jira/browse/JBCACHE-845 -- if we get it done for 2.0.0, great; if not we can push it out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985584#3985584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985584

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests

by rachmatowicz＠jboss.com

Just had a thought: would the solution here involve modifying the jboss.xml file in the jmsra.jar to specify scoped deployment? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985576#3985576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985576

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Another problem with jar urls

by bill.burke＠jboss.com

I found out that the hard way as well.... You have to do openConnection() typecast it to JarUrlConnection to gain access. Another way to do it which I experimented with was to *not* put "jar:" in front of jarfiles for the URL. I don't know why that was done in the first place other than to make the code a little easier to write. In my "vfsfile:" prototype, I had the Handlers spit out the "real" URLs while VirtualFile.toURL() would return a "vfsfile:" based URL. The AbstractJarHandler would always return a "file:" based URL. Only jarentries would return a "jar:" based one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985574#3985574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985574

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Problem with VFS AbstractJarHandler / JarEntryHandler

by jason.greene＠jboss.com

Yes toUR()L does not include the slash because it uses the default implementation which just returns the cached URL, and the URL that is constructed in AbstractJarHandler uses the stripped entry name. Ok, since we need the entry name to have a stripped slash, I think the solution is to modify createVirtualFileHandler() in AbstractJarHandler to readd the slash to the URL that is passed to JarEntryHandler. I can include this change in the WS deployer rework if you like. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985573#3985573 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985573

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Document where non-String FQN do not work, JBCACHE-838

by genman

The JDBM cacheloader does support non-string FQN. BDBJE does not, but could by doing something like: | TupleOutput to = new TupleOutput(); | Fqn fqn = ... | fqn.writeExternal(to); | Actually, this would be a nice feature worth adding by having this configured by the cache configuration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985539#3985539 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985539

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests

by rachmatowicz＠jboss.com

I have a problem with the JBossMQ tests in package jmsra which needs some consideration. 1. The testsuite uses by default a classpath called tests.classpath to execute client-side JUnit test cases. This classpath is constructed automatically, with the help of jbossbuild, and includes among other things jars from third-party products imported from the repository. This includes Messaging, so that jboss-messaging.jar is included on tests.classpath. In order to get the client side tests to work, I need to override the versions of remoting and serialization which get included on tests.classpath. I do this by using the following classpath for my tests: ${build.classes} ${build.resources} thirdparty/jboss-messaging-client.jar tests.classpath This works fine and makes sure that the client side tests get the right versions of remoting and serialization. 2. Above and beyond this, the tests in package jmsra deploy a jar, jmsra.jar, which contains some EJBs used in the test; in particular, one called Publisher. When I run any test involving Publisher, I get the following remoting error: 2006-11-13 10:33:03,930 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.net.SocketException at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:352) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125) at org.jboss.remoting.Client.invoke(Client.java:589) at org.jboss.remoting.Client.invoke(Client.java:581) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:161) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:241) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:181) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) at $Proxy1.create(Unknown Source) at org.jboss.test.jbossmessaging.ra.RaJMSSessionUnitTestCase.testSendToQueueAndTopic(RaJMSSessionUnitTestCase.java:5\5) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) The above error occurs when calling the Publisher home.create() method. I believe this may be due to jmsra.jar being deployed in such a way that it picks up the non-modified version of remoting. (Is this correct?) Therefore, I believe that I need to somehow arrange for jmsra.jar to be deployed within the same scoped classloading context as Messaging, so that it will pick up the correct (modified) version of Remoting. jmsra.jar is deployed using the method JBossTestCase.deploy() method, which makes a "deploy" invocation on the MBean jboss.system:service=MainDeployer. Does anyone know the best way to deploy this jar in such a way that it gets loaded using the scoped deployment? I'll keep on investigating.. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985538#3985538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985538

19 years, 5 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 November 2006