Hi, on the whole I think it works verry nice. Great work. But...
On 27 Sep, David Jencks wrote:
> Hi Peter,
> 1. Right now you have to specifically undeploy a package and then redeploy
> it. Very shortly I should have it so that the autodeployer does this for
> you if a timestamp changes.
I tested to first remove the jms-service.xml and then copy it back. It
undeployes with some exception and that reports it deployes fine. But
any beans that was dependant in the jms-ra seems to have stoped working.
On the server side I get no error. But on the client side:
[java] Saying hello
[java] Error: java.rmi.ServerException: RemoteException occurred in server
thread; nested exception is:
[java] java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
[java] java.rmi.ServerException: null
[java] java.rmi.ServerException: null
[java] Embedded Exception
[snip]
[java] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServe
r(StreamRemoteCall.java:245)
[java] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCa
ll.java:220)
[java] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
[java] at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.i
nvoke(Unknown Source)
[java] at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeCont
ainer(Unknown Source)
[java] at org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.i
nvoke(Unknown Source)
[java] at $Proxy1.hello(Unknown Source)
[java] at org.jboss.docs.jms.ra.HelloClient.hello(HelloClient.java:62)
[java] at org.jboss.docs.jms.ra.HelloClient.main(HelloClient.java:70)
[java] java.lang.NullPointerException
[java] <<no stack trace available>>
I have not digged into this, but my first, this I have never seen befora
and it happened when I did a redeploy of jms-service.
Perhaps I am naive to expect to be able to redeploy a resource without
taking down any beans that depends on that resource.
When redeploying that bean I instead get a
javax.resource.spi.CommException: javax.naming.NameNotFoundException:
DefaultJMSProvider not bound. Perhaps the redeployment of jms-service
somehow took down the provider and never started it again?
>
> 2.a. Well, the j2ee deployer is configured to need Jetty, so I think the
> current deployment is consistent. maybe we need an alternate web-free
> deployment config. I guess we could turn the j2ee deployer inside out so
> the ContainerFactory and WebDeployer register with it, and it does what it
> can with its registered subdeployers. Is this a good idea?
>
> 2.b. I'm not sure complaining about missing stuff it quite appropriate --
> the point is to allow more flexible deployment order, but not to create the
> mbeans until the dependencies are satisfied. I do think it would be a good
> idea to show in the ServiceDeployerMBean what is waiting for deployment on
> which mbeans and which packages are suspended (because you undeployed a
> package they had in the classpath).
Well, I know I did something wrong. But on the other hand I like when
the server informs me when I do something wrong instead of going into
silence: "I will wait here untill you bummer understands that I am
pissed" or something like that.
>
> Thanks for your comments, I get used to how it is working currently so
> quickly I don't see the problems.
;-)
//Peter
>
> david jencks
>
> On 2001.09.27 07:05:38 -0400 Peter Antman wrote:
>> Hi,
>> I had to play a little with the sar deployer when testing the new jmsra
>> stuff, and I have a question: was it not meant that it should be
>> possible to reconfigure your resources hot, for instance to be able to
>> change the attributes of a resource in runtime without having to stop
>> the server.
>>
>> This seems not to work. When I for example change something in
>> jms-service.xml I get this message:
>>
>> [ServiceDeployer] not deploying package because it is already deployed:
>> file:/home/pra/src/rw/jboss-all/build/output/jboss-3.0.0alpha/deploy/jms-service.xml
>>
>>
>> Another thing: I had to exclude jetty when building since that was
>> broken. As a sideeffect the j2ee deplyer service never started. It
>> obviously was wating for the jetty service to be deployed. When that was
>> not available, it simply never started. And most importand of all, it
>> never complained. Should it not do that? Or is that to hard to
>> implement?
>>
>> //Peter
>> --
>> Jobba hos oss: http://www.tim.se/weblab
>> ------------------------------------------------------------
>> Peter Antman Technology in Media, Box 34105 100 26
>> Stockholm
>> Systems Architect WWW: http://www.tim.se
>> Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
>> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
>> ------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
