Re: [equinox-dev] Eclipse Oxygen(4.7) M5 available
Answering myself: - In Oxygen p2 publisher will not parse the Require-Capability/Provide-Capability manifest headers. - The support for generic reqs/caps is limited to p2.inf files that need to be maintained manually. - The p2 internal representation of a capability is limited to the (namespace, name, version) triplet. - Therefore it is not possible to express the full information contained in the bundle manifest via p2.inf or generally in p2. The users need to select one most meaningful capability attribute and map that to the p2 model. After a lot of digging through the p2 code it seems that: - The internal representation of a requirement can already match against capabilities using an LDAP filter. - Therefore there is hope for a generic solution if the internal representation of a capability is extended to support an attribute map. Regards, Todor On Fri, Jan 27, 2017 at 6:41 PM, Todor Boev <rinsv...@gmail.com> wrote: > I noticed that in Oxygen M1, p2 was extended to support some generic > capabilities/requirements: > https://www.eclipse.org/eclipse/news/4.7/M1/#Equinox > > I have two questions: > - Does this mean p2 now has a mechanism to support the general OSGi > capability/requirement model? (i.e. where a capability is a set of > properties and a requirement is an LDAP filter) > - Why are only "osgi.service" capabilities added? Should't there be also > "osgi.implementation" capabilities? > > Regards > Todor > > On Fri, Jan 27, 2017 at 2:46 PM, Sravan K Lakkimsetti < > sravankum...@in.ibm.com> wrote: > >> Hi, >> >> We are pleased to announce that Oxygen M5 is available for download and >> updates. >> >> Eclipse downloads: >> http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M5 >> -201701261030/ >> >> New and Noteworthy: >> http://www.eclipse.org/eclipse/news/4.7/M5/ >> >> Update existing (non-production) installs: >> http://download.eclipse.org/eclipse/updates/4.7milestones/ >> >> Specific repository good for building against: >> http://download.eclipse.org/eclipse/updates/4.7milestones/S- >> 4.7M5-201701261030/ >> >> Equinox specific downloads: >> http://download.eclipse.org/equinox/drops/S-OxygenM5-201701261030/ >> >> Thank you to everyone who made this checkpoint possible. >> >> >> Thanks and Regards, >> Sravan >> >> Sravan Kumar Lakkimsetti >> IBM India Pvt Ltd, >> Embassy Golf Links Business Park, D Block, >> Off Indiranagar-Kormangla Inner Ring Road, >> Bangalore - 560071, India >> Phone: 91-80-41776858 >> >> ___ >> equinox-dev mailing list >> equinox-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> > > ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] How to use JSPs with HTTP Whiteboard?
Hello,
I am trying to use org.eclipse.equinox.jsp.jasper.JspServlet
from org.eclipse.equinox.jsp.jasper together with the HTTP Whiteboard.
Currently I am attempting to register a JspServlet instance with
Declarative Services like this:
@Component(
service = Servlet.class,
property = {
HTTP_WHITEBOARD_CONTEXT_SELECT + "=(" +
HTTP_WHITEBOARD_CONTEXT_NAME + "=greeter)",
HTTP_WHITEBOARD_SERVLET_PATTERN + "=/",
})
public class GreeterForm extends JspServlet {
private GreeterManager greeters;
public GreeterForm() {
super(FrameworkUtil.getBundle(GreeterForm.class), "/");
}
@Reference
public void setGreeterManager(GreeterManager greeters) {
this.greeters = greeters;
}
@Override
public void init(ServletConfig config) throws ServletException {
config.getServletContext().setAttribute(InstanceManager.class.getName(),
new SimpleInstanceManager());
super.init(config);
}
@Override
public void service(ServletRequest req, ServletResponse res) throws
IOException, ServletException {
req.setAttribute("greeters", greeters);
super.service(req, res);
}
}
My bundle requires both a bundle that provides the JSTL API and one that
provides the JSTL implementation.
There is an "/index.jsp" in the bundle root that uses some tags from JSTL.
The goal is to use OSGi services in a JSP. However the JspServlet crashes
in a variety of ways, which I gave up trying to fix.
Is there a standard way to combine HTTP Whiteboard and JSPs?
Moreover does the JSP support require other parts of Tomcat? Notice for
example the init() method.
Thanks in advance,
Todor
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Looking for active p2 developers for review
Hello, I have several bug fixes to p2 that are pending for review for about a year now. Recently a I took the trouble to update the patches and resubmit reviews to Gerrit. Can someone point me to equinox developers who are currently active in the p2 project, so that I can add them as reviewers? I'd hate to have to maintain forked versions of several p2 bundles for yet another Eclipse release. https://bugs.eclipse.org/bugs/show_bug.cgi?id=486279 - Bundle uninstalls can silently leave behind the old entry in bundles.info https://bugs.eclipse.org/bugs/show_bug.cgi?id=490896 - Director application reports failure on WARNING or INFO status Regards, Todor Boev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Eclipse Oxygen(4.7) M5 available
I noticed that in Oxygen M1, p2 was extended to support some generic capabilities/requirements: https://www.eclipse.org/eclipse/news/4.7/M1/#Equinox I have two questions: - Does this mean p2 now has a mechanism to support the general OSGi capability/requirement model? (i.e. where a capability is a set of properties and a requirement is an LDAP filter) - Why are only "osgi.service" capabilities added? Should't there be also "osgi.implementation" capabilities? Regards Todor On Fri, Jan 27, 2017 at 2:46 PM, Sravan K Lakkimsetti < sravankum...@in.ibm.com> wrote: > Hi, > > We are pleased to announce that Oxygen M5 is available for download and > updates. > > Eclipse downloads: > http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M5-201701261030/ > > New and Noteworthy: > http://www.eclipse.org/eclipse/news/4.7/M5/ > > Update existing (non-production) installs: > http://download.eclipse.org/eclipse/updates/4.7milestones/ > > Specific repository good for building against: > http://download.eclipse.org/eclipse/updates/4.7milestones/ > S-4.7M5-201701261030/ > > Equinox specific downloads: > http://download.eclipse.org/equinox/drops/S-OxygenM5-201701261030/ > > Thank you to everyone who made this checkpoint possible. > > > Thanks and Regards, > Sravan > > Sravan Kumar Lakkimsetti > IBM India Pvt Ltd, > Embassy Golf Links Business Park, D Block, > Off Indiranagar-Kormangla Inner Ring Road, > Bangalore - 560071, India > Phone: 91-80-41776858 > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev > ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Uses constraints in p2 (was Convergence between p2 and the OSGiresolver+repository)
It may be useful to see how the bundle resolution problem is proven to be NP-Complete through 3-SAT: http://stackoverflow.com/questions/2085106/is-the-resolution-problem-in-osgi-np-complete On Fri, Nov 18, 2016 at 10:32 AM, Todor Boev <rinsv...@gmail.com> wrote: > My math is very rusty and my math background is in a different area. > Because of this I hoped to do the mostly programming exercise to integrate > the Resolver service in p2 rather than to extend the SAT mapping. I need to > look at the OSGi-to-SAT mapping paper in order to understand if this is > possible with the current design of the Resolver. > > Regards > > On Fri, Nov 18, 2016 at 5:17 AM, Pascal Rapicault <pas...@rapicault.net> > wrote: > >> On 11/17/2016 8:54 AM, Peter Kriens wrote: >> >> I remember trying to map uses constraints to a boolean expression but >> could not find any way that did not blow up the expression size. This >> seemed very unfortunate because I think they can actually be used to reduce >> the search space considerably. >> >> I'm really happy to see that there is at least 3 people if not more >> interested in the exercise of seeing how to encode uses constraints to SAT. >> How do you guys want to get moving on this? >> Peter, would you happen to still have what you had done? >> >> >> >> From an API level I do not think there is a big deal. The resolver could >> just fetch all resources at start. It can of course only return a single >> solution. This might be unfortunate but I find it hard to see why that is a >> limitation since any solution that satisfies all requirements should be ok. >> >> Kind regards, >> >> Peter Kriens >> >> >> >> On 17 nov. 2016, at 14:41, Thomas Watson <tjwat...@us.ibm.com> wrote: >> >> I will be interested to see if you can successfully map the OSGi uses >> concept into the SAT solver p2 uses. I briefly looked at that a long time >> ago when we were refactoring the Equinox framework (Luna) and were >> replacing the old Equinox resolver. It was far from obvious how you would >> achieve this. At that time I opt'ed to collaborate with a common resolver >> in Felix for the Equinox framework. But this is no magic implementation. >> There are still cases where the OSGi resolver algorithm will blow up. In >> Equinox we try to minimize that possibility by avoiding the resolution of >> all (1) bundles at once. But as Pascal states, this does leave out >> some possible valid solutions that you will then not discover while >> resolving. >> >> If you do focus on how to map uses into the SAT solver in p2 I would be >> interested in collaborating to see if such a resolver would outperform the >> Felix resolver we use at runtime. My hope at the time I was looking into >> this was to map an OSGi Resolver service on top of the SAT solver >> implementation. But I cannot remember how the SAT solver is driven. I >> suspect the split between the OSGI Resovler and the OSGi ResolveContext >> will not fit well into the SAT implementation model. >> >> Tom >> >> >> >> >> >> From:Todor Boev <rinsv...@gmail.com> >> To:Equinox development mailing list <equinox-dev@eclipse.org> >> Date:11/17/2016 02:22 AM >> Subject:Re: [equinox-dev] Convergence between p2 and the OSGi >> resolver+repository >> Sent by:equinox-dev-boun...@eclipse.org >> -- >> >> >> >> - Regarding batch resolution: >> Ultimately I think the batch processing is about performance. At >> provisioning time where finding the best solution trumps speed the resolver >> can be executed against the entire set. But I have to try this. After than >> the equinox runtime should be able to re-create a correct (maybe not >> identical) resolution from the much smaller set of resources. I have tried >> the resolver against about 700 bundles and it did okay, but this is well >> short of 10,000. More research requiredsome day. >> >> - Regarding the additional p2 concepts: >> Can you point me to the documentation of how the resolution problem is >> converted to a SAT formula? >> >> Best regards >> >> On Thu, Nov 17, 2016 at 6:20 AM, Pascal Rapicault <*pas...@rapicault.net* >> <pas...@rapicault.net>> wrote: >> On 11/16/2016 10:49 AM, Todor Boev wrote: >> - Regarding resolver behavior: >> The goal is actually to replace the behavior of the objective function >> with the behavior of the resolver. This
Re: [equinox-dev] Uses constraints in p2 (was Convergence between p2 and the OSGiresolver+repository)
My math is very rusty and my math background is in a different area. Because of this I hoped to do the mostly programming exercise to integrate the Resolver service in p2 rather than to extend the SAT mapping. I need to look at the OSGi-to-SAT mapping paper in order to understand if this is possible with the current design of the Resolver. Regards On Fri, Nov 18, 2016 at 5:17 AM, Pascal Rapicault <pas...@rapicault.net> wrote: > On 11/17/2016 8:54 AM, Peter Kriens wrote: > > I remember trying to map uses constraints to a boolean expression but > could not find any way that did not blow up the expression size. This > seemed very unfortunate because I think they can actually be used to reduce > the search space considerably. > > I'm really happy to see that there is at least 3 people if not more > interested in the exercise of seeing how to encode uses constraints to SAT. > How do you guys want to get moving on this? > Peter, would you happen to still have what you had done? > > > > From an API level I do not think there is a big deal. The resolver could > just fetch all resources at start. It can of course only return a single > solution. This might be unfortunate but I find it hard to see why that is a > limitation since any solution that satisfies all requirements should be ok. > > Kind regards, > > Peter Kriens > > > > On 17 nov. 2016, at 14:41, Thomas Watson <tjwat...@us.ibm.com> wrote: > > I will be interested to see if you can successfully map the OSGi uses > concept into the SAT solver p2 uses. I briefly looked at that a long time > ago when we were refactoring the Equinox framework (Luna) and were > replacing the old Equinox resolver. It was far from obvious how you would > achieve this. At that time I opt'ed to collaborate with a common resolver > in Felix for the Equinox framework. But this is no magic implementation. > There are still cases where the OSGi resolver algorithm will blow up. In > Equinox we try to minimize that possibility by avoiding the resolution of > all (1) bundles at once. But as Pascal states, this does leave out > some possible valid solutions that you will then not discover while > resolving. > > If you do focus on how to map uses into the SAT solver in p2 I would be > interested in collaborating to see if such a resolver would outperform the > Felix resolver we use at runtime. My hope at the time I was looking into > this was to map an OSGi Resolver service on top of the SAT solver > implementation. But I cannot remember how the SAT solver is driven. I > suspect the split between the OSGI Resovler and the OSGi ResolveContext > will not fit well into the SAT implementation model. > > Tom > > > > > > From:Todor Boev <rinsv...@gmail.com> > To:Equinox development mailing list <equinox-dev@eclipse.org> > Date:11/17/2016 02:22 AM > Subject:Re: [equinox-dev] Convergence between p2 and the OSGi >resolver+repository > Sent by:equinox-dev-boun...@eclipse.org > -- > > > > - Regarding batch resolution: > Ultimately I think the batch processing is about performance. At > provisioning time where finding the best solution trumps speed the resolver > can be executed against the entire set. But I have to try this. After than > the equinox runtime should be able to re-create a correct (maybe not > identical) resolution from the much smaller set of resources. I have tried > the resolver against about 700 bundles and it did okay, but this is well > short of 10,000. More research requiredsome day. > > - Regarding the additional p2 concepts: > Can you point me to the documentation of how the resolution problem is > converted to a SAT formula? > > Best regards > > On Thu, Nov 17, 2016 at 6:20 AM, Pascal Rapicault <*pas...@rapicault.net* > <pas...@rapicault.net>> wrote: > On 11/16/2016 10:49 AM, Todor Boev wrote: > - Regarding resolver behavior: > The goal is actually to replace the behavior of the objective function > with the behavior of the resolver. This is the best way to guarantee that > both p2 and the OSGi runtime agree on what is a consistent set of bundles. > For example p2 does not take into account package uses constraints which > leads to p2 selecting bundles that later fail to resolve at runtime. It > does not matter which way to resolve is better, so long as they agree. > Since the OSGi resolver is very unlikely to change it falls on p2 to match > it's behavior. My current company (software ag) has had quite a number of > issues where essentially p2 sets up the resolver to fail. > > - Regarding resolver scalability: > The resolution is split between the resolver which
Re: [equinox-dev] Convergence between p2 and the OSGi resolver+repository
- Regarding batch resolution: Ultimately I think the batch processing is about performance. At provisioning time where finding the best solution trumps speed the resolver can be executed against the entire set. But I have to try this. After than the equinox runtime should be able to re-create a correct (maybe not identical) resolution from the much smaller set of resources. I have tried the resolver against about 700 bundles and it did okay, but this is well short of 10,000. More research requiredsome day. - Regarding the additional p2 concepts: Can you point me to the documentation of how the resolution problem is converted to a SAT formula? Best regards On Thu, Nov 17, 2016 at 6:20 AM, Pascal Rapicault <pas...@rapicault.net> wrote: > On 11/16/2016 10:49 AM, Todor Boev wrote: > > - Regarding resolver behavior: > The goal is actually to replace the behavior of the objective function > with the behavior of the resolver. This is the best way to guarantee that > both p2 and the OSGi runtime agree on what is a consistent set of bundles. > For example p2 does not take into account package uses constraints which > leads to p2 selecting bundles that later fail to resolve at runtime. It > does not matter which way to resolve is better, so long as they agree. > Since the OSGi resolver is very unlikely to change it falls on p2 to match > it's behavior. My current company (software ag) has had quite a number of > issues where essentially p2 sets up the resolver to fail. > > - Regarding resolver scalability: > The resolution is split between the resolver which processes the current > set of resources and the resolver context which selects candidates when > asked. If the goal is to support a very high number of candidates - a > resolver context impl optimized for searches in a large candidate space can > be provided. If the goal is to produce a solution that includes a very high > number of resources - more research is required. Even if the initial set is > 10,000 the resolver can be asked to process them not all at once, but > incrementally in batches or even one by one. Which is in fact what equinox > does today. > > The thing is that if you look at a subset of the available bundles, > you may find a solution that is not the optimal one. p2 will consider all > the possible candidates in one resolution invocation. > > > I am trying to determine if it makes sense to invest effort in prototyping > this given that subtle changes in behavior are in fact a goal, rather than > an issue. > > Even though on the surface p2 resolver looks similar to what the OSGi > resolver does, p2 has at least 2 additional concepts: > 1) the expression of strict negation > 2) the concept of patch > > I'm tempted to think that it is probably simpler to add support for the > uses-clause in p2 (this has been a known issue for years, but I can't seem > to find the bug tonight) than it is to replace the resolver completely and > get all the tests to pass. The encoding of dependencies to a SAT formula is > well documented and so are the optimization functions. > > > On Wed, Nov 16, 2016 at 4:44 AM, Pascal Rapicault <pas...@rapicault.net> > wrote: > >> On 11/15/2016 12:52 PM, Todor Boev wrote: >> >> Hello, >> >> Are there any plans to bring together p2 and OSGi resolver+repository >> standards? >> >> There is no immediate plan for this. >> >> >> It should be beneficial to have similar (maybe identical?) dependency >> resolution at provisioning time and later at runtime. >> >> The install time and runtime resolvers resolve a slightly different >> problem because the install time resolver has to look for candidates in a >> large space, whereas the runtime one has to connect as many components >> together. >> I have not tried replacing the p2 resolver with the new OSGi resolver >> so I can't tell how it would perform. >> >> >> Specifically: >> - Is it possible to publish the bundle generic capabilities/requirements >> to the p2 repository? >> >> Yes this should be possible. The underlying p2 capability / >> requirement model is really extensible and the current limitation is only >> the serialized format. >> >> - Is it possible to use the equinox Resolver inside the p2 Planner? >> >> It is possible to get something going but I'm not sure if this will >> scale (p2 resolver is able to perform seamlessly on 10's of thousands of >> IUs), nor if you will be able to replicate the subtleties that result from >> having an objective function. >> >> - Even if the equinox Resolver can not be used is it possible for p2 to >> ha
Re: [equinox-dev] Convergence between p2 and the OSGi resolver+repository
- Regarding resolver behavior: The goal is actually to replace the behavior of the objective function with the behavior of the resolver. This is the best way to guarantee that both p2 and the OSGi runtime agree on what is a consistent set of bundles. For example p2 does not take into account package uses constraints which leads to p2 selecting bundles that later fail to resolve at runtime. It does not matter which way to resolve is better, so long as they agree. Since the OSGi resolver is very unlikely to change it falls on p2 to match it's behavior. My current company (software ag) has had quite a number of issues where essentially p2 sets up the resolver to fail. - Regarding resolver scalability: The resolution is split between the resolver which processes the current set of resources and the resolver context which selects candidates when asked. If the goal is to support a very high number of candidates - a resolver context impl optimized for searches in a large candidate space can be provided. If the goal is to produce a solution that includes a very high number of resources - more research is required. Even if the initial set is 10,000 the resolver can be asked to process them not all at once, but incrementally in batches or even one by one. Which is in fact what equinox does today. I am trying to determine if it makes sense to invest effort in prototyping this given that subtle changes in behavior are in fact a goal, rather than an issue. On Wed, Nov 16, 2016 at 4:44 AM, Pascal Rapicault <pas...@rapicault.net> wrote: > On 11/15/2016 12:52 PM, Todor Boev wrote: > > Hello, > > Are there any plans to bring together p2 and OSGi resolver+repository > standards? > > There is no immediate plan for this. > > > It should be beneficial to have similar (maybe identical?) dependency > resolution at provisioning time and later at runtime. > > The install time and runtime resolvers resolve a slightly different > problem because the install time resolver has to look for candidates in a > large space, whereas the runtime one has to connect as many components > together. > I have not tried replacing the p2 resolver with the new OSGi resolver > so I can't tell how it would perform. > > > Specifically: > - Is it possible to publish the bundle generic capabilities/requirements > to the p2 repository? > > Yes this should be possible. The underlying p2 capability / > requirement model is really extensible and the current limitation is only > the serialized format. > > - Is it possible to use the equinox Resolver inside the p2 Planner? > > It is possible to get something going but I'm not sure if this will > scale (p2 resolver is able to perform seamlessly on 10's of thousands of > IUs), nor if you will be able to replicate the subtleties that result from > having an objective function. > > - Even if the equinox Resolver can not be used is it possible for p2 to > handle generic requirements/capabilities? > > Yes. This should not be too much work. > > > > Regards, > Todor Boev > > > ___ > equinox-dev mailing listequinox-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev > ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Convergence between p2 and the OSGi resolver+repository
Hello, Are there any plans to bring together p2 and OSGi resolver+repository standards? It should be beneficial to have similar (maybe identical?) dependency resolution at provisioning time and later at runtime. Specifically: - Is it possible to publish the bundle generic capabilities/requirements to the p2 repository? - Is it possible to use the equinox Resolver inside the p2 Planner? - Even if the equinox Resolver can not be used is it possible for p2 to handle generic requirements/capabilities? Regards, Todor Boev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Http Whiteboard implementation over Tomcat 8
Thanks for the detailed reply. Looking at HttpServiceServlet I can't help, but notice that the entire whiteboard seems to be anchored in a single ServletContext. Therefore it must multiplex access to this context to simulate multiple whiteboard web applications. This does not seem like a very easy/stable design to implement. Would it be possible to introduce a service oriented solution along the lines of the Gemini Web web container adapter: http://git.eclipse.org/c/gemini.web/org.eclipse.gemini.web.gemini-web-container.git/tree/org.eclipse.gemini.web.core/src/main/java/org/eclipse/gemini/web/core/spi/ServletContainer.java Implementations of this adapter have to be able to programatically talk to a concrete web container instance to make it create ServletContexts. From my experience with Tomcat it is not very hard to make a ServletContext (i.e. a web app internal structure) entirely programatically without any web.xml etc. metadata. It is also pretty easy to boot Tomcat from a bundle. I imagine it will be even easier on Jetty. Combine this with the programmatic servlet/filter/listener creation in Servlet 3.0 and it seems like a compelling design. Basically the whiteboard will only have to bridge Servlet 3.0 with the OSGi service registry. Does such a (radical) redesign seem feasible? Regards On Fri, Oct 28, 2016 at 3:12 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > The bundle you need is: > > http://download.eclipse.org/eclipse/updates/4.6/R-4.6- > 201606061100/plugins/org.eclipse.equinox.http.servlet_ > 1.3.0.v20160517-1559.jar > > I you are using PDE projects then you can just use this repository as > normal. > > IF you are using bndtools >=3.3 you can use this repository configuration: > > -plugin.Eclipse.Neon: \ > aQute.bnd.repository.p2.provider.P2Repository; \ > name= "Eclipse 4.6 (Neon)"; \ > url = "http://download.eclipse.org/ > eclipse/updates/4.6/R-4.6-201606061100/" > > In order to use this bundle with your own servlet container you must > create a bundle which will create an instance of > > org.eclipse.equinox.http.servlet.HttpServiceServlet > > That instance must provide access to a ServletContext of the real servlet > container, and from there the implementation will take over handling sub > servlet context's for you. > > Here's a real world implementation of this: > > https://github.com/liferay/liferay-portal/blob/master/ > modules/apps/static/portal-osgi-web/portal-osgi-web-wab- > extender/src/main/java/com/liferay/portal/osgi/web/wab/ > extender/internal/adapter/HttpAdapter.java > > Furthermore, I really dislike how this is implemented, It's a pretty > terrible API design. It would be great to make this service oriented. I'll > certainly appreciate any contributions to make it better. > > - Ray > > > On Wed, Oct 26, 2016 at 2:46 PM, Todor Boev <rinsv...@gmail.com> wrote: > >> Hello, >> >> I am looking for an implementation of the Http Whiteboard OSGi standard >> (Chapter 140 EEG spec). >> I also need to run it over Tomcat 8. >> Finally it is preferable that the whiteboard runs in "native mode" rather >> than via a bridge servlet. I.e. have Tomcat instantiate an actual >> ServletContext for every web app root as it does with WAR/WABs. >> >> Equinox supposedly has an Http whiteboard R6 implementation, but I am >> somewhat confused as to which bundles do I need to run to get it. >> >> Regards >> Todor >> >> ___ >> equinox-dev mailing list >> equinox-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev > ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Http Whiteboard implementation over Tomcat 8
Hello, I am looking for an implementation of the Http Whiteboard OSGi standard (Chapter 140 EEG spec). I also need to run it over Tomcat 8. Finally it is preferable that the whiteboard runs in "native mode" rather than via a bridge servlet. I.e. have Tomcat instantiate an actual ServletContext for every web app root as it does with WAR/WABs. Equinox supposedly has an Http whiteboard R6 implementation, but I am somewhat confused as to which bundles do I need to run to get it. Regards Todor ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Support for Declarative Services 1.3 (OSGi release 6)
Hello, It seems that the equinox DS bundle currently does not support OSGi release 6 standard (DS 1.3). Are there any plans to upgrade? In particular I am interested in support for "Component property Types" (OSGi enterprise 6, 112.8.2, page 216) Regards ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
