Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] equinox http service

As I'm not too familiar with the definitions of all the runtime qualifiers, I'm wondering if we need more than just:

Bundle-RequiredExecutionEnvironment: JavaSE-1.6

- Ray


On Mon, Mar 24, 2014 at 12:10 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:
I agree on all points. 

For now I'm going to assume 3.0 & Java 6 and once I get that, I'll then proceed to verifying 3.1 & Java 7.

- Ray


On Mon, Mar 24, 2014 at 10:45 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

I think we should target Java 6 if it makes life more simple.  Our jetty backed solution on Jetty 8 already requires Java 6 and I have been told that Servlet 3.0 requires Java 6 as a minimum.  Moving forward we need to figure out if we can pull off a base http.servlet bundle that supports 3.1 and 3.0 servlet.  I think Servlet 3.1 may require Java 7, but in the past we have been able to have http.servlet support much older Java versions.

BTW, I would like us to consider having the http.servlet bundle be as forwards compatible as possible.  I think this is important for cases where a war is delivered with http.servlet bundle embedded.  Otherwise the bridge style WAR will become incompatible on later servers that implement the very latest servlet spec.

Currently we attempt to do this by using proxies for provider types like the ServletContext which then delegate to the hosting container's provider type implementations.

Tom



Inactive hide details for Raymond Auge ---03/23/2014 10:05:16 PM---With respect to updating org.eclipse.equinox.http.servlet toRaymond Auge ---03/23/2014 10:05:16 PM---With respect to updating org.eclipse.equinox.http.servlet to RFC 189. Are we increasing:



From: Raymond Auge <raymond.auge@xxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date: 03/23/2014 10:05 PM

Subject: Re: [equinox-dev] equinox http service
Sent by: equinox-dev-bounces@xxxxxxxxxxx




With respect to updating org.eclipse.equinox.http.servlet to RFC 189.

Are we increasing:
* org.eclipse.jdt.core.compiler.compliance
* org.eclipse.jdt.core.compiler.source
* Bundle-RequiredExecutionEnvironment
* org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType

Basically, what's the baseline Java version we're limited to increasing this too.

- Ray


On Sun, Mar 23, 2014 at 1:13 AM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:
    Hello Thomas, et al.

    I managed to use the org.eclipse.equinox.http.servlet without modification as the Http Service in Liferay without using the equinox bridge or doing any nasty hackery. It was actually trivially simple.

    This is a good stepping stone to start hacking in the new http-service spec on top of this knowing that we're starting from an working common denominator.

    Probably tomorrow I'll create a github fork with a branch for this work.

    Sincerely,
    - Ray


    On Fri, Mar 21, 2014 at 5:45 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:
      Nvm... Old checkout.

      On Mar 21, 2014 5:26 PM, "Raymond Auge" <raymond.auge@xxxxxxxxxxx> wrote:

        Hey all,

        I'd like to confirm my understanding that rt.equinox.bundles/org.eclipse.equinox.http is indeed the (and only) http-service implementation in equinox.

        Thx

        --
        Raymond Augé (@rotty3000)
        Senior Software Architect
        Liferay, Inc. (@Liferay)




    --
    Raymond Augé (@rotty3000)
    Senior Software Architect
    Liferay, Inc. (@Liferay)




--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev




--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)




--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)

GIF image


Back to the top