July 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - FileHandler.getChildren IOException for non-dirs

by scott.stark＠jboss.org

I'm seeing a failure due to the behavior of the FileHandler.getChildren method when called for a non-dir file. I don't know why we want to do this as it makes it difficult to handle files consistently. It would seem better to return an empty list. | 18:01:42,239 WARN [DeployersImpl] DeploymentContext has no DeploymentControllerContext during undeploy request, ignoring: AbstractVFSDeploymentContext@1587954306{vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testAddDataSource-dsf.xml} | 18:01:42,258 ERROR [EJBRegistrationDeployer] Error during deploy: vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testAddDataSource-dsf.xml | org.jboss.deployers.spi.DeploymentException: java.lang.RuntimeException: java.io.IOException: Error listing files: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testAddDataSource-dsf.xml | at org.jboss.ejb3.deployers.EJBRegistrationDeployer.deploy(EJBRegistrationDeployer.java:172) | at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.deploy(AbstractVFSRealDeployer.java:45) | ... | Caused by: java.io.IOException: Error listing files: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testAddDataSource-dsf.xml | at org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:146) | at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:109) | at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:165) | at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:134) | at org.jboss.virtual.VFS.visit(VFS.java:313) | at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:363) | at org.jboss.ejb3.deployers.JBoss5DeploymentUnit.getResources(JBoss5DeploymentUnit.java:186) | ... 30 more | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065226#4065226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065226

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4277 Design

by JerryGauth

If a simpler configuration based solution is desirable, we could simply offer the use of the calling thread's context classloader, instead of requiring the caller to provide a classloader. This would be accomplished via a boolean configuration attribute and the startService() method would make the appropriate registration. We wouldn't need to provide a classloader attribute. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065223#4065223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065223

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: HAServiceMBeanSupport.callMethodOnPartition() doesn't re

by bstansberry＠jboss.com

That sure sounds like an oversight to me. The return type would have to ArrayList, which is a bit odd for the uninitiated, but that doesn't seem like a reason not to return values. Side note: ArrayList??? Seems we should consider changing HAPartition.callMethodOnCluster to return List. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065218#4065218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065218

18 years, 8 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Serialization with NIO

by michael.neale＠jboss.com

I would like to register interest in this - for rules. Although our specific problem is our deeply linked data structures - default serialization uses recursion heavily and we often blow the stack. A non recursive serialization algorithm would be brilliant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065209#4065209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065209

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Running with the full featured profile service

by bytor99999

Thanks Scott, AS is now starting up with the ProfileService. Now for the bad news, only 3 of the 13 ProfileServiceUnitTestCase Test methods pass. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065195#4065195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065195

18 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Consolidate delegating cache loader classes [JBCACHE-113

by galder.zamarreno＠jboss.com

Re 1 - OK --> this needed doing to avoid confusion. Re 2 - setCL/getCL are already in ADCL, so I'm happy to leave them either public or protected. Protected might make more sense cos only o.c.j.loader code or subclasses should be using it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065191#4065191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065191

18 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Transport Use Cases

by david.lloyd＠jboss.com

Right now there are a set of socket-based transports (including bisocket, multiplex, and socket, and encrypted variants), RMI, and a few HTTP-based transports. There are a few other transports that are on the table - JGroups, SSH. Also, I've seen some informal requests go by for much more esoteric transport mechanisms - like FTP, email, and that sort of thing. Is there a use case for these transports? Honestly I can't see why someone would use RMI (or the other socket transports) if there was a single socket transport that provided authentication, (possibly keyless) encryption, bidirectional communication, asynch request/replies, and multiplexing multiple requests or sessions on the same connection. HTTP seems useful in the case where a firewall prevents regular socket communication. Apart from that, it would probably be inferior (performancewise) to a single socket as described above. I'm not sure of the utility of a JGroups transport - certainly it could be done, but would this add any value over what JGroups does today? As for the other transports - FTP, email, etc. - are these truly appropriate to Remoting? Perhaps those types of transports are more suited towards a SOAP-like approach? If they really are wanted, then JIRA issues should be opened for each transport, along with a sketch of requirements and a use case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065169#4065169 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065169

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-4277 Design

by JerryGauth

JBAS-4277 notes that HAServiceMBeanSupport should be modified to take advantage of JBAS-4106, which allows association of a classloader with the cluster's RPC handler. HAServiceMBeanSupport is a base class intended for extension by cluster services. This class allows extenders to invoke RPC methods on a cluster without having to register the service as a handler, since the base class does this during startService(). To support invocation of RPC calls in the context of a scoped classloader, it's necessary to provide a reference to the classloader when registering the handler. The purpose of this issue is to modify HAServiceMBeanSupport to allow this registration. One simple solution is to modify HAServiceMBeanSupport by adding get/setRPCClassLoader(ClassLoader) to the api and implementation. This will set an instance variable in the base class for the classloader. When the service is registered as an RPCHandler with HAPartition, the classloader registration will be used if the variable is non-null. This approach should be fine if the classloader is set before startService() is called on the base class. However services aren't required to explicitly invoke this method so this could require services to override startService() , set the classloader, and then invoke it on the super class. To handle services which don't want to override startService(), the setRPCClassLoader() method can re-register the RPC handler if it's already been registered (i.e., by HAServiceMBeanSupport.startService). This is supported by ClusterPartition and will result in the classloader being associated with the service as desired. Once the client has set the classloader, subsequent RPC calls will use the designated classloader. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065149#4065149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065149

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"alesj" wrote : | I'll ditch my crap and rewrite this to the upper features. | I've added FromContext to AbstractInjectionValueMetaData to handle injection form (Kernel|XYZ)ControllerContext. | <bean name="set_name_bean" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="name"><inject fromContext="name"/></property> | </bean> | | <beanfactory name="set_name_factory" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="name"><inject fromContext="name"/></property> | </beanfactory> | | <bean name="metadata" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="metadata"><inject fromContext="metadata"/></property> | </bean> | | <bean name="scopekey" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="scopeKey"><inject fromContext="scope"/></property> | </bean> | | <bean name="dynamic" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="dynamic"><inject fromContext="getBeanMetaData"/></property> | </bean> | | <bean name="other" class="org.jboss.test.kernel.deployment.support.NameAwareBean"> | <property name="name"><inject bean="set_name_bean" fromContext="name"/></property> | </bean> | Currently there are these lookups / injections defined: - name - metadata - scope - id - dynamic If none of the first 4 is recognised, dynamic is used. Dynamic tries to execute the getter method gained from the actual string value of fromContext attribute on the underlying context. | public Object executeLookup(ControllerContext context) throws Throwable | { | Method method = findMethod(context.getClass()); | if (method == null) | throw new IllegalArgumentException("No such getter on context class: " + getFromString()); | return ReflectionUtils.invoke(method, context, new Object[]{}); | Is this dynamic OK to stay? I added it to cover some exotic cases on-the-fly, but I can easily remove it. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065125#4065125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065125

18 years, 8 months

1
0
0 / 0

[QA of JBoss Portal] - Re: SSO Unit Testing

by julien＠jboss.com

keep in mind you can copy the way that portals deploy the jaas security domain using an mbean and a login-config file, that will help you to avoid to have to modify login-config of app server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065097#4065097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065097

18 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 July 2007