Community
Participate
Working Groups
Hi Equinox Team, I'm improving ServletBridge to : 1. declare the BridgetServlet in the web.xml as an HTTP Filter. So no I can declare BridgetServlet in web.xml like this : --------------------------------------------------------- <filter id="bridge" > <filter-name>equinoxbridgeservlet</filter-name> <filter-class> org.eclipse.equinox.servletbridge.BridgeFilter </filter-class> </filter> <filter-mapping> <filter-name>equinoxbridgeservlet</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> --------------------------------------------------------- The benefit with filter declaration is that you can delegate to the FilterChain when NO ServletRegistration are founded for a path. So I can do that : ---------------------------------- if (chain != null) { // Delegate the HTTP request to the Web server container. chain.doFilter(req, resp); } ---------------------------------- instead doing that : ---------------------------------- // Send HTTP 404 Error. resp.sendError(HttpServletResponse.SC_NOT_FOUND, "ProxyServlet: " + req.getRequestURI()); //$NON-NLS-1$ ---------------------------------- So with Filter feature you can add some HTML, JSP, Servlet into the Bridget Web Application and it will work. By using BridgetServlet declaration you can NOT add your own resources (if you use /* pattern). With Filter declaration, 404 error is managed by the WEB server container. 2. Today, It's impossible to use directly bundles (ex : sample.http) from the workspace. You must create the bundle JAR and copy/paste to plugins folder (or use the ANT /scripts/webAppBuilder.xml"). I think it's not very easy. So I have improved FrameworkLauncher to give the capabilty to use bundles from the Eclipse workspace. To do that I'm using "-dev" options command of the org.eclipse.core.runtime.adaptor.EclipseStarter where you can set a dev.properties file (this is used with OSGi launch). So you can create a file "dev.properties" like this : ---------------------------------- sample.http=bin ---------------------------------- and use reference of your bundle in the "config.ini" like this : ---------------------------------- osgi.bundles=org.eclipse.equinox.common@2:start,... reference\:file\:WORKSPACE_PATH/sample.http@start ---------------------------------- where WORKSPACE_PATH is your workspace path. After no need to copy/paste your sample.http.jar in the plugins folder. You can use directly the sample.http project from your workspace. If you are interested with my work, tell me and I will send you patches. I had to modified : * org.eclipse.equinox.http.servlet * org.eclipse.equinox.http.servletbridge * org.eclipse.equinox.servletbridge Regards Angelo
Sure. Attach your patches and I'll take a look.
(In reply to comment #1) > Sure. Attach your patches and I'll take a look. Thank a lot Simon for your answer. Please let me a little time to clean my code and create a sample and I will send you patch + sample. Regards Angelo
Created attachment 177740 [details] Patch + samples + docs for using bundles from eclipse workspace + add custom resources (jsp...) in the bridge webapp by declaring BridgeServlet as Filter Simon I have attached a zip which contains : * bridge : Bridge Web app with the 2 new features (use bundles from outside WEB-INF/plugins (ex : bundles from your eclipse workspace) + declare Bridge as Filter to add custom JSP....to the webappp Bridge). This webapp is the Bridge webapp downloaded and modified with the 2 new JAR, web.xml wich use filter and index.jsp wich display sp_* commands. * NewServletBridge.odt and NewServletBridge.rtf are docs which explain the bridge sample with the 2 new features. * org.eclipse.equinox.http.servlet_patch.txt : patch for the project org.eclipse.equinox.http.servlet * org.eclipse.equinox.servletbridge_patch.txt : patch for the project org.eclipse.equinox.servletbridge Hope my work will please you. Regards Angelo
Created attachment 177810 [details] Patch + samples + docs for using bundles from eclipse workspace + add custom resources (jsp...) in the bridge webapp by declaring BridgeServlet as Filter Simon, I resent you a new patch+samples... where it fix problem with HttpServletRequestAdaptor#getPathInfo() + HttpServletRequestAdaptor.getContextPath() in Filter context. Indead in Filter case : * HttpServletRequestAdaptor#getPathInfo() is null. * HttpServletRequestAdaptor.getContextPath() which concat HttpServletRequestAdaptor.getContextPath() with HttpServletRequestAdaptor.getServletPath() is not correct in Filter context. I have founded this bug when I have tried to deploy OSGi Felix webconsole. Now it works well. But perhaps there are the same problems with another case?
(In reply to comment #4) > Created an attachment (id=177810) [details] > Patch + samples + docs for using bundles from eclipse workspace + add custom > resources (jsp...) in the bridge webapp by declaring BridgeServlet as Filter > > Simon, > > I resent you a new patch+samples... where it fix problem with > HttpServletRequestAdaptor#getPathInfo() + > HttpServletRequestAdaptor.getContextPath() in Filter context. Indead in Filter > case : > > * HttpServletRequestAdaptor#getPathInfo() is null. > * HttpServletRequestAdaptor.getContextPath() which concat > HttpServletRequestAdaptor.getContextPath() with > HttpServletRequestAdaptor.getServletPath() is not correct in Filter context. > > I have founded this bug when I have tried to deploy OSGi Felix webconsole. Now > it works well. But perhaps there are the same problems with another case? Hi Simon, I have bloggued about this patch at http://angelozerr.wordpress.com/2010/09/08/osgi-equinox-in-a-servlet-container-step4/. This post show you the benefit to use this patch. I have written several articles about "OSGi Equinox in a Servlet Container" where I explain step by step how use it with WTP. You can find plan at http://angelozerr.wordpress.com/about/osgi-equinox-in-a-servlet-container/ Regards Angelo
Created attachment 178420 [details] Bridge web App sample + Patch for ONLY dev-mode This zip contains : * org.eclipse.equinox.servletbridge_DevModePatch.txt : which is the patch to apply to the org.eclipse.equinox.servletbridge project to manage ONLY the dev-mode (use directly custom bundles (ex : sample.http) from teh workspace to avoid creating JAR in the /plugins folder). * bridwe WEB Application with the org.eclipse.equinox.servletbridge JAR + config.ini which use ${workspace_loc} wildcard in the config.ini.
Thanks Angelo, Looking at the "dev" patch and talking to a few others familiar with dev mode I want to avoid doing the work at runtime and instead look at doing something at deploy time similar to what PDE does when launching an Eclipse or Equinox instance. Overtime the way configuration information is handled and generated has changed and want to avoid increasing the surface area and coupling here. For example p2 generates the settings in config.ini in some of the newer server-side use-cases we're looking at. That's not to say that the development time experience of the servlet bridge cannot be improved however I think instead we might look at generating a development time WAR file with all the right settings again similar to what PDE does for launching. I know there was a summer-of-code project that was looking at this problem for RAP and I think that the general direction was good. Unfortuantely I don't think anyone has looked at what possibilities there are from incorporating their work into some general servletbridge tooling. Here's some relevant links: http://wiki.eclipse.org/RAP/Equinox_WAR_products http://eclipsesource.com/blogs/2010/04/11/rapequinox-war-products/ http://eclipsesource.com/blogs/2010/08/17/equinoxrap-war-deployment-an-end-to-the-pain/
Hi Simon, You mean that you wish have tool (Plug-In) to manage dev-mode with ServletBridge? (In reply to comment #7) > Thanks Angelo, > Looking at the "dev" patch and talking to a few others familiar with dev mode I > want to avoid doing the work at runtime and instead look at doing something at > deploy time similar to what PDE does when launching an Eclipse or Equinox > instance. > > Overtime the way configuration information is handled and generated has changed > and want to avoid increasing the surface area and coupling here. For example p2 > generates the settings in config.ini in some of the newer server-side use-cases > we're looking at. > > That's not to say that the development time experience of the servlet bridge > cannot be improved however I think instead we might look at generating a > development time WAR file with all the right settings again similar to what PDE > does for launching. I know there was a summer-of-code project that was looking > at this problem for RAP and I think that the general direction was good. > Unfortuantely I don't think anyone has looked at what possibilities there are > from incorporating their work into some general servletbridge tooling. > > Here's some relevant links: > http://wiki.eclipse.org/RAP/Equinox_WAR_products > http://eclipsesource.com/blogs/2010/04/11/rapequinox-war-products/ > http://eclipsesource.com/blogs/2010/08/17/equinoxrap-war-deployment-an-end-to-the-pain/
(In reply to comment #8) > Hi Simon, > You mean that you wish have tool (Plug-In) to manage dev-mode with > ServletBridge? Yes, I very mush wish we had a tool that somehow incorporated the web app deploy from WTP combined with the product launch from PDE. I haven't had a chance to look at what the RAP SOC guys have done, but from a short conversation with Jeff McAffer it sounded like they were moving in that direction. The SOC project was based on solving RAP problems however since they're just Equinox Servletbridge under the covers I'm hoping we can find a useful subset for our own use.
(In reply to comment #9) > (In reply to comment #8) > > Hi Simon, > > You mean that you wish have tool (Plug-In) to manage dev-mode with > > ServletBridge? > > Yes, I very mush wish we had a tool that somehow incorporated the web app > deploy from WTP combined with the product launch from PDE. I haven't had a > chance to look at what the RAP SOC guys have done, but from a short > conversation with Jeff McAffer it sounded like they were moving in that > direction. > > The SOC project was based on solving RAP problems however since they're just > Equinox Servletbridge under the covers I'm hoping we can find a useful subset > for our own use. Simon, If I find time I would like help you to create the ServletBridge Plug-In. I'm developping WTP Adaptor for Jetty7 and I'm studying how WTP publish works. Perhaps we could add a Publish Process with WTP for ServletBridge. At first we should clarify how ServletBridge can use product.
Traditionally in the Equinox world we assumed that server content was first developed in a "solo" configuration. That is, running Equinox with Jetty or some such embedded in it. This would use the normal PDE workflows of launch config, product etc. Once the function/content is the way you want, creating WARs and deploying in an app server was more of an integration/testing step since "it should just work". This has a great developer feel with very productive workflows. As more and more people are using server side function for a wider range of things, gaps have shown up. Being able to develop integrated with an app server from the beginning is interesting. We should try to do this without losing the productivity and simplicity of the solo scenario while enabling the bridged scenario in a seamless fashion. That is, IMHO it is critical that developers not have to do radically different things to run in the different forms. In the Equinox book and Toast example on eclipse.org we use .product files to capture what is to be run. The only difference between the solo and bridged/war cases are a) what equinox.server* feature you include in the product and b) the root dir used in the product export wizard. This is the level of seamlessness that developers should experience. Clearly there are still holes in this. For example, - developers need to export the product to create a WAR to run in an app server. It would be better to be able to launch in -dev mode with workspace bundles in-place. - Customizing the web.xml is hard. Currently we assume that the web.xml is just the standard one that comes with the servlet bridge. This works in many cases but clearly needs to be "tweakable". - Its still a pain that you have to manually go and start the server etc So what is really needed is a merge between the WTP infrastructure for launching/managing server instances and the PDE product launching capabilities. This way server developers retain their normal WTP workflows but get bundle capabilities and OSGi devs retain their bundle workflows but get server management. Chocolate and Peanut Butter...
(In reply to comment #11) > Traditionally in the Equinox world we assumed that server content was first > developed in a "solo" configuration. That is, running Equinox with Jetty or > some such embedded in it. This would use the normal PDE workflows of launch > config, product etc. Once the function/content is the way you want, creating > WARs and deploying in an app server was more of an integration/testing step > since "it should just work". This has a great developer feel with very > productive workflows. > > As more and more people are using server side function for a wider range of > things, gaps have shown up. Being able to develop integrated with an app server > from the beginning is interesting. We should try to do this without losing the > productivity and simplicity of the solo scenario while enabling the bridged > scenario in a seamless fashion. That is, IMHO it is critical that developers > not have to do radically different things to run in the different forms. > > In the Equinox book and Toast example on eclipse.org we use .product files to > capture what is to be run. The only difference between the solo and bridged/war > cases are a) what equinox.server* feature you include in the product and b) the > root dir used in the product export wizard. This is the level of seamlessness > that developers should experience. > > Clearly there are still holes in this. For example, > - developers need to export the product to create a WAR to run in an app > server. It would be better to be able to launch in -dev mode with workspace > bundles in-place. > > - Customizing the web.xml is hard. Currently we assume that the web.xml is just > the standard one that comes with the servlet bridge. This works in many cases > but clearly needs to be "tweakable". > > - Its still a pain that you have to manually go and start the server etc > > So what is really needed is a merge between the WTP infrastructure for > launching/managing server instances and the PDE product launching capabilities. > This way server developers retain their normal WTP workflows but get bundle > capabilities and OSGi devs retain their bundle workflows but get server > management. Chocolate and Peanut Butter... Thanks Jeff for your explanation. I understand the idea. I will try to study how we can create a Plug-In which manage your idea. Regards Angelo
Just a question Simon, Why ServletBridge use EclipeStarter#startup and NOT EclipeStarter#start? I tell you that because an Eclipse Application launch (created by launching a product) use EclipeStarter#start and EclipeStarter#startup. I woul like use in the Plug-In this launch generated but some parameters (like os..) are not used with your EclipeStarter#startup. Perhaps it's a ClassLoader problem (you are using ChildFirstURLClassLoader). Thanks for your help.
(In reply to comment #13) > Just a question Simon, Why ServletBridge use EclipeStarter#startup and NOT > EclipeStarter#start? I tell you that because an Eclipse Application launch > (created by launching a product) use EclipeStarter#start and > EclipeStarter#startup. I woul like use in the Plug-In this launch generated but > some parameters (like os..) are not used with your EclipeStarter#startup. > Perhaps it's a ClassLoader problem (you are using ChildFirstURLClassLoader). > Thanks for your help. Hi Angelo, The servletbridge is frequently used without the Application Service so having an application is not a requirement. Even when using the Application Admin service you don't have to use "start". "start" is generally used for applications that need control of the main/UI thread that will not return until the application is stopped. Five years ago we did play with start/stop and using -noShutdown but it didn't seem to buy us anything so we removed it.
(In reply to comment #14) > (In reply to comment #13) > > Just a question Simon, Why ServletBridge use EclipeStarter#startup and NOT > > EclipeStarter#start? I tell you that because an Eclipse Application launch > > (created by launching a product) use EclipeStarter#start and > > EclipeStarter#startup. I woul like use in the Plug-In this launch generated but > > some parameters (like os..) are not used with your EclipeStarter#startup. > > Perhaps it's a ClassLoader problem (you are using ChildFirstURLClassLoader). > > Thanks for your help. > > Hi Angelo, > > The servletbridge is frequently used without the Application Service so having > an application is not a requirement. Even when using the Application Admin > service you don't have to use "start". "start" is generally used for > applications that need control of the main/UI thread that will not return until > the application is stopped. Five years ago we did play with start/stop and > using -noShutdown but it didn't seem to buy us anything so we removed it. Hi Simon, Thank a lot for your information. I have start to develop a ServletBridge Plug-In to try some solution. I have studied OSGi PDE launch. When you execute an OSGi launch, it generate the OSGi command to call org.eclipse.equinox.launcher.Main with generated parameters. org.eclipse.equinox.launcher.Main call EclipseStart#start (and not EclipseStart#startup). My idea is to use this launch to get generated parameters (I have found a solution to do that : I don't execute the launch but just get the generated parameters). So the ideas is instead using product we could use OSGi launch. What do you think about that? I have studied PDE launch + WTP workflow : * I can detect when Server is started with WTP run/debug. * When server start is detected I can get an OSGi PDE launch from the workspace (for instance har-codeded with bridge.launch name) and I get generated parameters (ex : -application -data D:\_Projets\Personal\workspace_pde_wtp_servletbridge/../runtime-bridge.product -dev file:D:/_Projets/Personal/workspace_pde_wtp_servletbridge/.metadata/.plugins/org.eclipse.pde.core/bridge.product/dev.properties -os win32 -ws win32 -arch x86 -consoleLog) * After I generate a file in D:/tmp/servletbridge.txt which contains this generated parameters. * The BridgeServlet start and it read D:/tmp/servletbridge.txt to get generated parameters. But problem is that generated parameters is used with org.eclipse.equinox.launcher.Main and EclipseStart#startup. I must tranform it for EclipseStarter#starup. What do you think about this solution? Regards Angelo
Hi Simon, Forget my last comments. 'm studying "Equinox/RAP WAR deployment" at http://eclipsesource.com/blogs/2010/08/17/equinoxrap-war-deployment-an-end-to-the-pain/ where you can create a *.warproduct which works with ServletBridge. I have thought how we could use this great Plug-In to manage dev-mode with ServletBridge. I'm modifying to see if my idea can works : my idea is to generate a WEB-INF/configuration/config.ini in the WTP WEB DynamicProject project by using *.warproduct stored in this project. As soon as this product is modified it generate WEB-INF/configuration/config.ini with real path of bundles. I know the ideal solution is that generate this file not to the Eclipse project but it's my first step. If I can manage that, we need just *.warproduct (and not the whole /plugins/JAR bundles) and we will able to use JAR bundles from the Eclipse Home + Eclipse workspace in dev-mode. I tell you if I can do something. Regards Angelo
(In reply to comment #16) > Hi Simon, > > Forget my last comments. 'm studying "Equinox/RAP WAR deployment" at > http://eclipsesource.com/blogs/2010/08/17/equinoxrap-war-deployment-an-end-to-the-pain/ > where you can create a *.warproduct which works with ServletBridge. I have > thought how we could use this great Plug-In to manage dev-mode with > ServletBridge. I'm modifying to see if my idea can works : my idea is to > generate a WEB-INF/configuration/config.ini in the WTP WEB DynamicProject > project by using *.warproduct stored in this project. As soon as this product > is modified it generate WEB-INF/configuration/config.ini with real path of > bundles. I know the ideal solution is that generate this file not to the > Eclipse project but it's my first step. > > If I can manage that, we need just *.warproduct (and not the whole /plugins/JAR > bundles) and we will able to use JAR bundles from the Eclipse Home + Eclipse > workspace in dev-mode. I tell you if I can do something. > > Regards Angelo Please see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=327015 called " [WAR Product] Use WAR product for ServletBridge in dev-mode"
This bridge filter seems to be a really valuable improvement. Are there plans to incorporate that into Indigo?
Hi Lothar, No plans for doing this in Indigo.
(In reply to comment #19) > Hi Lothar, > No plans for doing this in Indigo. Can anyone explain to me why the Equinox Team is not interested in a useful enhancement like this? Making a Form based Login with RAP today is a major obstacle due to the fact that the bridge grabs all URI's and returns 404s for the html/jsp pages for the form login. And registering each individual resource with the extension point is a big annoyance. Should the Equinox Team not be happy if someone contributes something valuable as this, does all the work, provides patches and documentation. In my experience it should be not much work to get the IP statement for relatively small patches like this signed and the community could enjoy a IMHO major improvement. I know other Eclipse projects who are much more enthusiastic about getting contributions from outside their team and that are happy to incorporate them (in days or weeks - maybe after some redesign/refactoring) and that give the outside contributor the satisfaction that they accepted their contribution.
(In reply to comment #20) > (In reply to comment #19) > Can anyone explain to me why the Equinox Team is not interested in a useful > enhancement like this? > Lothar, of course we're interested in this enhancement and indeed Angelo has done a stellar job of putting this altogether. If you or Angelo are interested in bringing this work forward and maintaining it long term then we can talk and you can work in the incubator until it is ready for HEAD. The statement that this will not be in Indigo is a statement of timing on what I believe about my availability and other related committers on the equinox team and what we're working on in this release.
(In reply to comment #21) > > The statement that this will not be in Indigo is a statement of timing on what > I believe about my availability and other related committers on the equinox > team and what we're working on in this release. Given the fact that the bug was reported almost 6 months ago your statement about timing is somewhat strange, as you had IMHO ample time to consider and review it and I did not see any comment like "if you change this or that we can merge it to HEAD" that I see on many other bug reports in other projects. Yes, it's late in the Indigo train, but still far away from API freeze and thus not too late. From my impression reading this bug report Angelo seems eager and willing to provide a patch that would be accepted by you, so you need to communicate what's missing to accept the contribution and hopefully Angelo is able and willing to make these adjustments.
(In reply to comment #22) > (In reply to comment #21) > > > > The statement that this will not be in Indigo is a statement of timing on what > > I believe about my availability and other related committers on the equinox > > team and what we're working on in this release. > > Given the fact that the bug was reported almost 6 months ago your statement > about timing is somewhat strange, as you had IMHO ample time to consider and > review it and I did not see any comment like "if you change this or that we can > merge it to HEAD" that I see on many other bug reports in other projects. > Yes, it's late in the Indigo train, but still far away from API freeze and thus > not too late. > > From my impression reading this bug report Angelo seems eager and willing to > provide a patch that would be accepted by you, so you need to communicate > what's missing to accept the contribution and hopefully Angelo is able and > willing to make these adjustments. Hi Lothar, I'm happy that BridgeFilter please you. The main problem with this feature is that I have tested only with Tomcat but not with another server like WebSphere, WebLogic...I'm afraid that it will have some problems (I have every time bad surprises with WebSphere). For teh WAR product I had to modify FrameworkLauncher.java from ServletBridge to support "osgi.dev" property. But I have not answer about the WAR product patch. I will do a new patch (very simple) to support osgi.dev if WAR product accept my patch. Regards Angelo
Hi guys, two years ago you started to discuss these great Angelo's proposal. Any good news for rest of us (totally newcomer to Equinox serverside like me)? Will be something from it included in Equinox 3.8? Angello, I would like to ask you if you are still "in the picture" and willing to lobby for contious improvements in servletbridge again? I would like to help to "pump up" Equinox commiters concern to servletbridge again (2-3 years of sleeping is a really long). Thank you for your comments! Libor
(In reply to comment #24) > Hi guys, > two years ago you started to discuss these great Angelo's proposal. Any good > news for rest of us (totally newcomer to Equinox serverside like me)? Will be > something from it included in Equinox 3.8? > Hi Libor, > Angello, I would like to ask you if you are still "in the picture" and willing > to lobby for contious improvements in servletbridge again? I would like to help > to "pump up" Equinox commiters concern to servletbridge again (2-3 years of > sleeping is a really long). Many thank's for your proposition, but I have not time today to work on servletbridge, but don't hesitate to ask me, if you need some help with my work. Regards Angelo > > Thank you for your comments! > Libor
Is there any progress on this topic? The ability to use a BridgeFilter instead of a BridgeServlet would be an great enhancement.
(In reply to Heiko Hüter from comment #26) > Is there any progress on this topic? The ability to use a BridgeFilter > instead of a BridgeServlet would be an great enhancement. Not for mars. Will have to look more closely in Neon. Ray what are your thoughts?
(In reply to Thomas Watson from comment #27) > (In reply to Heiko Hüter from comment #26) > > Is there any progress on this topic? The ability to use a BridgeFilter > > instead of a BridgeServlet would be an great enhancement. > > Not for mars. Will have to look more closely in Neon. Ray what are your > thoughts? I've been thinking about this also. As you said, maybe for Neon.
(In reply to Raymond Auge from comment #28) > (In reply to Thomas Watson from comment #27) > > (In reply to Heiko Hüter from comment #26) > > > Is there any progress on this topic? The ability to use a BridgeFilter > > > instead of a BridgeServlet would be an great enhancement. > > > > Not for mars. Will have to look more closely in Neon. Ray what are your > > thoughts? > > I've been thinking about this also. As you said, maybe for Neon. Personally I think Neon is getting a little late to consider sweeping changes. But we can start a branch for oxygen if you like.
(In reply to Thomas Watson from comment #29) > (In reply to Raymond Auge from comment #28) > > (In reply to Thomas Watson from comment #27) > > > (In reply to Heiko Hüter from comment #26) > > > > Is there any progress on this topic? The ability to use a BridgeFilter > > > > instead of a BridgeServlet would be an great enhancement. > > > > > > Not for mars. Will have to look more closely in Neon. Ray what are your > > > thoughts? > > > > I've been thinking about this also. As you said, maybe for Neon. > > Personally I think Neon is getting a little late to consider sweeping > changes. But we can start a branch for oxygen if you like. I have not seen any activity on this. Unsetting milestone. If someone wants to start a branch on this and get work started then we can see what release to consider it for.
