[Lift] Re: Supporting Jetty 7 Continuations
I was hoping to generically support Servlet 3.0 continuations (which should work for Jetty 7 and Glassfish). Please open a ticket for it. On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett timo...@getintheloop.euwrote: Guys, I just wanted to rename this thread and raise this for proper discussion. API's between J6.x and J7.x appear to be the same, its mainly the package names and structure that have changed. Is it feasible to add a match statement to replace the current val assignments that have essentially hardcoded dependency on J6.x? There's some great stuff in Jetty 7 that would really help me (and lots of others) out Cheers, Tim On Oct 5, 5:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Id say that it would be easier to use a match statement as part of the val assignment... The current code is just using reflection, so factoring into a case statement shouldnt be too tough right? Thoughts? Cheers, Tim On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote: On 05/10/09 5:29 PM, Timothy Perrett wrote: So I just wrote a Jetty 6 wrapper - getting the packaging working was not ideal and not as flexible as Jetty 7 jetty-runner. Yes, just took a look at jetty-runner. Feature wise, it's blows away the older mechanism man! Any thoughts in and around altering the lift code to adjust the package based on jetty version? I can think of two options basically: 1. Move to jetty 7 and be done with it. 2. Allowing user option (via -Djetty.version) during archetype:generate. jetty.version can be an overridable archetype property that defaults to (say 6) but user can do -Djetty.version=7. Depending on the jetty version, the *.scala, *.xml etc. can be filtered to make the right kind of adjustment during archetype creation. Cheers, Indrajit Cheers, Tim On Oct 5, 9:07 am, Timothy Perretttimo...@getintheloop.eu wrote: Indrajit, Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6 would be this line: val cc = Class.forName (org.mortbay.util.ajax.ContinuationSupport) It would be trivial to add a match or whatever that determined the correct type to use... The question is, why haven't we done this already? I suspect its just a time / capacity issue but wanted to check. I know I could write a jetty 6 wrapper, but that is my fallback position as something more OOTB would be preferable. Cheers, Tim On Oct 5, 8:29 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Tim, Interestingly, we are trying out something similar in a project here and this is absolutely cool stuff. In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as 'desktop application'. That you can have 'double-click' friendly application helps :-) Few notes: 1. Embedding Jetty server is super easy with org.mortbay.jetty.Server. Something that we have in Lift - well almost ;-) The RunWebApp in the archetypes are primitive use case of such. [1] 2. Jetty Runner is available only on Jetty 7.x series I think (not certain). But yes, looks good either way. 3. Jetty has this clean and nice way of having web-app specific jetty config tucked inside the application (war or expanded) within WEB-INF/jetty-web.xml which is basically an XmlConfiguration instance applied on the specific WebApplicationContext instead of the Container Context. [2] 4. An archetype that does self deploying is something that I have on my todo-list. Do you think this would make sense? 5. Maven assembly plugin would do. I haven't tried this myself, but Maven shade plugin looks something close. [3] [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml [3]http://maven.apache.org/plugins/maven-shade-plugin/ Cheers, Indrajit NB: Looks like quite a few night owl here! On 05/10/09 4:11 AM, Timothy Perrett wrote: Viktor, you and I should not be up this late on a sunday! ;-) You have to see this:http://blogs.webtide.com/janb/entry/ jetty_runner Im going to hash this together as a maven assembly; if it works, then i'll write a blog and stuff it on the wiki... this could really make self deploying apps very nice indeed. I'll check with DavidB, but im fairly sure it would also be trivial to make a little maven plugin that builds a single JAR output... Cheers, Tim On Oct 4, 11:10 pm, Viktor Klangviktor.kl...@gmail.comwrote: Thanks for the linky, mate! Was a good read :) On Sun, Oct 4, 2009 at 11:45 PM, Timothy Perretttimo...@getintheloop.euwrote: Just some more fuel for this debate: http://technically.us/code/x/to-jettison-geronimo/ Cheers, Tim On Oct 4, 8:46 pm, Timothy Perretttimo...@getintheloop.eu wrote: Guys, Of
[Lift] Re: Supporting Jetty 7 Continuations
I know that has been the plan - but I cant help but think that Servlet 3.0 is still a long way off standardisation? What do you think? Cheers, Tim On 7 Oct 2009, at 16:53, David Pollak wrote: I was hoping to generically support Servlet 3.0 continuations (which should work for Jetty 7 and Glassfish). Please open a ticket for it. On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to rename this thread and raise this for proper discussion. API's between J6.x and J7.x appear to be the same, its mainly the package names and structure that have changed. Is it feasible to add a match statement to replace the current val assignments that have essentially hardcoded dependency on J6.x? There's some great stuff in Jetty 7 that would really help me (and lots of others) out Cheers, Tim On Oct 5, 5:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Id say that it would be easier to use a match statement as part of the val assignment... The current code is just using reflection, so factoring into a case statement shouldnt be too tough right? Thoughts? Cheers, Tim On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote: On 05/10/09 5:29 PM, Timothy Perrett wrote: So I just wrote a Jetty 6 wrapper - getting the packaging working was not ideal and not as flexible as Jetty 7 jetty-runner. Yes, just took a look at jetty-runner. Feature wise, it's blows away the older mechanism man! Any thoughts in and around altering the lift code to adjust the package based on jetty version? I can think of two options basically: 1. Move to jetty 7 and be done with it. 2. Allowing user option (via -Djetty.version) during archetype:generate. jetty.version can be an overridable archetype property that defaults to (say 6) but user can do -Djetty.version=7. Depending on the jetty version, the *.scala, *.xml etc. can be filtered to make the right kind of adjustment during archetype creation. Cheers, Indrajit Cheers, Tim On Oct 5, 9:07 am, Timothy Perretttimo...@getintheloop.eu wrote: Indrajit, Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6 would be this line: val cc = Class.forName (org.mortbay.util.ajax.ContinuationSupport) It would be trivial to add a match or whatever that determined the correct type to use... The question is, why haven't we done this already? I suspect its just a time / capacity issue but wanted to check. I know I could write a jetty 6 wrapper, but that is my fallback position as something more OOTB would be preferable. Cheers, Tim On Oct 5, 8:29 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Tim, Interestingly, we are trying out something similar in a project here and this is absolutely cool stuff. In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as 'desktop application'. That you can have 'double-click' friendly application helps :-) Few notes: 1. Embedding Jetty server is super easy with org.mortbay.jetty.Server. Something that we have in Lift - well almost ;-) The RunWebApp in the archetypes are primitive use case of such. [1] 2. Jetty Runner is available only on Jetty 7.x series I think (not certain). But yes, looks good either way. 3. Jetty has this clean and nice way of having web-app specific jetty config tucked inside the application (war or expanded) within WEB-INF/jetty-web.xml which is basically an XmlConfiguration instance applied on the specific WebApplicationContext instead of the Container Context. [2] 4. An archetype that does self deploying is something that I have on my todo-list. Do you think this would make sense? 5. Maven assembly plugin would do. I haven't tried this myself, but Maven shade plugin looks something close. [3] [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml [3]http://maven.apache.org/plugins/maven-shade-plugin/ Cheers, Indrajit NB: Looks like quite a few night owl here! On 05/10/09 4:11 AM, Timothy Perrett wrote: Viktor, you and I should not be up this late on a sunday! ;-) You have to see this:http://blogs.webtide.com/janb/entry/ jetty_runner Im going to hash this together as a maven assembly; if it works, then i'll write a blog and stuff it on the wiki... this could really make self deploying apps very nice indeed. I'll check with DavidB, but im fairly sure it would also be trivial to make a little maven plugin that builds a single JAR output... Cheers, Tim On Oct 4, 11:10 pm, Viktor Klangviktor.kl...@gmail.com wrote: Thanks for the linky, mate! Was a good read :) On Sun, Oct 4, 2009 at
[Lift] Re: Supporting Jetty 7 Continuations
On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett timo...@getintheloop.euwrote: I know that has been the plan - but I cant help but think that Servlet 3.0 is still a long way off standardisation? It's been 3 months away from being a standard for almost 2 years. ;-) What do you think? Cheers, Tim On 7 Oct 2009, at 16:53, David Pollak wrote: I was hoping to generically support Servlet 3.0 continuations (which should work for Jetty 7 and Glassfish). Please open a ticket for it. On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to rename this thread and raise this for proper discussion. API's between J6.x and J7.x appear to be the same, its mainly the package names and structure that have changed. Is it feasible to add a match statement to replace the current val assignments that have essentially hardcoded dependency on J6.x? There's some great stuff in Jetty 7 that would really help me (and lots of others) out Cheers, Tim On Oct 5, 5:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Id say that it would be easier to use a match statement as part of the val assignment... The current code is just using reflection, so factoring into a case statement shouldnt be too tough right? Thoughts? Cheers, Tim On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote: On 05/10/09 5:29 PM, Timothy Perrett wrote: So I just wrote a Jetty 6 wrapper - getting the packaging working was not ideal and not as flexible as Jetty 7 jetty-runner. Yes, just took a look at jetty-runner. Feature wise, it's blows away the older mechanism man! Any thoughts in and around altering the lift code to adjust the package based on jetty version? I can think of two options basically: 1. Move to jetty 7 and be done with it. 2. Allowing user option (via -Djetty.version) during archetype:generate. jetty.version can be an overridable archetype property that defaults to (say 6) but user can do -Djetty.version=7. Depending on the jetty version, the *.scala, *.xml etc. can be filtered to make the right kind of adjustment during archetype creation. Cheers, Indrajit Cheers, Tim On Oct 5, 9:07 am, Timothy Perretttimo...@getintheloop.eu wrote: Indrajit, Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6 would be this line: val cc = Class.forName (org.mortbay.util.ajax.ContinuationSupport) It would be trivial to add a match or whatever that determined the correct type to use... The question is, why haven't we done this already? I suspect its just a time / capacity issue but wanted to check. I know I could write a jetty 6 wrapper, but that is my fallback position as something more OOTB would be preferable. Cheers, Tim On Oct 5, 8:29 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Tim, Interestingly, we are trying out something similar in a project here and this is absolutely cool stuff. In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as 'desktop application'. That you can have 'double-click' friendly application helps :-) Few notes: 1. Embedding Jetty server is super easy with org.mortbay.jetty.Server. Something that we have in Lift - well almost ;-) The RunWebApp in the archetypes are primitive use case of such. [1] 2. Jetty Runner is available only on Jetty 7.x series I think (not certain). But yes, looks good either way. 3. Jetty has this clean and nice way of having web-app specific jetty config tucked inside the application (war or expanded) within WEB-INF/jetty-web.xml which is basically an XmlConfiguration instance applied on the specific WebApplicationContext instead of the Container Context. [2] 4. An archetype that does self deploying is something that I have on my todo-list. Do you think this would make sense? 5. Maven assembly plugin would do. I haven't tried this myself, but Maven shade plugin looks something close. [3] [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml [3]http://maven.apache.org/plugins/maven-shade-plugin/ Cheers, Indrajit NB: Looks like quite a few night owl here! On 05/10/09 4:11 AM, Timothy Perrett wrote: Viktor, you and I should not be up this late on a sunday! ;-) You have to see this:http://blogs.webtide.com/janb/entry/ jetty_runner Im going to hash this together as a maven assembly; if it works, then i'll write a blog and stuff it on the wiki... this could really make self deploying apps very nice indeed. I'll check with DavidB, but im
[Lift] Re: Supporting Jetty 7 Continuations
My point exactly! To that end, why dont we just add a small matching statement or switch that allows using Jetty 7 - only the package structure has changed not the continuation API itself so it should be fairly trivial. The jetty- runner stuff would really get me out of jetty-wrapper-hell that im in right now and would mean we could create an archetype that allows Lift apps to be deployable as a standalone JAR with jetty built in... would that not be über cool? Cheers, Tim On 7 Oct 2009, at 17:30, David Pollak wrote: On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett timo...@getintheloop.eu wrote: I know that has been the plan - but I cant help but think that Servlet 3.0 is still a long way off standardisation? It's been 3 months away from being a standard for almost 2 years. ;-) What do you think? Cheers, Tim On 7 Oct 2009, at 16:53, David Pollak wrote: I was hoping to generically support Servlet 3.0 continuations (which should work for Jetty 7 and Glassfish). Please open a ticket for it. On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to rename this thread and raise this for proper discussion. API's between J6.x and J7.x appear to be the same, its mainly the package names and structure that have changed. Is it feasible to add a match statement to replace the current val assignments that have essentially hardcoded dependency on J6.x? There's some great stuff in Jetty 7 that would really help me (and lots of others) out Cheers, Tim On Oct 5, 5:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Id say that it would be easier to use a match statement as part of the val assignment... The current code is just using reflection, so factoring into a case statement shouldnt be too tough right? Thoughts? Cheers, Tim On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote: On 05/10/09 5:29 PM, Timothy Perrett wrote: So I just wrote a Jetty 6 wrapper - getting the packaging working was not ideal and not as flexible as Jetty 7 jetty-runner. Yes, just took a look at jetty-runner. Feature wise, it's blows away the older mechanism man! Any thoughts in and around altering the lift code to adjust the package based on jetty version? I can think of two options basically: 1. Move to jetty 7 and be done with it. 2. Allowing user option (via -Djetty.version) during archetype:generate. jetty.version can be an overridable archetype property that defaults to (say 6) but user can do -Djetty.version=7. Depending on the jetty version, the *.scala, *.xml etc. can be filtered to make the right kind of adjustment during archetype creation. Cheers, Indrajit Cheers, Tim On Oct 5, 9:07 am, Timothy Perretttimo...@getintheloop.eu wrote: Indrajit, Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6 would be this line: val cc = Class.forName (org.mortbay.util.ajax.ContinuationSupport) It would be trivial to add a match or whatever that determined the correct type to use... The question is, why haven't we done this already? I suspect its just a time / capacity issue but wanted to check. I know I could write a jetty 6 wrapper, but that is my fallback position as something more OOTB would be preferable. Cheers, Tim On Oct 5, 8:29 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Tim, Interestingly, we are trying out something similar in a project here and this is absolutely cool stuff. In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as 'desktop application'. That you can have 'double-click' friendly application helps :-) Few notes: 1. Embedding Jetty server is super easy with org.mortbay.jetty.Server. Something that we have in Lift - well almost ;-) The RunWebApp in the archetypes are primitive use case of such. [1] 2. Jetty Runner is available only on Jetty 7.x series I think (not certain). But yes, looks good either way. 3. Jetty has this clean and nice way of having web-app specific jetty config tucked inside the application (war or expanded) within WEB-INF/jetty-web.xml which is basically an XmlConfiguration instance applied on the specific WebApplicationContext instead of the Container Context. [2] 4. An archetype that does self deploying is something that I have on my todo-list. Do you think this would make sense? 5. Maven assembly plugin would do. I haven't tried this myself, but Maven shade plugin looks something close. [3] [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
[Lift] Re: Supporting Jetty 7 Continuations
Looks like you need to open a ticket for that :P On Oct 8, 3:50 am, Timothy Perrett timo...@getintheloop.eu wrote: My point exactly! To that end, why dont we just add a small matching statement or switch that allows using Jetty 7 - only the package structure has changed not the continuation API itself so it should be fairly trivial. The jetty- runner stuff would really get me out of jetty-wrapper-hell that im in right now and would mean we could create an archetype that allows Lift apps to be deployable as a standalone JAR with jetty built in... would that not be über cool? Cheers, Tim On 7 Oct 2009, at 17:30, David Pollak wrote: On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett timo...@getintheloop.eu wrote: I know that has been the plan - but I cant help but think that Servlet 3.0 is still a long way off standardisation? It's been 3 months away from being a standard for almost 2 years. ;-) What do you think? Cheers, Tim On 7 Oct 2009, at 16:53, David Pollak wrote: I was hoping to generically support Servlet 3.0 continuations (which should work for Jetty 7 and Glassfish). Please open a ticket for it. On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to rename this thread and raise this for proper discussion. API's between J6.x and J7.x appear to be the same, its mainly the package names and structure that have changed. Is it feasible to add a match statement to replace the current val assignments that have essentially hardcoded dependency on J6.x? There's some great stuff in Jetty 7 that would really help me (and lots of others) out Cheers, Tim On Oct 5, 5:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Id say that it would be easier to use a match statement as part of the val assignment... The current code is just using reflection, so factoring into a case statement shouldnt be too tough right? Thoughts? Cheers, Tim On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote: On 05/10/09 5:29 PM, Timothy Perrett wrote: So I just wrote a Jetty 6 wrapper - getting the packaging working was not ideal and not as flexible as Jetty 7 jetty-runner. Yes, just took a look at jetty-runner. Feature wise, it's blows away the older mechanism man! Any thoughts in and around altering the lift code to adjust the package based on jetty version? I can think of two options basically: 1. Move to jetty 7 and be done with it. 2. Allowing user option (via -Djetty.version) during archetype:generate. jetty.version can be an overridable archetype property that defaults to (say 6) but user can do -Djetty.version=7. Depending on the jetty version, the *.scala, *.xml etc. can be filtered to make the right kind of adjustment during archetype creation. Cheers, Indrajit Cheers, Tim On Oct 5, 9:07 am, Timothy Perretttimo...@getintheloop.eu wrote: Indrajit, Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6 would be this line: val cc = Class.forName (org.mortbay.util.ajax.ContinuationSupport) It would be trivial to add a match or whatever that determined the correct type to use... The question is, why haven't we done this already? I suspect its just a time / capacity issue but wanted to check. I know I could write a jetty 6 wrapper, but that is my fallback position as something more OOTB would be preferable. Cheers, Tim On Oct 5, 8:29 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Tim, Interestingly, we are trying out something similar in a project here and this is absolutely cool stuff. In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as 'desktop application'. That you can have 'double-click' friendly application helps :-) Few notes: 1. Embedding Jetty server is super easy with org.mortbay.jetty.Server. Something that we have in Lift - well almost ;-) The RunWebApp in the archetypes are primitive use case of such. [1] 2. Jetty Runner is available only on Jetty 7.x series I think (not certain). But yes, looks good either way. 3. Jetty has this clean and nice way of having web-app specific jetty config tucked inside the application (war or expanded) within WEB-INF/jetty-web.xml which is basically an XmlConfiguration instance applied on the specific WebApplicationContext instead of the Container Context. [2] 4. An archetype that does self deploying is something that I have on my todo-list. Do you think this would make sense? 5. Maven assembly plugin would do. I haven't tried this myself, but Maven shade plugin looks
