Bugzilla – Full Text Bug Listing
| Summary: | Document the par.ecore URI change in the Migration wiki | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Leo Dos Santos <leo.dos.santos> |
| Component: | tooling | Assignee: | Leo Dos Santos <leo.dos.santos> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | denis.roy, eclipse, Ed.Merks, jhanna, milesparker, mlippert |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 341911 | ||
|
Description
Leo Dos Santos
I've updated the wiki with install instructions for the snapshot update site, and added an additional note to the migration section documenting this change. > after:
> <org.eclipse.virgo.ide.par:Par xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:org.eclipse.virgo.ide.par="http://eclipse.org/virgo/par.ecore"/>
Is it normal for that file to not exist? It seems to be generating some 404 File Not Found errors in my web logs, and in one specific case, it seems one (or many) user's Eclipse is repeatedly trying to fetch that file.
As far as I know, the par.ecore file (and the URI) are generated from the EMF tooling. Miles is the EMF expert on the team, maybe he can confirm. Should this live on the server? We can provide the par.ecore file if so. Ditto previous comment by Denis, who appears to be an Eclipse webmaster. He just confirmed for us that the Eclipse firewall had blocked our IP address due to repeated automated requests that were destined for this URI. Since his comment is a couple days old, I'm presuming this has happened to other Virgo tooling users. I thought this URI was only supposed to be used for namespace resolution. I wouldn't expect there to be anything at this URI, or for the tooling to try and access it. Is there something in the Virgo tooling that is making explicit HTTP GET requests for this URI to Eclipse? From Denis ---- It seems a computer on your network is requesting the same file repeatedly, in very rapid succession. This is causing our firewalls to trip and block your subnet. The browser signature leads me to believe this is happening from within Eclipse itself. I've traced this back to this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=369458 Below is a small snapshot of the logs from one of our webservers: <my IP address> - - [24/May/2012:11:40:42 -0400] "GET /virgo/par.ecore HTTP/1.1" 404 6623 "-" "Java/1.6.0_30" <my IP address> - - [24/May/2012:11:40:43 -0400] "GET /virgo/par.ecore HTTP/1.1" 404 6623 "-" "Java/1.6.0_30" <my IP address> - - [24/May/2012:11:40:43 -0400] "GET /virgo/par.ecore HTTP/1.1" 404 6623 "-" "Java/1.6.0_30" <my IP address> - - [24/May/2012:11:40:44 -0400] "GET /virgo/par.ecore HTTP/1.1" 404 6623 "-" "Java/1.6.0_30" Hi folks, Normally the way this works is that the namespace resolution is actually delegated to a local resource. So even though we use a "real" URL for the par.ecore URI, that should get resolved without actually going to the internet resource. In fact, people often use nonsense URL for this purpose. OTOH EMF for example uses http://www.eclipse.org/emf/2002/Ecore, which AFAICT doesn't actually exist either. 1. We should probably put the actual schema up where it is being pointed. 2. More importantly we need to figure out why the resolution isn't happening locally. Can you pass along the actual IP to our emails so that we can determine whether this is just a development time issue? Or if you can't do that for privacy reasons or whatever let me know and we'll send you our source IPs so you can check them against what you're seeing. > I'm presuming this has happened to other Virgo > tooling users. I'm seeing many different instances of IP addresses fetching the Virgo "par.ecore" URI in rapid succession, until our firewalls get bored and block the action. (In reply to comment #5) > OTOH EMF for > example uses http://www.eclipse.org/emf/2002/Ecore, which AFAICT doesn't > actually exist either. It doesn't exist, and I just checked our web logs, and the same problem is happening there too -- some IP addresses fetch http://www.eclipse.org/emf/2002/Ecore repeatedly, and quickly, until they are kicked out. To me this indicated a problem deeper into Eclipse, not necessarily with Virgo, but perhaps with ECF and the http provider? I'm just a server monkey so I wouldn't know in which component to report this... (In reply to comment #6) > It doesn't exist, and I just checked our web logs, and the same problem is > happening there too -- some IP addresses fetch > http://www.eclipse.org/emf/2002/Ecore repeatedly, and quickly, until they are > kicked out. > > > To me this indicated a problem deeper into Eclipse, not necessarily with Virgo, > but perhaps with ECF and the http provider? I'm just a server monkey so I > wouldn't know in which component to report this... Yes, if there's a problem of over-eager fetching, then it's likely coming from one of those or even the XML editor framework which unfortunately is out of our (Virgo) hands. > (In reply to comment #5)
> It doesn't exist, and I just checked our web logs, and the same problem is
> happening there too -- some IP addresses fetch
> http://www.eclipse.org/emf/2002/Ecore repeatedly, and quickly, until they are
> kicked out.
>
>
> To me this indicated a problem deeper into Eclipse, not necessarily with Virgo,
> but perhaps with ECF and the http provider? I'm just a server monkey so I
> wouldn't know in which component to report this...
cc'ing Ed M. Maybe he has some thoughts about why the local URI resolution doesn't always work. It's possible that this is coming from people oepning the files in a raw XML editor, e.g. not using the generated EMF editors.
(In reply to comment #8) > cc'ing Ed M. Maybe he has some thoughts about why the local URI resolution > doesn't always work. It's possible that this is coming from people oepning the > files in a raw XML editor, e.g. not using the generated EMF editors. Definitely not caused by explicit user action on my side. My developers aren't working with Eclipse internals, they're simply developing an application with Eclipse/STS for a Virgo Tomcat Server run time. If you look at the frequency of requests, they're rapid fire and repeated. And they seem to be initiated directly from the java process running Eclipse/STS. (In reply to comment #5) > 2. More importantly we need to figure out why the resolution isn't happening > locally. Can you pass along the actual IP to our emails so that we can > determine whether this is just a development time issue? I'll copy the cc: list for this bug via e-mail. I don't mind sharing my IP but would prefer it not be in plain view on the bug report. (I'm just going to reopen this bug to avoid the issue of people having to reassign themselves to another one.) OK, here's the short term solution that should hopefully at least prevent the ban from happening, without requiring a fix/update. (As we can't control people's update sites anyway): I've put the par.ecore at the root of the virgo website, i.e. where the xml namespace definition expects to see it. It will take a while for the change to propagate, but please let us know if that resolves the immediate issue. That leaves the larger issue of what's going on with hitting this url so much in the first place. Obviously we don't want to be spamming the eclipse servers every time someone loads an ecore par file or whatever. But again, this seems that it might be a general issue that simply hasn't been noticed until now (?!). This seems to be something for EMF modeling to perhaps assuming that Denis continues to see an excessive number of hits on that URL. One other thought I had. Jason I suppose it might be possible for some Eclipse proxy configurations to confuse the EMF resolution process. I'm sorry that I can't look into that right now, but it might be worth investigating. Is there a generated EMF Package that has this as its value for eNS_URI? Does its bundle's plugin.xml have a generated_package registration? If you've changed this in the model and regenerated, it's likely the plugin.xml will have the old value (because regeneration doesn't support merging for the MANIFEST.MF and the plugin.xml).
For example, for Ecore itself we have
public interface EcorePackage extends EPackage
{
// ...
String eNS_URI = "http://www.eclipse.org/emf/2002/Ecore";
and
<extension point="org.eclipse.emf.ecore.generated_package">
<package
uri="http://www.eclipse.org/emf/2002/Ecore"
class="org.eclipse.emf.ecore.EcorePackage"
genModel="model/Ecore.genmodel"/>
</extension>
Certainly it's possible that XML tools could try to find an XML schema at this location and EMF, when loading such a file, if it fails to find a registered package, will definitely try to load an Ecore model from that URI.
(In reply to comment #12) > Is there a generated EMF Package that has this as its value for eNS_URI? Does > its bundle's plugin.xml have a generated_package registration? If you've > changed this in the model and regenerated, it's likely the plugin.xml will have > the old value (because regeneration doesn't support merging for the MANIFEST.MF > and the plugin.xml). Yep, we took care of that on change and it was the first thing I checked when Jason reported this issue. /** * The package namespace URI. <!-- begin-user-doc --> <!-- end-user-doc --> * * @generated */ String eNS_URI = "http://eclipse.org/virgo/par.ecore"; <extension point="org.eclipse.emf.ecore.generated_package"> <package uri="http://eclipse.org/virgo/par.ecore" class="org.eclipse.virgo.ide.par.ParPackage" genModel="model/par.genmodel"/> </extension> > Certainly it's possible that XML tools could try to find an XML schema at this > location and EMF, when loading such a file, if it fails to find a registered > package, will definitely try to load an Ecore model from that URI. Yes, I wonder.. perhaps there is some aspect of the tooling that is loading the file as a raw xml file. Obviously there isn't anyway to get a stack trace for the machines attempting to grab that URL so it's a tough one to diagnose, but perhaps we could get to the issue by setting a local proxy listener and triggering a vm wide thread dump when some process tries to reach that URL. What I am *really* wondering about now is why this is apparently happening for Ecore as well. Perhaps Denis could give us a sense for the volume of hits. (And incidentally, wondering why there isn't an actual file provided at http://www.eclipse.org/emf/2002/Ecore"? I always thought there was..) If the problem is happening for Ecore as well, it's not likely to be EMF doing the loading. Ecore will always be registered, even in a stand alone application. I'm pretty sure that any validating SAX parser will attempt to find a schema for the namespace, so any application could cause this type of problem. I know that the W3C gets upset when they get too many hits on their schemas, and in those cases the schemas really are there. They expect clients to redirect to a local copy, like what I do for the XSD model, which relies on the XML Schema for Schemas... I'm going to close bug this because the original issue was resolved. If we still need to follow up on the schema resolution issue please file another bug. |