|
| Re: EPackage Global Registry problems [message #400465 is a reply to message #400463] |
Thu, 20 April 2006 18:09   |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
As I understand it, when running inside Eclipse, the plugin.xml that the
generated code is in uses the extension point
org.eclipse.emf.ecore.generated_package extension point to register the
package with the URI. This puts a "delegate" into the registry and went
the registry looks for the URI it will resolve through the delegate,
finding the real package and putting that in its place and returning it.
The problem is when running outside of Eclipse there is no extension
point to provide this info. So the application has to know ahead of time
what packages can possibly be referenced and should do an
thepackage.EINSTANCE.get...;
Where get... is some valid get method on the package. This will then
cause that package to be registered.
R. Gavlin wrote:
> I have several statically declared EPackages which I am attempting to
> access using EPackage.Registry.INSTANCE.values(). For this particular
> problem, I am unable to locate the EPackages I want using the
> INSTANCE.getEPackage(URI) API.
>
> When running within the same JVM as Eclipse, these statically registered
> EPackages as well as others are returned as expected from
> INSTANCE.values(). Outside of Eclipse and inside my J2EE app server,
> however, this values() method returns nothing. In this case, it appears
> the registry is complicated by Delegates and Classloaders. Is there a
> way running outside Eclipse I can traverse through all the delegates and
> retrieve all the EPackages. Any help would be appreciated?
>
> - Ron
>
--
Thanks,
Rich Kulp
|
|
|
|
|
| Re: EPackage Global Registry problems [message #400468 is a reply to message #400465] |
Thu, 20 April 2006 18:17 |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Rich,
Thanks. Sametime interrupts caused my delayed send. I clearly should
wait longer and questions will answer themselves! ;-)
Rich Kulp wrote:
> As I understand it, when running inside Eclipse, the plugin.xml that
> the generated code is in uses the extension point
> org.eclipse.emf.ecore.generated_package extension point to register
> the package with the URI. This puts a "delegate" into the registry and
> went the registry looks for the URI it will resolve through the
> delegate, finding the real package and putting that in its place and
> returning it.
>
> The problem is when running outside of Eclipse there is no extension
> point to provide this info. So the application has to know ahead of
> time what packages can possibly be referenced and should do an
>
> thepackage.EINSTANCE.get...;
>
> Where get... is some valid get method on the package. This will then
> cause that package to be registered.
>
>
> R. Gavlin wrote:
>> I have several statically declared EPackages which I am attempting to
>> access using EPackage.Registry.INSTANCE.values(). For this particular
>> problem, I am unable to locate the EPackages I want using the
>> INSTANCE.getEPackage(URI) API.
>>
>> When running within the same JVM as Eclipse, these statically
>> registered EPackages as well as others are returned as expected from
>> INSTANCE.values(). Outside of Eclipse and inside my J2EE app server,
>> however, this values() method returns nothing. In this case, it
>> appears the registry is complicated by Delegates and Classloaders. Is
>> there a way running outside Eclipse I can traverse through all the
>> delegates and retrieve all the EPackages. Any help would be appreciated?
>>
>> - Ron
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EPackage Global Registry problems [message #400469 is a reply to message #400467] |
Thu, 20 April 2006 18:29 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Ron,
With the class loader scoped registry, the values() or getEPackage
results you see will depend on the current thread's class loader. This
scoping mechanism was designed to support the type of visibility that
the class loaders themselves impose and was helpful to WebSphere for
supporting their desired visibility mechanisms. Likely this is the
source of your issues. The getEPackage method will walk up the
delegation chain (which mirrors the class loader hierarchy) to find the
package, but the values() method will just return the values in the
local registry(). The registry was never intended for folks to try to
enumerate all possible packages so I'm curious what you are trying to
achieve? Changing the current thread's class loader to be the parent,
and then the parent of the parent, and so on, calling values() each time
while walking all the way to the root is the only way you can find all
the packages currently visible in the starting scope.
R. Gavlin wrote:
> Yes, I am already invoking xxxPackageImpl.eINSTANCE.eClass() to get
> the static EPackages registered. Sometime later in the lifecycle of my
> application, I need to interrogate all the registered EPackages. I am
> attempting to use EPackage.Registry.INSTANCE.values() to access the
> EPackages. Unfortunately, this list is empty. However, if I execute
> EPackage.Registry.INSTANCE.getEPackage(uri) for one of my statically
> declared packages, it is returned. I need to list all of them and the
> delegate registries outside of Eclipse appear to be hidden within the
> EPackageRegistryImpl Delegator. Thoughts?
>
> - Ron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: EPackage Global Registry problems [message #400471 is a reply to message #400470] |
Thu, 20 April 2006 18:34 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Ron,
Yes, as I said in my other note the Delegator implementation was
designed to support visibility based on class loader scope. I've begun
to regret that we provided that directly rather than insisting that
clients provide that themselves, if and when they want it. Since a
"normal runtime environment" doesn't have such nested class loaders,
it's typically not an issue either way, until a funky environment full
of nested class loaders comes into play...
R. Gavlin wrote:
> FYI, when I am running my application outside Eclipse and set the
> System Property "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE =
> org.eclipse.emf.ecore.impl.EPackageRegistryImpl" on my appserver
> command line, EPackage.Registry.INSTANCE.values() returns the
> EPackages as expected. However, I'm not sure this is a good thing to
> do. Obviously, the Delegator/Classloader stuff in EPackageRegistryImpl
> exists for a good reason and this technique bypasses those mechanisms.
> Any thoughts?
>
> - Ron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EPackage Global Registry problems [message #400473 is a reply to message #400465] |
Thu, 20 April 2006 18:36 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Only when running outside of Eclipse:
The global registry is replaced with a Delegator registry. This is
because you don't want a global registry for the entire VM when working
with J2EE. Instead it needs to be per-class loader because each
application will get its own classloader, even though it is in the same
JVM as other applications. This prevents one application's packages from
contaminating another application.
It uses the thread's context classloader (this is what many servers use
to maintain this separation). EMF maintains a registry per context
classloader.
Now as mentioned previously there are no default registrations when
running outside of Eclipse. So you can either do the calls to load,
activate, and register every package, or you can create a descriptor for
the packages that could possibly be referenced.
A descriptor is an implementation of EPackage.Descriptor. You would
implement the getEPackage and getEFactory methods. That way it would not
actually load and instantiate the package until referenced. You would
put this descriptor into the registry instead. For example:
EPackage.Registry.INSTANCE.put(MyPackage.eNS_URI, new
EPackage.Descriptor() {
public EPackage getEPackage() {
return MyPackage.EINSTANCE;
}
public EFactory getEFactory() {
return MyFactory.EINSTANCE;
}
});
I'm fairly sure this won't force the initialization of the package until
the call to it is made.
--
Thanks,
Rich Kulp
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05033 seconds
] 
Search
Help
Register
Login
Home
