[JBoss-dev] Installer / Deployer Problem
Hi Geeks In the Installer all deployed application are copyed and then inflated (right now in "/deploy/Default/"). During this inflation the name of the contained archives are lost. As example for an JAR file it will be renamed to ejb1002.jar. Unfortunately the mapping of the orginal archive name is lost but JSR-77 needs to know the name of the archive. QUESTION: Is this a problem to keep the orignal name of the archive ? Andy x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|Hi Geeks | |In the Installer all deployed application are copyed and then |inflated (right now in "/deploy/Default/"). During this inflation |the name of the contained archives are lost. As example for |an JAR file it will be renamed to ejb1002.jar. | |Unfortunately the mapping of the orginal archive name is lost |but JSR-77 needs to know the name of the archive. | |QUESTION: Is this a problem to keep the orignal name of |the archive ? not that I know, the original deployer was a piece of crap anyway, fix this if you want. BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require the 1.4 VM for proper behavior of the deployer I think it would greatly simplify the design as we wouldn't need to copy the files over. Also teh copying gets to be slow when the stuff is too big, marcf | |Andy | |x |Andreas Schaefer |Senior Consultant |JBoss Group, LLC |x | | |___ |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
Re: [JBoss-dev] Installer / Deployer Problem
Ok, then I will also do this changes: - rearrange Deployment and Application therefore I can be used to pass information from Installer/J2eeDeployer to ContainerFactory - ContainerFactory should not be called directly therefore I will remove the convenience deploy() method accepting a String instead of an URL Andy BTW I will check if the problem is fixed in JDK1.4. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Andreas Schaefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 8:07 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem > |Hi Geeks > | > |In the Installer all deployed application are copyed and then > |inflated (right now in "/deploy/Default/"). During this inflation > |the name of the contained archives are lost. As example for > |an JAR file it will be renamed to ejb1002.jar. > | > |Unfortunately the mapping of the orginal archive name is lost > |but JSR-77 needs to know the name of the archive. > | > |QUESTION: Is this a problem to keep the orignal name of > |the archive ? > > not that I know, the original deployer was a piece of crap anyway, fix this > if you want. > > BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require > the 1.4 VM for proper behavior of the deployer I think it would greatly > simplify the design as we wouldn't need to copy the files over. > > Also teh copying gets to be slow when the stuff is too big, > > marcf > | > |Andy > | > |x > |Andreas Schaefer > |Senior Consultant > |JBoss Group, LLC > |x > | > | > |___ > |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
RE: [JBoss-dev] Installer / Deployer Problem
|It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. but in any case until we know what it takes to open and close a connection that would be the simplest. Go ahead and also try to get some number on "how much time to open one connection to file/10 connections/ lookup a class randomly in the 10 that are there"... if you get that in time for the rewrite it would really make the work simple. marcf | |/Rickard | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
rickard, following my own mantra of "communicate simple", go right ahead and create a URLConnection that closes the connection after some time or every time, maybe even every time is enough. That will solve our problem for sure the vm will not be holding on to connections to the file system and we will be able to hotdeploy on the original files. The discussion I have below only affects "loading" times when new classes are deployed and we can always measure that and deal with it. So KISS the URL. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Tuesday, November 27, 2001 12:14 PM |To: Rickard Öberg |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | ||It's not fixed. Marc, do you remember when we were at J1 and talked to ||your french friend that said something about it being a security hole if ||it was fixed. Or something like that. | |Are you sure it is not fixed? as in you verified or as in you took |what this |guy said at face value (name is jc collet btw), I wouldn't trust everything |he said :) you know we were friends and all but... | ||I've been thinking about this problem though. Wouldn't it be possible to ||make a custom URL handler that returns a connection wrapper that we can ||drop under the covers. I.e. even if the URLClassLoader hangs onto it, we ||can still close the file under the covers. I think that would make it ||work, and wouldn't be *that* intrusive in the code. | |sure, that is an idea and it would simplify the code a lot. The problem I |see is that I suspect they keep the connection opened for classloading |reasons, i.e. the VM asks for loading classes at random times. |Reopening the |connection seems slow (the security hole would be the capability to change |the jar we look up???). | |I guess the way this works is you would put a time out on the URL or |something, you need to make guesses as to when the vm will be done loading |from this puppy which is never in the case of JMX and SL CL architectures. | |A problem will be slow classloading in the JMX/SL base (it will affect 2.4 |and 3.0) as you will ask CL to look for classes in connections that are |closed... h we are going to need smart CLs... at least with |indexing, yes... indexing of cl contents to allow for fast clusterwide |lookups h me likes... do you see these? is there a way to create a |default jar tvf (t being the important one here) and allowing for indexing |PER Cl, that would dramaticaly improve the speed of our |superservers as well |as solve the above problem. | |but in any case until we know what it takes to open and close a connection |that would be the simplest. | |Go ahead and also try to get some number on "how much time to open one |connection to file/10 connections/ lookup a class randomly in the 10 that |are there"... if you get that in time for the rewrite it would really make |the work simple. | |marcf | | || ||/Rickard || ||-- ||Rickard Öberg || | | |___ |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
Re: [JBoss-dev] Installer / Deployer Problem
Hi I don't see the point here. The copying of the file is done when it get deployed and this is a rare occurance. When you now have to open/close the connection to the URL then it can affect the overall performance which I think is the worse that to copy the file. Also the file must inflated anyway and do I miss something ? Andy - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Rickard Öberg" <[EMAIL PROTECTED]> Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 9:13 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem > |It's not fixed. Marc, do you remember when we were at J1 and talked to > |your french friend that said something about it being a security hole if > |it was fixed. Or something like that. > > Are you sure it is not fixed? as in you verified or as in you took what this > guy said at face value (name is jc collet btw), I wouldn't trust everything > he said :) you know we were friends and all but... > > |I've been thinking about this problem though. Wouldn't it be possible to > |make a custom URL handler that returns a connection wrapper that we can > |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we > |can still close the file under the covers. I think that would make it > |work, and wouldn't be *that* intrusive in the code. > > sure, that is an idea and it would simplify the code a lot. The problem I > see is that I suspect they keep the connection opened for classloading > reasons, i.e. the VM asks for loading classes at random times. Reopening the > connection seems slow (the security hole would be the capability to change > the jar we look up???). > > I guess the way this works is you would put a time out on the URL or > something, you need to make guesses as to when the vm will be done loading > from this puppy which is never in the case of JMX and SL CL architectures. > > A problem will be slow classloading in the JMX/SL base (it will affect 2.4 > and 3.0) as you will ask CL to look for classes in connections that are > closed... h we are going to need smart CLs... at least with > indexing, yes... indexing of cl contents to allow for fast clusterwide > lookups h me likes... do you see these? is there a way to create a > default jar tvf (t being the important one here) and allowing for indexing > PER Cl, that would dramaticaly improve the speed of our superservers as well > as solve the above problem. > > but in any case until we know what it takes to open and close a connection > that would be the simplest. > > Go ahead and also try to get some number on "how much time to open one > connection to file/10 connections/ lookup a class randomly in the 10 that > are there"... if you get that in time for the rewrite it would really make > the work simple. > > marcf > > > | > |/Rickard > | > |-- > |Rickard Öberg > | > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 12:57 PM |To: marc fleury; Rickard Öberg |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi | |I don't see the point here. The copying of the file is done when it get |deployed |and this is a rare occurance. When you now have to open/close the It really slows down large deployment. Copying 2 meg is just bad. Again packaging madness. |connection |to the URL then it can affect the overall performance which I think is the |worse |that to copy the file. |Also the file must inflated anyway and do I miss something ? it's a point, I don't care either way. But when do you need to "inflate" and why? refresh my memory marcf | |Andy | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: "Rickard Öberg" <[EMAIL PROTECTED]> |Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; |<[EMAIL PROTECTED]> |Sent: Tuesday, November 27, 2001 9:13 AM |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | |> |It's not fixed. Marc, do you remember when we were at J1 and talked to |> |your french friend that said something about it being a security hole if |> |it was fixed. Or something like that. |> |> Are you sure it is not fixed? as in you verified or as in you took what |this |> guy said at face value (name is jc collet btw), I wouldn't trust |everything |> he said :) you know we were friends and all but... |> |> |I've been thinking about this problem though. Wouldn't it be possible to |> |make a custom URL handler that returns a connection wrapper that we can |> |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |> |can still close the file under the covers. I think that would make it |> |work, and wouldn't be *that* intrusive in the code. |> |> sure, that is an idea and it would simplify the code a lot. The |problem I |> see is that I suspect they keep the connection opened for classloading |> reasons, i.e. the VM asks for loading classes at random times. Reopening |the |> connection seems slow (the security hole would be the capability |to change |> the jar we look up???). |> |> I guess the way this works is you would put a time out on the URL or |> something, you need to make guesses as to when the vm will be |done loading |> from this puppy which is never in the case of JMX and SL CL |architectures. |> |> A problem will be slow classloading in the JMX/SL base (it will |affect 2.4 |> and 3.0) as you will ask CL to look for classes in connections that are |> closed... h we are going to need smart CLs... at least with |> indexing, yes... indexing of cl contents to allow for fast clusterwide |> lookups h me likes... do you see these? is there a way |to create a |> default jar tvf (t being the important one here) and allowing |for indexing |> PER Cl, that would dramaticaly improve the speed of our superservers as |well |> as solve the above problem. |> |> but in any case until we know what it takes to open and close a |connection |> that would be the simplest. |> |> Go ahead and also try to get some number on "how much time to open one |> connection to file/10 connections/ lookup a class randomly in the 10 that |> are there"... if you get that in time for the rewrite it would |really make |> the work simple. |> |> marcf |> |> |> | |> |/Rickard |> | |> |-- |> |Rickard Öberg |> | |> | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
On 2001.11.27 13:34:31 -0500 marc fleury wrote: > > > |-Original Message- > |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > |Sent: Tuesday, November 27, 2001 12:57 PM > |To: marc fleury; Rickard Öberg > |Cc: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] Installer / Deployer Problem > | > | > |Hi > | > |I don't see the point here. The copying of the file is done when it get > |deployed > |and this is a rare occurance. When you now have to open/close the > > It really slows down large deployment. Copying 2 meg is just bad. Again > packaging madness. > > |connection > |to the URL then it can affect the overall performance which I think is > the > |worse > |that to copy the file. > |Also the file must inflated anyway and do I miss something ? > > it's a point, I don't care either way. But when do you need to "inflate" > and why? refresh my memory You may not need to inflate a jar, but rar, ear, and now sar have jars inside them. Unless someone can come up with a way to get classes out of them using a jar:jar:jar:http://.!/!/!/ url we need to unpack them. If network speed is the problem here, how can it possibly be faster after deployment to use a remote url rather than a local copy? Otherwise are you sure it is file copying that is taking the time? So far I agree with Andy. david jencks > > marcf > | > |Andy > | > |- Original Message - > |From: "marc fleury" <[EMAIL PROTECTED]> > |To: "Rickard Öberg" <[EMAIL PROTECTED]> > |Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; > |<[EMAIL PROTECTED]> > |Sent: Tuesday, November 27, 2001 9:13 AM > |Subject: RE: [JBoss-dev] Installer / Deployer Problem > | > | > |> |It's not fixed. Marc, do you remember when we were at J1 and talked > to > |> |your french friend that said something about it being a security hole > if > |> |it was fixed. Or something like that. > |> > |> Are you sure it is not fixed? as in you verified or as in you took > what > |this > |> guy said at face value (name is jc collet btw), I wouldn't trust > |everything > |> he said :) you know we were friends and all but... > |> > |> |I've been thinking about this problem though. Wouldn't it be possible > to > |> |make a custom URL handler that returns a connection wrapper that we > can > |> |drop under the covers. I.e. even if the URLClassLoader hangs onto it, > we > |> |can still close the file under the covers. I think that would make it > |> |work, and wouldn't be *that* intrusive in the code. > |> > |> sure, that is an idea and it would simplify the code a lot. The > |problem I > |> see is that I suspect they keep the connection opened for classloading > |> reasons, i.e. the VM asks for loading classes at random times. > Reopening > |the > |> connection seems slow (the security hole would be the capability > |to change > |> the jar we look up???). > |> > |> I guess the way this works is you would put a time out on the URL or > |> something, you need to make guesses as to when the vm will be > |done loading > |> from this puppy which is never in the case of JMX and SL CL > |architectures. > |> > |> A problem will be slow classloading in the JMX/SL base (it will > |affect 2.4 > |> and 3.0) as you will ask CL to look for classes in connections that > are > |> closed... h we are going to need smart CLs... at least with > |> indexing, yes... indexing of cl contents to allow for fast clusterwide > |> lookups h me likes... do you see these? is there a way > |to create a > |> default jar tvf (t being the important one here) and allowing > |for indexing > |> PER Cl, that would dramaticaly improve the speed of our superservers > as > |well > |> as solve the above problem. > |> > |> but in any case until we know what it takes to open and close a > |connection > |> that would be the simplest. > |> > |> Go ahead and also try to get some number on "how much time to open one > |> connection to file/10 connections/ lookup a class randomly in the 10 > that > |> are there"... if you get that in time for the rewrite it would > |really make > |> the work simple. > |> > |> marcf > |> > |> > |> | > |> |/Rickard > |> | > |> |-- > |> |Rickard Öberg > |> | > |> > | > > > ___ > 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
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > |It's not fixed. Marc, do you remember when we were at J1 and talked to > |your french friend that said something about it being a security hole if > |it was fixed. Or something like that. > > Are you sure it is not fixed? as in you verified or as in you took what this > guy said at face value (name is jc collet btw), I wouldn't trust everything > he said :) you know we were friends and all but... Haven't checked, but can't imagine that it's been fixed... still, would be nice with a solution that works on 1.3 too. > |I've been thinking about this problem though. Wouldn't it be possible to > |make a custom URL handler that returns a connection wrapper that we can > |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we > |can still close the file under the covers. I think that would make it > |work, and wouldn't be *that* intrusive in the code. > > sure, that is an idea and it would simplify the code a lot. The problem I > see is that I suspect they keep the connection opened for classloading > reasons, i.e. the VM asks for loading classes at random times. Reopening the > connection seems slow (the security hole would be the capability to change > the jar we look up???). That's irrelevant. It's ok that they hold on to the connection. It's not ok that there's no way to flush that cache. What our custom URL handler would buy us is that we can close the underlying connections explicitly as needed. If there's another call on the connection we would reopen it, but during the time it is closed we can replace the underlying JAR. > I guess the way this works is you would put a time out on the URL or > something, you need to make guesses as to when the vm will be done loading > from this puppy which is never in the case of JMX and SL CL architectures. Nope, just an explicit way of closing the connections and thus disregarding how the URLClassLoader connection cache does things. > A problem will be slow classloading in the JMX/SL base (it will affect 2.4 > and 3.0) as you will ask CL to look for classes in connections that are > closed... h we are going to need smart CLs... at least with > indexing, yes... indexing of cl contents to allow for fast clusterwide > lookups h me likes... do you see these? is there a way to create a > default jar tvf (t being the important one here) and allowing for indexing > PER Cl, that would dramaticaly improve the speed of our superservers as well > as solve the above problem. blah blah blah... nonsense. Not a problem, see above. The only thing that's important is that we can *close* them when *we* want to. Other than that its fine that the URLCL hangs onto open connections. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > following my own mantra of "communicate simple", go right ahead and create a > URLConnection that closes the connection after some time or every time, > maybe even every time is enough. See previous email. No guessing is needed. All the connection needs is that when we explicitly say "close() goddammit" it will close the underlying connection, so that we can remove the file that it was pointing to. > The discussion I have below only affects "loading" times when new classes > are deployed and we can always measure that and deal with it. So KISS the > URL. There would be no loading time problems. See previous descriptions. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Andreas Schaefer wrote: > I don't see the point here. The copying of the file is done when it get > deployed > and this is a rare occurance. When you now have to open/close the connection > to the URL then it can affect the overall performance which I think is the > worse > that to copy the file. The open/close only happens at deploy time, so no problem > Also the file must inflated anyway and do I miss something ? AFAIK the file would *not* have to be inflated. What are the reasons it must be inflated? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > not that I know, the original deployer was a piece of crap anyway, fix this > if you want. > > BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require > the 1.4 VM for proper behavior of the deployer I think it would greatly > simplify the design as we wouldn't need to copy the files over. It's not fixed. Marc, do you remember when we were at J1 and talked to your french friend that said something about it being a security hole if it was fixed. Or something like that. I've been thinking about this problem though. Wouldn't it be possible to make a custom URL handler that returns a connection wrapper that we can drop under the covers. I.e. even if the URLClassLoader hangs onto it, we can still close the file under the covers. I think that would make it work, and wouldn't be *that* intrusive in the code. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
On Tue, 27 Nov 2001, Rickard [ISO-8859-1] Öberg wrote: > Andreas Schaefer wrote: > > > I don't see the point here. The copying of the file is done when it get > > deployed > > and this is a rare occurance. When you now have to open/close the connection > > to the URL then it can affect the overall performance which I think is the > > worse > > that to copy the file. > > > The open/close only happens at deploy time, so no problem > > > > Also the file must inflated anyway and do I miss something ? > > > AFAIK the file would *not* have to be inflated. What are the reasons it > must be inflated? See David Jencks previous message in this thread where he said it is needed for ears, sars and any other JAR archive which has nested JAR archives in them which have to be used by a CL. So, inflating is needed unless you dump standard j2ee packaging (which, in fact, we are discussing in a different thread, well we would need it for backward compatibility but still) or come up with a way of (getting inside a jar)* to reach another jar without inflating them. ^^regex^^^ Packaging sucks... Anatoly. > > /Rickard > > > -- > Rickard Öberg > > > ___ > 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
RE: [JBoss-dev] Installer / Deployer Problem
|The open/close only happens at deploy time, so no problem You don't get it, the cl arch of 3.0 asks all the cls in case a class is not there, so well beyond the "deployment" if a class is not loaded during that deployment we might have problems... if everything is loaded at deployment time then we will be ok. marcf | | |> Also the file must inflated anyway and do I miss something ? | | |AFAIK the file would *not* have to be inflated. What are the reasons it |must be inflated? | |/Rickard | | |-- |Rickard Öberg | | |___ |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
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > |The open/close only happens at deploy time, so no problem > > You don't get it, the cl arch of 3.0 asks all the cls in case a class is not > there, so well beyond the "deployment" if a class is not loaded during that > deployment we might have problems... if everything is loaded at deployment > time then we will be ok. No, you don't get it. Please reread my previous posts. The connection will be open pretty much all of the time. The only time it will be closed is during deploy time. Hence, no problem. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
> |> You don't get it, the cl arch of 3.0 asks all the cls in case a |class is not |> there, so well beyond the "deployment" if a class is not loaded |during that |> deployment we might have problems... if everything is loaded at |deployment |> time then we will be ok. | | |No, you don't get it. Please reread my previous posts. The connection |will be open pretty much all of the time. The only time it will be |closed is during deploy time. Hence, no problem. ok one of us doesn't get it, if you are "open most of the time" how do you release the lock in the filesystem for anyone to overwrite the file ? I could be missing it :) marcf | |/R | |-- |Rickard Öberg | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > ok one of us doesn't get it, if you are "open most of the time" how do you > release the lock in the filesystem for anyone to overwrite the file ? I > could be missing it :) 1. URLCL wants to access "custom://somejar.jar" 2. It uses CustomURLHandler to get a connection to somejar.jar. This connection is put in cache and is never let go of. 3. The connection retrieved from CustomURLHandler is not a real connection, but merely a wrapper to a file connection. Similar to how a connection pool provides implementations of Connection that are only wrappers for real connections that can be managed by the pool. 4. Operations on the connection are passed on to the file connection. 5. When redeploy of a JAR is to be done, the wrapper is told to close its underlying connection 6. At this point there are no open connections to the JAR, so it can be replaced with a new file or removed. 7. At some point the connection wrapper is called, either by the old URLCL or a new one using the same connection. The file connection is then re-acquired, only now to the new file. See? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Rickard Oberg |Sent: Tuesday, November 27, 2001 5:24 PM |To: marc fleury |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |marc fleury wrote: | |> ok one of us doesn't get it, if you are "open most of the time" |how do you |> release the lock in the filesystem for anyone to overwrite the file ? I |> could be missing it :) | I understand what you proposed what I don't understand is the above, see below :) |1. URLCL wants to access "custom://somejar.jar" |2. It uses CustomURLHandler to get a connection to somejar.jar. This |connection is put in cache and is never let go of. |3. The connection retrieved from CustomURLHandler is not a real |connection, but merely a wrapper to a file connection. Similar to how a |connection pool provides implementations of Connection that are only |wrappers for real connections that can be managed by the pool. |4. Operations on the connection are passed on to the file connection. |5. When redeploy of a JAR is to be done, the wrapper is told to close |its underlying connection Question: can you overwrite the jar if the vm holds a open connection to it and thus a lock to it in windows (file in usage)? If no which is my assumption for this discussion then you don't know when ANT is going to replace that file from JBoss, or when the user wants to drag and drop, it is an asynchronous operation that happens without your knowledge (won't happen in this case) |6. At this point there are no open connections to the JAR, so it can be |replaced with a new file or removed. no see above, you don't know *when* someone is going to replace the file so you can't be "open most of the time". Do we agree here? |7. At some point the connection wrapper is called, either by the old |URLCL or a new one using the same connection. The file connection is |then re-acquired, only now to the new file. sure |See? almost, some googoo on my glasses still (or is it yours?) marcf | |/Rickard | | |-- |Rickard Öberg | | | |___ |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
Re: [JBoss-dev] Installer / Deployer Problem
On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: > marc fleury wrote: > > > ok one of us doesn't get it, if you are "open most of the time" how do > you > > release the lock in the filesystem for anyone to overwrite the file ? > I > > could be missing it :) > > > 1. URLCL wants to access "custom://somejar.jar" > 2. It uses CustomURLHandler to get a connection to somejar.jar. This > connection is put in cache and is never let go of. > 3. The connection retrieved from CustomURLHandler is not a real > connection, but merely a wrapper to a file connection. Similar to how a > connection pool provides implementations of Connection that are only > wrappers for real connections that can be managed by the pool. > 4. Operations on the connection are passed on to the file connection. > 5. When redeploy of a JAR is to be done, the wrapper is told to close > its underlying connection > 6. At this point there are no open connections to the JAR, so it can be > replaced with a new file or removed. > 7. At some point the connection wrapper is called, either by the old > URLCL or a new one using the same connection. The file connection is > then re-acquired, only now to the new file. > > See? So this requires an explicit undeploy of the old jar: it cannot work via an autodeployer watching for changed timestamps, because you have to undeploy the file first before you can change it. You sure this is better than copying? david jencks > > /Rickard > > > -- > Rickard Öberg > > > > ___ > 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
RE: [JBoss-dev] Installer / Deployer Problem
That is correct and my objection, however andreas pointed out that I was arguing an irrelevant point anyhow, I will forward his email marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, November 27, 2001 6:44 PM |To: Rickard Oberg |Cc: marc fleury; Andreas Schaefer; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: |> marc fleury wrote: |> |> > ok one of us doesn't get it, if you are "open most of the time" how do |> you |> > release the lock in the filesystem for anyone to overwrite the file ? |> I |> > could be missing it :) |> |> |> 1. URLCL wants to access "custom://somejar.jar" |> 2. It uses CustomURLHandler to get a connection to somejar.jar. This |> connection is put in cache and is never let go of. |> 3. The connection retrieved from CustomURLHandler is not a real |> connection, but merely a wrapper to a file connection. Similar to how a |> connection pool provides implementations of Connection that are only |> wrappers for real connections that can be managed by the pool. |> 4. Operations on the connection are passed on to the file connection. |> 5. When redeploy of a JAR is to be done, the wrapper is told to close |> its underlying connection |> 6. At this point there are no open connections to the JAR, so it can be |> replaced with a new file or removed. |> 7. At some point the connection wrapper is called, either by the old |> URLCL or a new one using the same connection. The file connection is |> then re-acquired, only now to the new file. |> |> See? | |So this requires an explicit undeploy of the old jar: it cannot work via an |autodeployer watching for changed timestamps, because you have to undeploy |the file first before you can change it. You sure this is better than |copying? | |david jencks |> |> /Rickard |> |> |> -- |> Rickard Öberg |> |> |> |> ___ |> 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 6:33 PM |To: marc fleury |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi Geeks | |We are maybe still discussing the wrong issue. I had a |look at the ZipFile and JarFile classes and they don't |allow you to open an archive inside an archive. true, more of that packaging madness, THE STANDARD PACKAGING OF J2EE IS A BROWN SMELLY CYLINDER. Anyway we got to eat it... |Therefore for most of the files except the JAR file |(EAR, WAR, RAR and SAR) we have to inflate the |archive anyhow. |Now with the old trick of various directories or numbering |the files we can go around the lock. that is correct. |When Rickard can implement a lock-free URLCL then |we don't have to create subclasses and can reuse the |files (right now I can grow and grow until the server is |bounced) and that would be valueable. yes and the trick will also enable to not have to renumber the jar and wars so we can have a more fine grained deployment with the actual names and you get to keep (andreas) your JSR77 requirements of keeping track. good call andy, our bad marcf | |Andy | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > I understand what you proposed what I don't understand is the above, see > below :) Ah, sorry, now I understand. We're talking about slightly different things. > Question: can you overwrite the jar if the vm holds a open connection to it > and thus a lock to it in windows (file in usage)? No. > If no which is my assumption for this discussion then you don't know when > ANT is going to replace that file from JBoss, or when the user wants to drag > and drop, it is an asynchronous operation that happens without your > knowledge (won't happen in this case) I was thinking about the same case as now, where there is one original copy (in /deploy) and one copy being actually used. The original copy would never be locked, but currently the copy being used is. *That* is what this solution would fix. You'd still need two copies. For the other case, you'd simply not use auto deployment. Introduce an Ant target that does "JBoss Deploy" and which does undeploy-copy-deploy directly to the server. Then you can work with the original file without problems. Personally I'd prefer this explicit way of doing deploy, since auto deployment seems a little funky right now (we get dual deployments quite often). > |6. At this point there are no open connections to the JAR, so it can be > |replaced with a new file or removed. > > no see above, you don't know *when* someone is going to replace the file so > you can't be "open most of the time". > > Do we agree here? We were talking about different files, that was the problem. > almost, some googoo on my glasses still (or is it yours?) As above, we talked about different things. We were both "right" :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
David Jencks wrote: > So this requires an explicit undeploy of the old jar: it cannot work via an > autodeployer watching for changed timestamps, because you have to undeploy > the file first before you can change it. Correct, I was mainly thinking about the locking of the copied file, which is a pain right now (it doesn't get cleaned up). > You sure this is better than > copying? Copying would still be used, but at least the copy can have the same name, and always be removed on undeploy. With explicit deployment (described in previous reply to Marc) there would be no locking. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
