Re: How to use discouragedRuntimeAccess extension point
cool! Thanks. I wanted to let you know that we intend to use this feature in WASCE. We have not changed any code, but we are using the feature by adding this element to org.apache.geronimo.devtools.eclipse.core/plugin.xml: point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > id="org.apache.geronimo.generic.runtime.10"> value="/lib"/> value="/lib/endorsed"/> Our use case is to allow development of a J2EE app on WASCE (based on AG(Apache Geronimo)), but deploy the app on AG/WASCE or other J2EE app server. We want to warn the user against using any class that is specific to AG/WASCE and would thus cause problems when deploying on another J2EE app server. I mention this use case for consideration in future versions of the eclipse plugin, as I see there is discussion on its future direction. I would like to see this capability carried forward in some capacity in future releases. Thanks, Ted On 3/1/06, Sachin Patel <[EMAIL PROTECTED]> wrote: You should start using the run-time workbench to test your changes it will make things easier for you. Read this... http://www.developer.com/lang/article.php/3552481 in particular... "To test-run your work, PDE provides a special launch configuration type that allows you to launch another workbench instance (referred to as the run-time workbench) with your workspace plug-ins included in its configuration (this is also referred to as self-hosting—you don't have to install your plug-ins into an external workbench just to test-run them; instead, you can use your own development workbench installation, dynamically). Your Eclipse launch configuration will allow you to specify which plug-ins you want included, special command-line arguments, environment properties, and so on." - sachin On Mar 1, 2006, at 1:41 PM, Ted Kirby wrote: For the record, this did work, when I properly installed it in a fresh, new, pristine eclipse tree. It also worked when I lanched it in debug mode. What I had been doing was rebuild plugin, and extract it to my eclipse directory, on top of the old/existing code. (Perhaps this will work, if I use a completely new workspace?) I had then deleted my old projects, then created new ones, and this discouragedAccess rule was not working. Now, I installed my eclipse to a tst\base dir. To test, I xcopy that toe tst\e, then extract the plugin to tst\e, and run, with new workspace. On 3/1/06, Ted Kirby <[EMAIL PROTECTED]> wrote: I now have: I thought it worked once, but I have not been able to get it work again. Anything else I should check? I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well? Thanks, Ted On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation. Even though this is an acceptable and you have my recommendation on this solution we can go even further. Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath contai
Re: How to use discouragedRuntimeAccess extension point
You should start using the run-time workbench to test your changes it will make things easier for you. Read this... http://www.developer.com/lang/article.php/3552481in particular..."To test-run your work, PDE provides a special launch configuration type that allows you to launch another workbench instance (referred to as the run-time workbench) with your workspace plug-ins included in its configuration (this is also referred to as self-hosting—you don't have to install your plug-ins into an external workbench just to test-run them; instead, you can use your own development workbench installation, dynamically). Your Eclipse launch configuration will allow you to specify which plug-ins you want included, special command-line arguments, environment properties, and so on." - sachin On Mar 1, 2006, at 1:41 PM, Ted Kirby wrote:For the record, this did work, when I properly installed it in a fresh, new, pristine eclipse tree. It also worked when I lanched it in debug mode. What I had been doing was rebuild plugin, and extract it to my eclipse directory, on top of the old/existing code. (Perhaps this will work, if I use a completely new workspace?) I had then deleted my old projects, then created new ones, and this discouragedAccess rule was not working. Now, I installed my eclipse to a tst\base dir. To test, I xcopy that toe tst\e, then extract the plugin to tst\e, and run, with new workspace. On 3/1/06, Ted Kirby <[EMAIL PROTECTED]> wrote: I now have: I thought it worked once, but I have not been able to get it work again. Anything else I should check? I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well? Thanks, Ted On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation. Even though this is an acceptable and you have my recommendation on this solution we can go even further. Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ. - sachin On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote: Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only
Re: How to use discouragedRuntimeAccess extension point
For the record, this did work, when I properly installed it in a fresh, new, pristine eclipse tree. It also worked when I lanched it in debug mode. What I had been doing was rebuild plugin, and extract it to my eclipse directory, on top of the old/existing code. (Perhaps this will work, if I use a completely new workspace?) I had then deleted my old projects, then created new ones, and this discouragedAccess rule was not working. Now, I installed my eclipse to a tst\base dir. To test, I xcopy that toe tst\e, then extract the plugin to tst\e, and run, with new workspace. On 3/1/06, Ted Kirby <[EMAIL PROTECTED]> wrote: I now have: I thought it worked once, but I have not been able to get it work again. Anything else I should check? I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well? Thanks, Ted On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation. Even though this is an acceptable and you have my recommendation on this solution we can go even further. Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ. - sachin On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote: Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only? Here is my extension element: Thanks. On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrot
Re: How to use discouragedRuntimeAccess extension point
If the extension point doesn't provide the granularity of control that you need and want to have more programmatic control over it, then it needs to be done via facets. - sachin On Mar 1, 2006, at 1:44 AM, Ted Kirby wrote:I now have: I thought it worked once, but I have not been able to get it work again. Anything else I should check? I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well? Thanks, Ted On 2/28/06, Sachin Patel <[EMAIL PROTECTED]> wrote: Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation. Even though this is an acceptable and you have my recommendation on this solution we can go even further. Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ. - sachin On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote: Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only? Here is my extension element: Thanks. On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote: I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got:Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/se
Re: How to use discouragedRuntimeAccess extension point
I now have: I thought it worked once, but I have not been able to get it work again. Anything else I should check? I was not clear on your FYI. Do you recommend discouragedRuntimeAccess via this extension point for current release and facets for future release, or do you recommend facets for current release as well? Thanks, Ted On 2/28/06, Sachin Patel <[EMAIL PROTECTED]> wrote: Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation. Even though this is an acceptable and you have my recommendation on this solution we can go even further. Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ. - sachin On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote: Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only? Here is my extension element: Thanks. On 2/28/06, Sachin Patel <[EMAIL PROTECTED] > wrote: I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote: I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got: Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91) Where should I put the element?
RE: How to use discouragedRuntimeAccess extension point
Quick question on a related topic… is there a reason that we don’t have the geronimo10.serverdef file standalone but bundled it inside of the org.apache.geronimo.devtools.eclipse.core jar file? I noticed I got a standalone serverdef file for pretty much every server runtime I can define within my eclipse: Directory of E:\tools\eclipse3.1.2\eclipse\plugins\org.eclipse.jst.server.gener ic.serverdefinitions_1.0.0.v20060131b\servers 02/17/2006 04:33 PM 4,278 jboss.serverdef 02/17/2006 04:33 PM 5,228 jboss323.serverdef 02/17/2006 04:33 PM 5,120 jonas.serverdef 02/17/2006 04:33 PM 5,212 oracle.10.1.3.serverdef 02/17/2006 04:33 PM 4,144 weblogic81.serverdef 02/17/2006 04:33 PM 4,182 weblogic90.serverdef Thanks, Lin -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 5:35 PM To: dev@geronimo.apache.org Subject: Re: How to use discouragedRuntimeAccess extension point I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html. This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote: I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got: Wrapped exception org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91) Where should I put the element?
Re: How to use discouragedRuntimeAccess extension point
Check the schema definition for the extension point. (schema/discouragedRuntimeAccess.exsd file) You are not defining the extension point correctly. You also need to specify an id to binding to the the geronimo runtime. IIRC both jars and directories can be specified. FYI I think in future releases I'll be ridding of this extension point as I don't see any future value in it and there are better ways of accomplishing this such as the use of facets. But this is probably better for you anyway so you can re-use what ever existing code you have. However you need to programatically provide the function you desire in a "pluggable" manner by creating a facet extension point and binding it to the geronimo runtime. The facet extensions require you to implement the IDelegate interface and you can have multiple implementations for when the facet is added and removed or for any of the other lifecycle types the facet framework defines. (version changed, runtime changed). This will give you the best flexibility and in your implementation you will be able to do whatever you need to the classpath container or project configuration. The UI pieces will automatically be then taken care of and you will be able to add/remove the facet at project creation or after. The key idea behind this is that you can programatically do what you need to the project without modifying any existing code. If a custom wizard is needed for the facet to provide additional details then a facet wizard extension point exists as well which plugins in a wizard page when you facet is selected during project creation.Even though this is an acceptable and you have my recommendation on this solution we can go even further.Discussions are going on being able to improve the flexibility of runtimes. Runtimes can contain multiple components and as you've seen currently two components are defined, a JRE and a server classpath container. Currently all of the runtimes are using the same bridge that adds these two components. However in the future we want to be able to make it easier for adopters to provide "N" number of components. This capability is currently possible but its somewhat complex and one of the goals is to make this easier. So essentially the runtime classpath needs to be broken down into multiple components, at minimum a J2EE component and a non J2EE component. But the vision is to go even beyond that. (ejb component, web component) thus each project type may target the same server buts the contents of its runtime would differ. - sachin On Feb 28, 2006, at 6:09 PM, Ted Kirby wrote:Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only? Here is my extension element: Thanks. On 2/28/06, Sachin Patel <[EMAIL PROTECTED]> wrote: I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote: I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got:Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91)Where should I put the element?
Re: How to use discouragedRuntimeAccess extension point
Thanks. I put my extension element in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\plugin.xml. I got not .log errors, but I also did not get any access rules added to the selected jars in my build path, and my use of classes from a restricted jar was not flagged. Does path accept a .jar file, or directory only? Here is my extension element: Thanks. On 2/28/06, Sachin Patel <[EMAIL PROTECTED]> wrote: I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . This particular article may be outdated since the move to OSGI but the concepts are the same. Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote: I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got: Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91) Where should I put the element?
Re: How to use discouragedRuntimeAccess extension point
I think its best if you first need to get an understanding of the eclipse plugin architecture. Please read this article... http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html. This particular article may be outdated since the move to OSGI but the concepts are the same.Extension points are defined and loaded inside a plugin.xml. The .serverdef file is a WTP specific file for defining generic servers. Its loaded via an EMF model and thus by adding your entry there invalidates your file and thats why you're seeing the exception. - sachin On Feb 28, 2006, at 5:22 PM, Ted Kirby wrote:I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got:Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91)Where should I put the element?
How to use discouragedRuntimeAccess extension point
I want to use this new support. I put point="org.apache.geronimo.devtools.eclipse.core.discouragedRuntimeAccess" > value="/lib" /> in devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.devtools.eclipse.core\serverdef\geronimo10.serverdef, but it did not work. From the eclipse log, I got: Wrapped exceptionorg.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'extension' not found. (bundleentry://341/serverdef/geronimo10.serverdef, 102, 91) Where should I put the element?
