[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by David Lloyd
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521552#521552
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:adrian@jboss.org wrote:
>
> > mailto:david.lloyd@jboss.com wrote:
> >
> > > mailto:adrian@jboss.org wrote:
> > >
> > > Editor, ate my post again. ;-)
> > >
> > > Following the last comment, I'm not sure you wouldn't want more fine grained control on
> > > which dependencies start your bean?
> > >
> > > <bean name="A" mode="On Demand">
> > > <property name="b"><inject bean="B" transitive-start="true"/></property>
> > > <bean>
> > >
> > > <bean name="B" mode="On Demand"/>
> > Ah, that would be neat. Let me see if I can wrap my brain around that...
> >
> > So in this example, transitive-start would really mean that the targeted bean would control when this bean starts. So the question is, if you had two such injected bean properties, when would A start? When either injection is started, or only when both are?
> You could make a configuration option, e.g. something like
>
> Require both dependencies to start:
>
> <bean name="A" mode="On Demand">
> <property name="b"><inject bean="B" transitive-start="required"/></property>
> <property name="c"><inject bean="C" transitive-start="required"/></property>
> <bean>
>
> Any one
>
> <bean name="A" mode="On Demand">
> <property name="b"><inject bean="B" transitive-start="optional"/></property>
> <property name="c"><inject bean="C" transitive-start="optional"/></property>
> <bean>
>
>
> But unless starting A triggers some other knock-on effects, the second example is likely to stall with a missing dependency anyway. ;-)
> So I think you'd probably want all the dependencies marked transitive-start anyway?
The effect I'm envisioning for the latter case would run like this:
1. Something ("D") depending on C is started
2. This causes A to want to be demanded
3. A then demands that B start, since A has been demanded
4. A, B, and C are all started because D depended on C
Not sure if that really makes sense in terms of use case though. Also (disclaimer!) I'm not sure that I'm using the term "demand" correctly in this context.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521552#521552
16 years, 3 months
[JBoss Cache] New message: "NPE in ClusteredCacheLoader (JBoss Cache 3.2.1.GA)"
by Jamie S
User development,
A new message was posted in the thread "NPE in ClusteredCacheLoader (JBoss Cache 3.2.1.GA)":
http://community.jboss.org/message/521550#521550
Author : Jamie S
Profile : http://community.jboss.org/people/jamie.s
Message:
--------------------------------------------------------------
Hello,
Trying out a chained cacheloader configuration.
Previously, I had JDBCCacheLoader as the only loader, and that is working properly.
Now, I want to delegate to the cluster first, so I added ClusteredCacheLoader first.
However, when I start the first node in the cluster, and get to my first API call (which is addChild() ), I hit an NPE in clustered cache loader:
java.lang.NullPointerException
at org.jboss.cache.loader.ClusteredCacheLoader.exists(ClusteredCacheLoader.java:212)
Which I take to mean commandsFactory is null:
public boolean exists(Fqn name) throws Exception
{
// DON'T make a remote call if this is a remote call in the first place - leads to deadlocks - JBCACHE-1103
if (!isCacheReady() || !cache.getInvocationContext().isOriginLocal()) return false;
lock.acquireLock(name, false);
try
{
ExistsCommand command = commandsFactory.buildExistsNodeCommand(name);
Object resp = callRemote(command);
return resp != null && (Boolean) resp;
}
finally
{
lock.releaseLock(name);
}
}
It would seem though, that isCacheReady returned true, and the invocationContext says it's a local call...
Here's my loader config:
<loaders passivation="false" shared="false">
<loader
class="org.jboss.cache.loader.ClusteredCacheLoader"
async="false"
ignoreModifications="true"
>
<properties>
timeout=1500
</properties>
</loader>
<!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
<loader
class="org.jboss.cache.loader.JDBCCacheLoader"
async="false"
fetchPersistentState="true"
ignoreModifications="false"
purgeOnStartup="false">
<properties>
cache.jdbc.table.name=jbosscache
cache.jdbc.table.create=true
cache.jdbc.table.drop=false
cache.jdbc.table.primarykey=jbosscache_pkey
cache.jdbc.fqn.column=fqn
cache.jdbc.fqn.type=VARCHAR(255)
cache.jdbc.node.column=node
cache.jdbc.node.type=bytea
cache.jdbc.parent.column=parent
cache.jdbc.driver=org.postgresql.Driver
cache.jdbc.url=jdbc:postgresql:testdb
cache.jdbc.user=+deleted+
cache.jdbc.password=+deleted+
</properties>
</loader>
</loaders>
And finally, the stack trace back to my call:
java.lang.NullPointerException
at org.jboss.cache.loader.ClusteredCacheLoader.exists(ClusteredCacheLoader.java:212)
at org.jboss.cache.loader.AbstractDelegatingCacheLoader.exists(AbstractDelegatingCacheLoader.java:94)
at org.jboss.cache.loader.ChainingCacheLoader.exists(ChainingCacheLoader.java:128)
at org.jboss.cache.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:311)
at org.jboss.cache.interceptors.CacheLoaderInterceptor.visitGetNodeCommand(CacheLoaderInterceptor.java:176)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitGetNodeCommand(AbstractVisitor.java:115)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitGetNodeCommand(AbstractVisitor.java:115)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
at org.jboss.cache.commands.AbstractVisitor.visitGetNodeCommand(AbstractVisitor.java:115)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitGetNodeCommand(AbstractVisitor.java:115)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:130)
at org.jboss.cache.commands.AbstractVisitor.visitGetNodeCommand(AbstractVisitor.java:115)
at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76)
at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
at org.jboss.cache.invocation.CacheInvocationDelegate.getNode(CacheInvocationDelegate.java:494)
at org.jboss.cache.invocation.NodeInvocationDelegate.getChild(NodeInvocationDelegate.java:361)
at org.jboss.cache.invocation.NodeInvocationDelegate.*addChild*(NodeInvocationDelegate.java:330)
at com.whatever.configuration.initCache(configuration.java:134)
Anyone run into anything like this before?
I can't imagine it is the configuration of the ClusteredCacheLoader, that's pretty straight forward.
Thanks for any input,
Jamie
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521550#521550
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by Adrian Brock
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521548#521548
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
> mailto:david.lloyd@jboss.com wrote:
>
> > mailto:adrian@jboss.org wrote:
> >
> > Editor, ate my post again. ;-)
> >
> > Following the last comment, I'm not sure you wouldn't want more fine grained control on
> > which dependencies start your bean?
> >
> > <bean name="A" mode="On Demand">
> > <property name="b"><inject bean="B" transitive-start="true"/></property>
> > <bean>
> >
> > <bean name="B" mode="On Demand"/>
> Ah, that would be neat. Let me see if I can wrap my brain around that...
>
> So in this example, transitive-start would really mean that the targeted bean would control when this bean starts. So the question is, if you had two such injected bean properties, when would A start? When either injection is started, or only when both are?
You could make a configuration option, e.g. something like
Require both dependencies to start:
<bean name="A" mode="On Demand">
<property name="b"><inject bean="B" transitive-start="required"/></property>
<property name="c"><inject bean="C" transitive-start="required"/></property>
<bean>
Any one
<bean name="A" mode="On Demand">
<property name="b"><inject bean="B" transitive-start="optional"/></property>
<property name="c"><inject bean="C" transitive-start="optional"/></property>
<bean>
But unless starting A triggers some other knock-on effects, the second example is likely to stall with a missing dependency anyway. ;-)
So I think you'd probably want all the dependencies marked transitive-start anyway?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521548#521548
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by David Lloyd
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521547#521547
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:adrian@jboss.org wrote:
>
> Ok, then another way might be:
>
> <bean name="A1" mode="On Demand">
> <incallback property="b"/>
> <bean>
>
> <bean name="A2" mode="On Demand">
> <incallback property="b"/>
> <bean>
>
> <bean name="B" mode="On Demand"/>
>
> But the CallbackDependencyItem also overrides
> resolve(Controller)
> and so doesn't do the enableOnDemand()
>
> What the above should do, is that when B gets
> installed, all the beans that want an instance of that
> class get enabled with their setB() method invoked.
>
>
Replying to the first post last... perhaps I can work around this by creating a subclass of CallbackDependencyItem since I'm building this up programmatically anyway?
I might give that a go...
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521547#521547
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by David Lloyd
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521543#521543
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:adrian@jboss.org wrote:
>
> Editor, ate my post again. ;-)
>
> Following the last comment, I'm not sure you wouldn't want more fine grained control on
> which dependencies start your bean?
>
> <bean name="A" mode="On Demand">
> <property name="b"><inject bean="B" transitive-start="true"/></property>
> <bean>
>
> <bean name="B" mode="On Demand"/>
Ah, that would be neat. Let me see if I can wrap my brain around that...
So in this example, transitive-start would really mean that the targeted bean would control when this bean starts. So the question is, if you had two such injected bean properties, when would A start? When either injection is started, or only when both are?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521543#521543
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by Adrian Brock
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521537#521537
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
david.lloyd(a)jboss.com wrote:>
> It seems like there should be another controller mode which means "automatic but does not demand dependencies". It's not really a circular dependency, in principle at least, as B doesn't know or care about its A dependencies really, other than in the regular dependency graph sense i.e. "I've started up, now all my dependents may start".
I don't know if it would be a new controller mode?
You mean something like:
<bean name="A" mode="On Demand Transitive">
<property name="b"><inject bean="B" /></property>
<bean>
<bean name="B" mode="On Demand"/>
Which would have the semantic of starting A when all its dependencies have started, i.e. B in this case.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521537#521537
16 years, 3 months