Re: [equinox-dev] GWT+Equinox
You might want to get the real Jetty stuff rather than checking it out using the psf. The psf may be out of date. Try using all released code. Jeff Ian Bull wrote: Ricardo, I have this working with GWT 1.5 and Eclipse 3.4, so we know it's possible :-). Have you tried adding javax.servlet to the required plug-ins for GWT? I have a GWT bundle, and I noticed that it depends on javax.servlet. If I remove this dependency I get the class cast exception. I also removed all the servlet stuff from Exported Packages list. (See the Runtime tab in the Manifest editor). Cheers, Ian Ricardo Giacomin wrote: Hi there, I tried to follow the directions from wiki page http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with no success. The problem is that no matter what I do I still get the ClassCastException when the ServletManager tries to instantiate the servlet. It is probably a problem of different servlet API version (2.4 in equinox http and 2.3 in gwt). I’m using: GWT 1.5.2 Eclipse 3.4 Jetty Http from http://www.eclipse.org/equinox/server/downloads/jettyhttp-anon.psf Any hints? Thank you in advance. Regards, Ricardo Giacomin -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] GWT+Equinox
This is what I did originally: 1) I created a plug-in wrapping gwt-user.jar and gwt-devwindows.jar (this plug-in is called equinox.gwt) 2) In this plug-in manifest, I removed javax.servlet.* from exported packages and appended Eclipse-BuddyPolicy: registered 3) I had a working gwt RPC sample application (pretty much a hello world) that I converted to a plug-in project (this plug-in is called equinox.gwt.sample) 4) I checked-out the following plug-ins from dev.eclipse.org (using the jetty http psf) . javax.servlet (v2_4) . org.apache.commons.logging (v1_0_4) . org.eclipse.equinox.http.jetty . org.eclipse.equinox.http.registry . org.eclipse.equinox.http.servlet . org.mortbay.jetty (5_1_11) 5) In plug-in equinox.gwt.sample I extended org.eclipse.equinox.http.registry.resources and org.eclipse.equinox.registry.servlets 6) In manifest file, I appended Eclipse-RegisterBuddy: equinox.gwt My RemoteServiceServlet is called MyServiceImpl. It is instantiated but a ClassCastException is thrown when it is assigned to newDelegate, in SevletManager.initializeDelegate() method. Ian, if I put javax.servlet plug-in as required to equinox.gwt, I get HTTP ERROR: 405 HTTP method GET is not supported by this URL. If I put javax.servlet as required to equinox.gwt.sample, I still get the ClassCastException. Jeff, which is the stable version I should get from cvs (instead of using psf file)? I tried version R3_4 with no success. Any other hints? Best, Ricardo Giacomin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Bull Sent: Tuesday, September 02, 2008 4:14 PM To: Equinox development mailing list Subject: Re: [equinox-dev] GWT+Equinox Ricardo, I have this working with GWT 1.5 and Eclipse 3.4, so we know it's possible :-). Have you tried adding javax.servlet to the required plug-ins for GWT? I have a GWT bundle, and I noticed that it depends on javax.servlet. If I remove this dependency I get the class cast exception. I also removed all the servlet stuff from Exported Packages list. (See the Runtime tab in the Manifest editor). Cheers, Ian Ricardo Giacomin wrote: Hi there, I tried to follow the directions from wiki page http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with no success. The problem is that no matter what I do I still get the ClassCastException when the ServletManager tries to instantiate the servlet. It is probably a problem of different servlet API version (2.4 in equinox http and 2.3 in gwt). I'm using: GWT 1.5.2 Eclipse 3.4 Jetty Http from http://www.eclipse.org/equinox/server/downloads/jettyhttp-anon.psf Any hints? Thank you in advance. Regards, Ricardo Giacomin -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- R. Ian Bull PhD Candidate, University of Victoria http://www.ianbull.com http://irbull.blogspot.com/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] When is DS done loading services?
The whole point of services is that the are dynamic. The fact the DS is processing them on behalf of some bundle does not mean that another bundle should know or observe that. Bundles which depend upon a service need to deal with that service's dynamism. You can't assume a bundle's activator or starting a bundle will synchronously register some services. I would not support an option for DS to synchronously register services during bundle start as this means people will improperly use that. You may also be seeing an impedance mismatch between the lifecycle of extensions and services. Extensions become active when the bundle is resolved while services become active only when the bundle is started. Switching to use extensions will not allow for dynamism (unless you want to write all the code to use the extension registry API to do so.) You may be able to use startlevels to mitigate the issue (make sure all bundles providing service B are started before bundles using B), but this is also a hack. It would be better if service A dealt with the dynamics of service B such that service A has a dynamic dependency on service B and is able to accept B's being registered and unregistered at any time. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Stoyan Boshev [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 07:51 AM Subject: Re: [equinox-dev] When is DS done loading services? Hi Otto, I guess your problem is connected to the asynchronous processing of the DS services. As far as I understand the situation is: your application bundles are started, then your application is started but at this moment not all of the DS services are inited yet because they are being asynchronously processed. Unfortunately currently there is no way to find out when DS completes the DS services processing. I think if there was an option that DS bundle process the DS services in the started bundles synchronously, it would solve your problem. So I will open bug(enhancement) about that and hopefully this will be implemented soon. As a possible workaround you could observe the running threads and when the thread with name Component Resolve Thread disappears this would mean that DS bundle has no more work to do and eventually all of your DS services are processed. I realize this is not a clean solution (that's why I call it workaround) but at this moment I cannot find out a more appropriate working solution without modifications in the DS bundle. Stoyan Cortez, Otto wrote: I made a post to the Eclipse newcomers group a few weeks ago, but did not get a response. I don’t know if this is the appropriate place for this question, but hopefully someone can point me in the right direction. We are building a headless RCP application and we would like to use DS to make functionality available. The problem we are running into is that not all of the services we declared through DS get loaded and are visible before our application executes. For example, I have a service A which needs 0..n instances of another service B. The issue I'm running into is that if the implementations of service B are spread across several bundles, then the service A will not have seen all instances of service B when it is called since the application starts (and sometimes ends) running before DS is done looking through all the bundles and registering all the services in the active bundles. Is there a way to know when declarative services is done looking through the active bundles and loading the services found in them? Am I missing something? It seems that using the plug-in registry may solve this issue. Is that perhaps a better way to go? Thanks, Otto This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- - dipl. eng. Stoyan Boshev . Department manager ProSyst Labs EOOD 1606 Sofia, Bulgaria . 48 Vladajska Str. Tel. +359 2 953 05 88; Fax +359 2 953 26 17 Mobile: +359 88 898 29 17 http://www.prosyst.com . [EMAIL PROTECTED] - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] .qualifier for export package?
If you change API during dev cycle, that is the proper time to also change the major or minor version. That is the whole point. I would assume that API tooling will complain until you do so. Just changing the qualifier is insufficient to capture an API change. Also, I think that last thing we want to see are bundles using qualifiers in import package statements! So if you use qualifier to denote API change during dev, then other bundles will need to import using qualifiers to ensure they wire to the desire API if they use it. UGLY! Qualifiers are useful to capture implementation changes. But API is a specified thing that changes deliberately and (hopefully) slowly and its version is not subject to implementation. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 06:16 AM Subject: Re: [equinox-dev] .qualifier for export package? I understand your hestiation and actually agree with you from the released code point of view. However, we spend a lot of time dealing with code and API that is in development. If we are to have any hope of provisioning and managing that, we need to know the difference between the various iterations of the packages. For example, when someone adds an API during the dev cycle and you want use it, you need to import the right version of the package to ensure you get it. Changing the first three segments version number of the package for every change done in the dev cycle feels too disruptive. To a certain extent this could be handled in the provisioning system but that would force the situation of bundles in a particular context (e.g., a build lineup). That is, bundles would no longer be completely/accurately self-describing. Jeff BJ Hargrave wrote: I would be extremely cautious about using qualifier on package versions. I must say that I have never seen it done. It seems an over specification. I think that having build tools to advise you to increment the micro is more than sufficient. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Thomas Watson/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/02 10:45 AM Subject: Re: [equinox-dev] .qualifier for export package? Before recommending every package uses a qualifier I have the following concerns: 1) In Eclipse we have loads of packages. We better make sure all identical qualifier Strings are shared (interned etc.) for performance reasons. Today when loading from a cached state we share identical Version objects. Because package versions are managed independently we will end up with lots of different versions that have the same qualifier exported by a bundle. We also will limit the ability to share Version objects across bundles because each will use a different qualifier (unless we happen to use the same CVS tag). 2) The qualifier will change even in cases where no code was touched in the package. I'm not sure this is a valid concern. The code got recompiled so perhaps changing the version qualifier is warranted. But we need to think about the consequences. For example, I can see API tooling start to complain that the micro version of a package should be increased to indicate a bug fix when comparing the package versions with a base line. It will notice that the qualifier changed from a previous release but the micro version was not increased. 3) What about versions of packages which we do not maintain the API for at Eclipse. Things like org.osgi.* and orbit bundles. Shouldn't we use the version the producers of the API have defined? Adding a qualifier here does not seem right, especially if a qualifier is already defined by the producers. On the surface this sounds like a fine idea, and I am not completely against it. But I would like to take the first step of versioning the Eclipse API packages first to see what all the issues are with independent package versioning. I'm sure we will run into other hurdles along the way. For example, how does a developer maintain the version of a split package across all the bundles the package is split? Tom Chris Aniszczyk ---08/31/2008 02:46:34 PM---On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] From: Chris Aniszczyk [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 08/31/2008 02:46 PM Subject: Re: [equinox-dev] .qualifier for export package? On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] wrote: As version numbers on packages become more prevalent does it start making sense to use .qualifier on them in addition to bundle version
RE: [equinox-dev] When is DS done loading services?
It is more important for us to know what functionality is installed and available before parts of the application execute then it is for us to support dynamism. I would like to keep the dynamism if we can, but to do that and provide reliable execution I think the application would need to guarantee that all services known through the bundle manifests will be initialized before we start processing. I guess using extensions might be a better fit. I'm not sure if we need DS to synchronously register services as much as some way to listen to DS events or know its state, like is it just sitting around waiting for more bundles to be activated or deactivated. I was focused on services being managed by DS since I thought DS would know weather it was done initializing all services listed in the active bundles' manifest files and then we would be able to say to users which may supply functionality, well if you use DS then we could guarantee that we wouldn't start until DS had initialized your services. Thanks, Otto From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave Sent: Wednesday, September 03, 2008 7:22 AM To: Equinox development mailing list Subject: Re: [equinox-dev] When is DS done loading services? The whole point of services is that the are dynamic. The fact the DS is processing them on behalf of some bundle does not mean that another bundle should know or observe that. Bundles which depend upon a service need to deal with that service's dynamism. You can't assume a bundle's activator or starting a bundle will synchronously register some services. I would not support an option for DS to synchronously register services during bundle start as this means people will improperly use that. You may also be seeing an impedance mismatch between the lifecycle of extensions and services. Extensions become active when the bundle is resolved while services become active only when the bundle is started. Switching to use extensions will not allow for dynamism (unless you want to write all the code to use the extension registry API to do so.) You may be able to use startlevels to mitigate the issue (make sure all bundles providing service B are started before bundles using B), but this is also a hack. It would be better if service A dealt with the dynamics of service B such that service A has a dynamic dependency on service B and is able to accept B's being registered and unregistered at any time. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance http://www.osgi.org/ [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Stoyan Boshev [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 07:51 AM Subject: Re: [equinox-dev] When is DS done loading services? Hi Otto, I guess your problem is connected to the asynchronous processing of the DS services. As far as I understand the situation is: your application bundles are started, then your application is started but at this moment not all of the DS services are inited yet because they are being asynchronously processed. Unfortunately currently there is no way to find out when DS completes the DS services processing. I think if there was an option that DS bundle process the DS services in the started bundles synchronously, it would solve your problem. So I will open bug(enhancement) about that and hopefully this will be implemented soon. As a possible workaround you could observe the running threads and when the thread with name Component Resolve Thread disappears this would mean that DS bundle has no more work to do and eventually all of your DS services are processed. I realize this is not a clean solution (that's why I call it workaround) but at this moment I cannot find out a more appropriate working solution without modifications in the DS bundle. Stoyan Cortez, Otto wrote: I made a post to the Eclipse newcomers group a few weeks ago, but did not get a response. I don't know if this is the appropriate place for this question, but hopefully someone can point me in the right direction. We are building a headless RCP application and we would like to use DS to make functionality available. The problem we are running into is that not all of the services we declared through DS get loaded and are visible before our application executes. For example, I have a service A which needs 0..n instances of another service B. The issue I'm running into is that if the implementations of service B are spread across several bundles, then the service A will not have seen all instances of service B when it is called since the application starts (and sometimes ends) running before DS is done looking through all the bundles and registering all the services in the
RE: [equinox-dev] When is DS done loading services?
But even DS only knows about started bundles. If a bundle is started after DS has processed some bundle, then new services can be registered. There is no way for DS to know about all possible services being ready since some may come from bundles yet to be started. The best DS could tell you is that it is done processing services from bundles that are currently started. It is far better in the long run for the application to handle dynamism. Anything you do today to try and enforce some ordering will likely fail in the future when some thing changes about the set of installed bundles. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Cortez, Otto [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 02:48 PM Subject: RE: [equinox-dev] When is DS done loading services? It is more important for us to know what functionality is installed and available before parts of the application execute then it is for us to support dynamism. I would like to keep the dynamism if we can, but to do that and provide reliable execution I think the application would need to guarantee that all services known through the bundle manifests will be initialized before we start processing. I guess using extensions might be a better fit. I’m not sure if we need DS to synchronously register services as much as some way to listen to DS events or know its state, like is it just sitting around waiting for more bundles to be activated or deactivated. I was focused on services being managed by DS since I thought DS would know weather it was done initializing all services listed in the active bundles’ manifest files and then we would be able to say to users which may supply functionality, well if you use DS then we could guarantee that we wouldn’t start until DS had initialized your services. Thanks, Otto From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave Sent: Wednesday, September 03, 2008 7:22 AM To: Equinox development mailing list Subject: Re: [equinox-dev] When is DS done loading services? The whole point of services is that the are dynamic. The fact the DS is processing them on behalf of some bundle does not mean that another bundle should know or observe that. Bundles which depend upon a service need to deal with that service's dynamism. You can't assume a bundle's activator or starting a bundle will synchronously register some services. I would not support an option for DS to synchronously register services during bundle start as this means people will improperly use that. You may also be seeing an impedance mismatch between the lifecycle of extensions and services. Extensions become active when the bundle is resolved while services become active only when the bundle is started. Switching to use extensions will not allow for dynamism (unless you want to write all the code to use the extension registry API to do so.) You may be able to use startlevels to mitigate the issue (make sure all bundles providing service B are started before bundles using B), but this is also a hack. It would be better if service A dealt with the dynamics of service B such that service A has a dynamic dependency on service B and is able to accept B's being registered and unregistered at any time. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Stoyan Boshev [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 07:51 AM Subject: Re: [equinox-dev] When is DS done loading services? Hi Otto, I guess your problem is connected to the asynchronous processing of the DS services. As far as I understand the situation is: your application bundles are started, then your application is started but at this moment not all of the DS services are inited yet because they are being asynchronously processed. Unfortunately currently there is no way to find out when DS completes the DS services processing. I think if there was an option that DS bundle process the DS services in the started bundles synchronously, it would solve your problem. So I will open bug(enhancement) about that and hopefully this will be implemented soon. As a possible workaround you could observe the running threads and when the thread with name Component Resolve Thread disappears this would mean that DS bundle has no more work to do and eventually all of your DS services are processed. I realize this is not a clean solution (that's why I call it workaround) but at this moment I cannot find out a more appropriate working solution without modifications in the DS bundle. Stoyan Cortez, Otto wrote: I made a post to the Eclipse newcomers group a few weeks ago, but did not get
RE: [equinox-dev] When is DS done loading services?
I think part of the problem here is the term application. In this case we are talking about an RCP application which is defined as an Eclipse extension to the org.eclipse.core.runtime.applications extension point. When launching Eclipse the default application is started after the platform has been initialized and the start-level has reached the final state. RCP applications have historically depended on the platform to be fully booted and ready before their application is started. This mentality does not mix well with the dynamic nature of OSGi services. When DS is added to the mix the boot sequence become less predictable because services are not registered synchronously as bundles get started during the bootup process (incrementing the start-level). Currently the Eclipse application container just assumes the application is ready to launch after the the platform has been initialized and the final start-level has been reached. To work around the issue you will need to do something like BJ says and make the application handle dynamic service registrations. The problem you will run into is that the Eclipse application container has no idea that your Eclipse application depends on services before it is ready to launch. So in addition to making your application handle dynamic services, you will also need to handle waiting for your required services to be available in your application start method before allowing your application start method to continue to bring up your application. Or you can simply allow your application to start and put safeguards in to handle when a service is not available yet. It would be great if we could figure out a better way to mix the use of extensions and services together in an Eclipse application. Tom From: BJ Hargrave/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date:: 09/03/2008 02:04 PM Subject:RE: [equinox-dev] When is DS done loading services? But even DS only knows about started bundles. If a bundle is started after DS has processed some bundle, then new services can be registered. There is no way for DS to know about all possible services being ready since some may come from bundles yet to be started. The best DS could tell you is that it is done processing services from bundles that are currently started. It is far better in the long run for the application to handle dynamism. Anything you do today to try and enforce some ordering will likely fail in the future when some thing changes about the set of installed bundles. -- BJ Hargrave Senior Technical Staff office: +1 386 Member, IBM 848 1781 OSGi Fellow and CTO of mobile: +1 386 the OSGi Alliance848 3788 [EMAIL PROTECTED] From: Cortez, Otto [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 02:48 PM Subject: RE: [equinox-dev] When is DS done loading services? It is more important for us to know what functionality is installed and available before parts of the application execute then it is for us to support dynamism. I would like to keep the dynamism if we can, but to do that and provide reliable execution I think the application would need to guarantee that all services known through the bundle manifests will be initialized before we start processing. I guess using
Re: [equinox-dev] GWT+Equinox
I didn't use anything from CVS. The Eclipse SDK (aka Eclipse Classic, and possibly other eclipse distros), come with Jetty. I will create a small Hello World example and post it. I'm not sure I can post it here (since it uses the GWT bundle), but I can post it on my blog and link to it here. You're not the first person to request this, so it seems this setup has some use. I can also investigate the possibility of donating the code to the Eclipse Examples project. This may require an Orbit bundle for GWT though. cheers, Ian Ricardo Giacomin wrote: This is what I did originally: 1) I created a plug-in wrapping gwt-user.jar and gwt-devwindows.jar (this plug-in is called equinox.gwt) 2) In this plug-in manifest, I removed javax.servlet.* from exported packages and appended Eclipse-BuddyPolicy: registered 3) I had a working gwt RPC sample application (pretty much a hello world) that I converted to a plug-in project (this plug-in is called equinox.gwt.sample) 4) I checked-out the following plug-ins from dev.eclipse.org (using the jetty http psf) . javax.servlet (v2_4) . org.apache.commons.logging (v1_0_4) . org.eclipse.equinox.http.jetty . org.eclipse.equinox.http.registry . org.eclipse.equinox.http.servlet . org.mortbay.jetty (5_1_11) 5) In plug-in equinox.gwt.sample I extended org.eclipse.equinox.http.registry.resources and org.eclipse.equinox.registry.servlets 6) In manifest file, I appended Eclipse-RegisterBuddy: equinox.gwt My RemoteServiceServlet is called MyServiceImpl. It is instantiated but a ClassCastException is thrown when it is assigned to newDelegate, in SevletManager.initializeDelegate() method. Ian, if I put javax.servlet plug-in as required to equinox.gwt, I get HTTP ERROR: 405 HTTP method GET is not supported by this URL. If I put javax.servlet as required to equinox.gwt.sample, I still get the ClassCastException. Jeff, which is the stable version I should get from cvs (instead of using psf file)? I tried version R3_4 with no success. Any other hints? Best, Ricardo Giacomin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Bull Sent: Tuesday, September 02, 2008 4:14 PM To: Equinox development mailing list Subject: Re: [equinox-dev] GWT+Equinox Ricardo, I have this working with GWT 1.5 and Eclipse 3.4, so we know it's possible :-). Have you tried adding javax.servlet to the required plug-ins for GWT? I have a GWT bundle, and I noticed that it depends on javax.servlet. If I remove this dependency I get the class cast exception. I also removed all the servlet stuff from Exported Packages list. (See the Runtime tab in the Manifest editor). Cheers, Ian Ricardo Giacomin wrote: Hi there, I tried to follow the directions from wiki page http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with no success. The problem is that no matter what I do I still get the ClassCastException when the ServletManager tries to instantiate the servlet. It is probably a problem of different servlet API version (2.4 in equinox http and 2.3 in gwt). I'm using: GWT 1.5.2 Eclipse 3.4 Jetty Http from http://www.eclipse.org/equinox/server/downloads/jettyhttp-anon.psf Any hints? Thank you in advance. Regards, Ricardo Giacomin -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- R. Ian Bull PhD Candidate, University of Victoria http://www.ianbull.com http://irbull.blogspot.com/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Starting equinox framework in program
Meng, Thanks for your reply. Yes, my plug-in is an UI Eclipse plugin. And it's true that Equinox framework will be start firstly when Eclipse launched. But the problem is the Equinox framework I want to start is not the framework of Eclipse platform where my plug-in is install in. The Equinox framework I want to start is another framework (application), and all the bundle is in a folder. I want to start another Equinox framework through my plug-in, and install all the bundles of the application through my plug-in, then I can control and monitor the bundles on the Equinox framework. For that my plug-in is a Bundle Monitor tool to control another Equinox-based application. 2008/9/4 Meng Xin Zhu [EMAIL PROTECTED] As you said your application is an Eclipse plug-in, I assume it's RCP application whether it has UI or not. Equiiox(OSGi) framework would be started firstly when your application launch, then your plug-in can obtain BundleContext in its bundle activator. Don't need explicitly call EclipseStarter.startup to launch OSGi framework. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
