ah man... "reply-all" trigger happy... this was meant private sorry...
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
|Sent: Wednesday, November 08, 2000 1:14 PM
|To: jBoss Developer
|Subject: RE: [jBoss-Dev] J2EE deployer troubles
|
|
|Daniel,
|
|good handling of it, it is normal and proves your stuff is being used. Do
|pay attention to what they say and you will get a kick ass deployer. I
|think you are almost there, let the open source feedback get you
|there, just
|ride it, don't fight it.
|
|ok on a personal note, I do need your bio and picture asap since you have
|been upgrade to "supah-stah" ;-) as a significant code owner.
|
|regards
|
|marc
|
|
||-----Original Message-----
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Schulze
||Sent: Wednesday, November 08, 2000 12:50 PM
||To: jBoss Developer
||Subject: Re: [jBoss-Dev] J2EE deployer troubles
||
||
||Rickard,
||
||> Since you point a URLClassLoader at it I would guess that you
||will never be
||> able to remove it. Right?
||
||Yep on Win2k! On my Linux box it works fine :-)
||
||> > Once I know what type I have to deploy, I install it from the original
||> > source. This doesnt seem smart, especially if we dont have much
||> > bandwidth. But it was simpler to only pass the original source
||location,
||> > which is needed to find libraries referenced by
|MANIFEST.MF/Class-Path:
||> > entries in case of ejb or war packages.
||> > I agree its not a clean solution, so maybe I should change this...
||>
||> Ok. Yeah you should change to always deploy on the localCopy.
||This way it is
||> always possible to put in a new version in /deploy. Right now it doesn't
||> work very well (about half of my redeployments fail, consistently).
||
||Ok will change that immediately...
||
||> > This is a bug! ...in the AutoDeployer. The AutoDeployer calls the
||> > J2eeDeployer too early (before the copy (or jar operation) on OS level
||> > is completed).
||>
||> No, that's not it. I made the wait longer, and it still appears. It is
||> something else.
||
||Hmmm... ???
||I will try to investigate that...
||
||> Also, if I restart the server, does the J2EE deployer redeploy
||ones that are
||> not autodeployed? I.e. if I call deploy() through JMX and then
||restart, will
||> it redeploy the package? If it doesn't, it should.
||
||Uuhhh, this is a completely different story.
||Since I remove all from the tmp/deploy directory on service startup, I
||dont have anything left to redeploy (just read the deploymnet.cfg file
||and call startApplication ())...
||
||Ok, this is the Window hack but anyway I was thinking about that issue
||too, especially on server crashes (will never happen ;-) it would be
||fine to be able to recover the state of deployment (as I had this in an
||earlier version). But how would that behave in conjunction with the
||Autodeployer? J2eeDeployer starts, recoveres all deployments,
||Autodeployer starts, redeploys all apps that are still available in the
||observed directories.
||
||Do you have an idea how to crack that (or anyone else)?
||
||
||\Daniel
||
||>
||> /Rickard
||
||
|
|
|
