I am using something like this:
<attribute name="URLs">
../deploy/lib,
../deploy/bean1.jar,
../deploy/bean2.jar
</attribute>
Since the beans are already urls ready for deploying they are added to the
list right away. The lib directory is only scanned once a pass is made on
run(), which will find some files, but append them after the urls that are
explict.
I fixed this by simply scanning the directories after adding the directory
url to the watch list.
It seems to work fine.
I am having another problem with a NPE when trying to get a connection from
the datasource, perhaps my config is wrong... but the logs do not really
tell me what is wrong, which I was looking into fixing. Below is my config
if you could tell me what is wrong with it that would be swell:
<!-- Shared DataSource ConnectionFactoryLoader -->
<mbean code="org.jboss.resource.ConnectionFactoryLoader"
name="DefaultDomain:service=ConnectionFactoryLoader,name=SharedDS">
<attribute name="Properties">
ConnectionURL=jdbc:oracle:thin:@bendev:1521:BENDV
JDBCUser=jason
Password=jason
</attribute>
<attribute name="FactoryName">
SharedDS
</attribute>
<attribute name="TransactionManagerName">
java:/TransactionManager
</attribute>
<attribute name="ResourceAdapterName">
Minerva JDBC XATransaction ResourceAdapter
</attribute>
<attribute name="RARDeployerName">JCA:service=RARDeployer</attribute>
<attribute name="ConnectionManagerFactoryName">
MinervaXACMFactory
</attribute>
<attribute name="ConnectionManagerProperties">
InvalidateOnError=false
Blocking=true
IdleTimeoutMillis=1800000
MaxSize=10
TimestampUsed=false
IdleTimeoutEnabled=false
GCIntervalMillis=120000
MinSize=0
GCMinIdleMillis=1200000
GCEnabled=false
MaxIdleTimeoutPercent=1.0
</attribute>
<attribute name="PrincipalMappingClass">
org.jboss.resource.security.ManyToOnePrincipalMapping
</attribute>
<attribute name="PrincipalMappingProperties">
</attribute>
</mbean>
--jason
On Thu, 16 Aug 2001, David Jencks wrote:
> Hi jason, I forgot about this problem.
>
> AutoDeploy works ok for me if the autodeployer conf looks like this:
>
> <mbean code="org.jboss.ejb.AutoDeployer" name="EJB:service=AutoDeployer">
> <attribute name="Deployers">
> JCA:service=RARDeployer;
> J2EE:service=J2eeDeployer
> </attribute>
> <attribute name="URLs">
> ../deploy/lib,
> ../deploy
> </attribute>
> <attribute name="Timeout">
> 3000
> </attribute>
> </mbean>
>
> Note that I reversed RARDeployer and J2eeDeployer as well as the directory
> order. (For me just having ../deploy.lib before ../deploy worked, maybe
> reversing both will fix it for you).
>
> If this doesn't fix it for you could you send me your AutoDeployer conf?
>
> thanks
> david
>
> On 2001.08.16 15:08:58 -0400 Jason Dillon wrote:
> > I just switched over and found one rather large problem, that is that my
> > beans deploy before the resource adapters. It could be that I am
> > explicitly
> > listing the .jars to deploy, but I have the deploy/lib directory listed
> > before it, so I expected that it would do the right thing.
> >
> > I think it will work if I touch all the files and force the auto deployer
> > to
> > re-deploy once the datasources have been bound to jndi.
> >
> > Do you (or anyone else) have any ideas on how to fix this, or should I
> > look
> > into it?
> >
> > --jason
> >
> >
> > On Wed, 15 Aug 2001, David Jencks wrote:
> >
> > > Hi Jason, could you try converting to the jca version of db access and
> > see
> > > if the problem persists? I recently found a race condition in (the jca
> > > versions) of the code that releases connections back to the pool after
> > > transactions complete that was allowing several transactions to access
> > the
> > > same connection. Maybe a similar bug is present in the non-jca code.
> > I'm
> > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later
> > > today, in case you don't want to try the conversion by hand. (this race
> > fix
> > > is only in rabbit hole).
> > >
> > > Thanks
> > > david jencks
> > >
> > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote:
> > > > I was trying to track down a concurrency problem which would show up
> > as
> > > > an
> > > > Oracle deadlock exception. It looks like that exception was
> > happening
> > > > due
> > > > to some fk constraints causing parent tables to lock and such. Any
> > ways,
> > > > after I got that deadlock exception, I got a ton of these session
> > bean
> > > > context errors.
> > > >
> > > > I think that I have fixed the deadlock problem by removing some of
> > the fk
> > > > constraints (which I don't like too much, but it stopped the
> > exception
> > > > from
> > > > being thrown), but I am still getting these errors.
> > > >
> > > > I thought they were caused by the oracle problem, but now I think
> > there
> > > > might be something else going on.
> > > >
> > > > Does anyone have any ideas on why this might happen, and or how I
> > might
> > > > go
> > > > about fixing it? The TX stuff is still a bit of a mystery to me.
> > Any
> > > > help
> > > > would be appreciated.
> > > >
> > > > Below is the log of the exception thrown.
> > > >
> > > > --jason
> > > >
> > > >
> > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread
> > Pool
> > > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error:
> > tried
> > > > to
> > > > enter Stateful bean with different transaction context; nested
> > exception
> > > > is:
> > > > java.rmi.RemoteException: Application Error: tried to enter
> > > > Stateful
> > > > bean with different transaction context
> > > >
> > > > ...
> > > >
> > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor [Thread
> > Pool
> > > > Worker] ERROR - Detail
> > > > java.rmi.RemoteException: Application Error: tried to enter Stateful
> > bean
> > > > with different transaction context
> > > > at
> > > >
>org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207)
> > > > at
> > > >
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97)
> > > > at
> > > >
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154)
> > > > at
> > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63)
> > > > at
> > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168)
> > > > at
> > > >
>org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354)
> > > > at
> > > >
>org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445)
> > > > at
> > > >
>org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339)
> > > > at
> > > >
>org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136)
> > > > at $Proxy28.handle(Unknown Source)
> > > > at
> > > >
>com.boldfish.does.job.service.internal.ResponseProcessorEJB.process(ResponseProcessorEJB.java:152)
> > > > at
> > > >
>com.boldfish.ejb.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:132)
> > > > at java.lang.reflect.Method.invoke(Native Method)
> > > > at
> > > >
>org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:410)
> > > > at
> > > >
>org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:79)
> > > > at
> > > >
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97)
> > > > at
> > > >
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154)
> > > > at
> > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63)
> > > > at
> > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128)
> > > > at
> > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168)
> > > > at
> > > > org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:285)
> > > > at
> > > >
>org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:165)
> > > > at
> > > >
>org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:644)
> > > > at
> > > >
>org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:290)
> > > > at
> > > > org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:257)
> > > > at org.jboss.mq.SpySession.run(SpySession.java:176)
> > > > at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
> > > > at
> > > >
>EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
> > > > at java.lang.Thread.run(Thread.java:484)
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
