Re: WebappLoader RFC
Its unclear now what you are trying to fix. Your first post stated you wanted to cut down on the "deploy" part (I pointed out the features we currently get that we'd loose with your approach; also that deploy is necessary to flush out the old version of the code in the JVM) and this last post I get the impression you want to cut down on the "build and copy JAR to WEB-INF/lib" step. I think I understand your situation as I have been there too but lets work through your points. Glen Marchesani wrote: The IDE features you mention sound cool which one is it? I don't want to get into any religious IDE war but Eclipse 3 with WTP 1.0. Any pointers/links to how you got that setup? See below for the outline. Unfortunately for the environment I am working in an IDE specific solution would be incomplete. We have a broad range of use cases (IDEs, OSes) as well as users where we need people to be able to checkout a project and be productive with it in a minimal amount of time. So doing IDE specific tweaks won't cut it. Our solution has worked extremely well with other app containers for example WebSphere, Resin and Jetty (all three that we use) come with support for something like this out of the box. I understand what you are saying, from your commercial standpoint you see the lack of this feature as causing a headache in supporting your customer base container diversity. My point from a technical standpoint your feature is already obsolete since at least one popular IDE already has a working solution which probably works for all containers the IDE supports (I've never tested on anything but TC) which includes the ones you list above. It is just matter of time before the other popular IDEs play catch up. The IDE we use really depends on the customer, project and environment. So could be any of the following ant+text editors, eclipse, WSDC, and/or netbeans... We can seemlessly switch between any of these using this technique by just adding the extendedClasspath line to the context and dropping a jar in server/lib/ all of which is handled by our ant scripts. I am all for continuing this tangential discussion of webapp development techniques but it really is tangential to the intent of the original post.. I'm not against your feature per say just the reasons you cite the need for it. Hot-code replace works fine in this scenario, I get the impression that you think it doesn't. As for your comments about future proofing. I am very confident that IDE's will from now on into the future will compile my .java files to some directory on the disk and that this option will be configurable and use some consistent default. So this solution is completely future-proof. In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's you need to manually kick off that process so it is adding a step to the edit-compile process. Are you really sure hot code replace work fine in this scenario, I thought the IDE had to be able to understand from its internal dependency graph that the compiled .class file is running on the JVM to be able to push an update to that JVM. The situation you present sounds like you have a web-app running under TC under the IDE and another standalone java project in the IDE. If you edit this standalone project sure you get a compiled .class file out of it, but why would the IDE then offer it up to the TC JVM ? For all intents and purposes the standalone project is disconnected from the running web-app. Since Eclipse WTP 1.0 you can create a J2EE Utility Project which can contribute a JAR into the WEB-INF/lib of J2EE Dynamic Web Project (create those 2 project types, goto the Project Properties page J2EE Module Dependancy of the DWP and tick the box). You can have both projects open and develop them at the same time with the IDE automatically propagating the new compiled code. This feature is still not perfect since TC will auto-redeploy when a JAR changes, the WTP feature would be better if it had a toggle to allow the J2EE Utility Project exported as individual .class files into the WEB-INF/classes tree this would allow Eclipse to attempt a Hot-code replace and thwart some unnecessary TC reloading. In any case if you alter the fields of a class which has one or more active instances Sun's JVM doesn't allow that class to be hot-code-replaced you get an error and Eclipse offers to continue/restart/shutdown the JVM. But there are many common cases where it works well, like adding/changing methods. Eclipse's solution is nearer my vision of the future and generic this makes it future proof to me. What you are proposing as a solution to this problem is a band aid, a dead end; that prohibits the next step to be taken by the IDE towards the ultimate seamless developer experience. Geez I should try marketing. Effectively adding a deploy step so you have edit-compile-deploy. Which is exactly what I am tryin
Re: WebappLoader RFC
The IDE features you mention sound cool which one is it? Any pointers/links to how you got that setup? Unfortunately for the environment I am working in an IDE specific solution would be incomplete. We have a broad range of use cases (IDEs, OSes) as well as users where we need people to be able to checkout a project and be productive with it in a minimal amount of time. So doing IDE specific tweaks won't cut it. Our solution has worked extremely well with other app containers for example WebSphere, Resin and Jetty (all three that we use) come with support for something like this out of the box. The IDE we use really depends on the customer, project and environment. So could be any of the following ant+text editors, eclipse, WSDC, and/or netbeans... We can seemlessly switch between any of these using this technique by just adding the extendedClasspath line to the context and dropping a jar in server/lib/ all of which is handled by our ant scripts. I am all for continuing this tangential discussion of webapp development techniques but it really is tangential to the intent of the original post.. Hot-code replace works fine in this scenario, I get the impression that you think it doesn't. As for your comments about future proofing. I am very confident that IDE's will from now on into the future will compile my .java files to some directory on the disk and that this option will be configurable and use some consistent default. So this solution is completely future-proof. In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's you need to manually kick off that process so it is adding a step to the edit-compile process. Effectively adding a deploy step so you have edit-compile-deploy. Which is exactly what I am trying to avoid albeit if it is properly contained in the IDE it is less of a headache. I enjoy the discussion of good practices (I don't think there is a one size fits all best practice here) for having a smooth development process so keep it coming ;-) On 6/13/06, Darryl Miles <[EMAIL PROTECTED]> wrote: Glen Marchesani wrote: > className="org.apache.catalina.loader.MyWebappLoader" > extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/" > /> > > > The reason for doing this is when developping a webapp that consists of > several smaller projects I wanted to be able to from within the ide > edit-compile-run skipping the deploy step. Skipping the deploy step > saves a > fair bit of tediousness. Which IDE are you using ? My IDE understands both the containers classpath and the web-app classpath fairly well. This means my IDE is able to resolve a dependency tree so its able to calculate the best possible approach to take. My IDE also supports hot-code replace (providing the JVM will allow it for a given situation, adding fields is a problem when one or more instances exist). My IDE also supports exporting of a JAR from another project into the WEB-INF/lib of the web-app project that is running under a debugging version of TC. If you are now bypassing all of the above, how do you cope with the problematic scenarios this now presents ? On the face of it; it may appear to skip the redeploy process but how can you be sure what you are debugging is the current version of code ? Then how in the future as IDE technology and tooling gets better can it make the best decision given that only the IDE has all the available knowledge about the edit-compile-run process. In short if one popular IDE is able to do so much (without patching features into TC) then it would appear to set the mark of what is possible. It questions if your approach would be a long term fix or just a patch over how you currently see the problem in the moment. Maybe your problem is more of configuration. Infact I think might be worth adding a section to the documentation outlining the features TC supports in the development cycle and when and how to set them up for use. Then another section on how setup (or tips) on working with a particular IDE (from the web-app developers PoV). Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappLoader RFC
Glen Marchesani wrote: extendedClasspath="C:/mycode/myproject/lib/*.jar;C:/mycode/myproject2/lib/*.jar;C:/mycode/myproject2/classes/" /> The reason for doing this is when developping a webapp that consists of several smaller projects I wanted to be able to from within the ide edit-compile-run skipping the deploy step. Skipping the deploy step saves a fair bit of tediousness. Which IDE are you using ? My IDE understands both the containers classpath and the web-app classpath fairly well. This means my IDE is able to resolve a dependency tree so its able to calculate the best possible approach to take. My IDE also supports hot-code replace (providing the JVM will allow it for a given situation, adding fields is a problem when one or more instances exist). My IDE also supports exporting of a JAR from another project into the WEB-INF/lib of the web-app project that is running under a debugging version of TC. If you are now bypassing all of the above, how do you cope with the problematic scenarios this now presents ? On the face of it; it may appear to skip the redeploy process but how can you be sure what you are debugging is the current version of code ? Then how in the future as IDE technology and tooling gets better can it make the best decision given that only the IDE has all the available knowledge about the edit-compile-run process. In short if one popular IDE is able to do so much (without patching features into TC) then it would appear to set the mark of what is possible. It questions if your approach would be a long term fix or just a patch over how you currently see the problem in the moment. Maybe your problem is more of configuration. Infact I think might be worth adding a section to the documentation outlining the features TC supports in the development cycle and when and how to set them up for use. Then another section on how setup (or tips) on working with a particular IDE (from the web-app developers PoV). Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebappLoader RFC
Hi All, I have created a custom WebappLoader that allows additional classpath settings. It's use is as follows.. The reason for doing this is when developping a webapp that consists of several smaller projects I wanted to be able to from within the ide edit-compile-run skipping the deploy step. Skipping the deploy step saves a fair bit of tediousness. My thiking is that this would be useful to others and hence this post. Is there interest in this being an included feature on the default WebappLoader? Or as an add on WebappLoader? The number of lines/complexity of code this adds is minimal a gettter/setter for extendedClasspath and a loop at the bottom of the setRepositories() method to add the entries in the extendedClasspath to the proper places.. Also I am willing to clean up/refactoring the WebappLoader code if someone is willing to be the committer and let me know what I need to provide.. I am well versed in Classloader intracacies ;-) As for cleanup there is code like this throughout WebappLoader and WebappClassloader String results[] = new String[repositories.length + 1]; for (int i = 0; i < repositories.length; i++) results[i] = repositories[i]; results[repositories.length] = repository; repositories = results; thanks, Glen