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

[Design the new POJO MicroContainer] - Re: NPE in CLSpace

by adrian＠jboss.org

"alesj" wrote : | And you end up with | | | JBoss-MC-Demo ERROR [04-12-2008 23:56:08] AbstractKernelController - Error resolving dependencies for ClassLoader: name=vfsfile:/C:/projects/demos/sandbox/deployers/ state=Describe mode=Manual requiredState=ClassLoader | | java.lang.NullPointerException | | at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:325) | | at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:122) | | at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:169) | | at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:325) | | at org.jboss.classloading.spi.dependency.Module.resolveModule(Module.java:737) | | at org.jboss.classloading.spi.dependency.RequirementDependencyItem.resolve(RequirementDependencyItem.java:87) | | at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:143) | | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1103) | | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1039) | | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) | | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) | | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) | | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) | | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545) | | at org.jboss.demos.bootstrap.MainDeployerHelper.process(MainDeployerHelper.java:86) | | | | The cause is the CLMD/module with import-all="true" and this code in Domain::addModule | | | // Skip the classloader space checking when it is import all | | if (module.isImportAll() == false) | | { | | ClassLoadingSpace space = new ClassLoadingSpace(); | | space.join(module); | | } | | | Module never joins any CLSpace. The NPE is obviously a bug, but the import-all not taking part in the ClassloadingSpace checking is correct. When you have import-all=true you can't really check consistency because the imports are not deterministic. i.e. you import everything so there is no way for it know what you actually import. The fix looks fairly trivial? | Module otherModule = module.resolveModule(dependency, false); | if (otherModule != null) | { | // Do we need to join with another classloading space? | ClassLoadingSpace space = otherModule.getClassLoadingSpace(); | - if (this != space) | + if (space != null && this != space) | space.joinAndResolve(this); | } | But we probably also want to log a warning if one of our explicit imports resolves to a module with import-all=true? i.e. the resolved module has no classloading space. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194608#4194608 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194608

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups

by timfox

"gaohoward" wrote : | 1. consumers of strict ordered messages cannot receive second message without first being acknowledged. | I don't agree. For ordering there is no requirement that previous message is acked first - that's an implementation detail. The only requirement is that messages are delivered in order. anonymous wrote : | 2. If we can guarantee strict ordering, there is no need to nail the ordered messages to one consumer. Consider if there are two consumers on one queue that deliver ordered messages. If one consumer gets a failure situation and is not able to consume anymore, the current message will not be acked (or will be rolled back), the other consumer may take over the job (as backup) and continue working (it may call session.recover() first). Will message group allow that happen? | Yes, with message grouping, if a consumer closes, another consumer will get pinned to that group. anonymous wrote : | 3. If user only wants message group, he shouldn't pay the performance cost brought by strict ordering. | What performance penalty is that? anonymous wrote : | 4. In failover and cluster cases, message group and strict ordering are handled differently. Consumer identity is critical for a message group to survive a failure, but sequence is vital to ordering. | I didn't understand this last point. Can you elaborate? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194578#4194578 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194578

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - netty http integration update

by ataylor

The basic http implementation we have would not work over a clever firewall, this is because it is not a true 1 - 1 mapping between request and response. To solve this we could do the following. The client send can will only change slightly. Since Http 1.1 supports request pipelining we should be able to send requests without waiting for a response, so the order could be req1 req2 req3 res1 res2 res3. The spec does say the following however: anonymous wrote : Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request. But I think it should be ok for our usage. The client will also need to send a 'bogus' request when idle for n seconds to make sure the connection isn't closed. The server cannot send an unsolicited response to a client but *must* send a response to every request.This should work as follows. The server does not send anything directly to the client, instead it keeps a list of 'Pending packets'. When the server receives a request it will initiate a response. any pending packets will be wrapped up in a single response and sent*. If there are no pending responses then the server will wait for a configurable amount of time for a pending message to arrive or send a bogus response, this is again to keep the connection alive. *wrapping up all pending packets into a single response will require a copy so theres an overhead, it may be better just to send back a single packet at a time but I'll need to test this to see. It all depends how many actual requests vs responses there are. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194574#4194574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194574

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Client Connect to INADDR_ANY is a no-no.

by david.lloyd＠jboss.com

Errr. Really? That's kinda.... errr. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194522#4194522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194522

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Client Connect to INADDR_ANY is a no-no.

by ALRubinger

The "clientBindUrl" doesn't define a binding, it tells the client where to connect (InvokerLocator URL). It's a *-jboss-beans.xml that'll make the server binding (Remoting Connector). Short answer: we agree. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194521#4194521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194521

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Client Connect to INADDR_ANY is a no-no.

by david.lloyd＠jboss.com

Not for that reason. Binding to 0.0.0.0 is just fine. It's connecting to 0.0.0.0 that is a strange thing to do. Though probably you want to bind to jboss.bind.address in any case...? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194520#4194520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194520

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Client Connect to INADDR_ANY is a no-no.

by ALRubinger

This begs the question of what to do with a grammar like: @RemoteBinding(clientBindUrl="socket://0.0.0.0:3873", jndiBinding="Stateful3873"), It'd be better to have an EL available so we could do: @RemoteBinding(clientBindUrl="socket://${jboss.bind.address}:3873", jndiBinding="Stateful3873"), Worthy of a JIRA? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194519#4194519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194519

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Client Connect to INADDR_ANY is a no-no.

by ALRubinger

Lately we've been bugged by discrepancies between Hudson environments running the EJB Integration TestSuite. I found DML on #jboss this evening and asked him if a client connect to 0.0.0.0 was bad (some reading I found hinted at this) and he and Jason agree "yes, don't do it". (09:54:26 PM) Nihility: yeah it just picks an interface | (09:54:30 PM) Nihility: like playing slots | (09:54:42 PM) dmlloyd: connecting to 0.0.0.0 *finds* the service running on only 127.0.0.1 | (09:54:47 PM) dmlloyd: that's very weird | (09:55:56 PM) dmlloyd: http://twistedmatrix.com/trac/ticket/1472 | (09:56:07 PM) dmlloyd: doesn't work on winders | (09:59:40 PM) dmlloyd: the little bit I can find implies that it's not a great idea Therefore: https://jira.jboss.org/jira/browse/EJBTHREE-1610 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194518#4194518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194518

17 years, 4 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: NPE taking snapshots

by jesper.pedersen

Could you try rev517 and see if that fixes your problem ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194513#4194513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194513

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Management component?

by kukeltje

I'd like to go for xforms in any form as well. But serverside xforms. I'm still trying to wrap chiba (https://www.r15z.de/trac, with self-signed cert) into a jsf component that can be used with seam. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194498#4194498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194498

17 years, 4 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 December 2008