1:20 a.m.
[
https://issues.jboss.org/browse/JBIDE-19720?page=com.atlassian.jira.plugi...
]
Viacheslav Kabanovich edited comment on JBIDE-19720 at 5/16/15 2:19 AM:
------------------------------------------------------------------------
Yes, you are right, in the case of JRE only external libraries are allowed (even if they
physically may reside inside the workspace, paths to them should be absolute), so that the
check should be just removed from the code.
Still, the confusion remains for referenced libraries that can be selected both from the
workspace and from the disk.
After consideration I add this:
Suppose, you create in your 'System' project in Eclipse resource
/System/Library/Java/Extensions/MRJToolkit.jar. Make that MRJToolkit.jar not a valid copy,
but just a fake. Suppose, EclipseResourceUtil is fixed and finds the external jar without
exceptions. But what will Eclipse itself resolve for JRE? I have my doubts. Docs to
JavaCore.getResolvedClasspathEntry(IClasspathEntry) describe the algorithm, in which the
priority is given to 'a project, JAR or binary folder in the workspace at the resolved
path location', and only if this fails, 'an external JAR file or folder outside
the workspace at the resolved path location' is tried. Docs say nothing about treating
JRE entries in any different way than other entries. So, even though Eclipse prompts user
to select for JRE libraries external paths, when resolving them it may get stuck with a
fake workspace resource whose workspace path by accident is the same as the external path
of a real JRE library.
After 'a field experiment':
Eclipse indeed resolved JRE to the fake resource inside its workspace, though I added to
JRE in Preferences an external path to the valid library. Oh, boy! Eclipse users should
beware to give same favourite names to both Linux aliases and Eclipse projects.
was (Author: scabanovich):
Yes, you are right, in the case of JRE only external libraries are allowed (even if they
physically may reside inside the workspace, paths to them should be absolute), so that the
check should be just removed from the code.
Still, the confusion remains for referenced libraries that can be selected both from the
workspace and from the disk.
After consideration I add this:
Suppose, you create in your 'System' project in Eclipse resource
/System/Library/Java/Extensions/MRJToolkit.jar. Make that MRJToolkit.jar not a valid copy,
but just a fake. Suppose, EclipseResourceUtil is fixed and finds the external jar without
exceptions. But what will Eclipse itself resolve for JRE? I have my doubts. Docs to
JavaCore.getResolvedClasspathEntry(IClasspathEntry) describe the algorithm, in which the
priority is given to 'a project, JAR or binary folder in the workspace at the resolved
path location', and only if this fails, 'an external JAR file or folder outside
the workspace at the resolved path location' is tried. Docs say nothing about treating
JRE entries in any different way than other entries. So, even though Eclipse prompts user
to select for JRE libraries external paths, when resolving them it may get stuck with a
fake workspace resource whose workspace path by accident is the same as the external path
of a real JRE library.
NPE in
org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
----------------------------------------------------------------------------
Key: JBIDE-19720
URL: https://issues.jboss.org/browse/JBIDE-19720
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common/jst/core
Affects Versions: 4.2.3.Final
Environment: Mac OS X 10.10.3, java full version "1.8.0_25-b17"
Reporter: Valentin Baciu
Assignee: Viacheslav Kabanovich
Priority: Minor
Fix For: 4.3.0.Beta1
java.lang.NullPointerException
at
org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
at
org.jboss.tools.common.model.util.EclipseResourceUtil.updateLibs(EclipseResourceUtil.java:535)
at
org.jboss.tools.common.model.util.EclipseResourceUtil.createObjectForResource(EclipseResourceUtil.java:417)
at
org.jboss.tools.jst.web.model.helpers.InnerModelHelper.createXModel(InnerModelHelper.java:40)
at
org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.init(ClassPathMonitor.java:60)
at org.jboss.tools.jst.web.kb.internal.KbProject.setProject(KbProject.java:202)
at
org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:71)
at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:38)
at
org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.getKbProjects(ClassPathMonitor.java:193)
at
org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:143)
at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
at org.jboss.tools.jst.web.kb.internal.KbProject.resolve(KbProject.java:330)
at org.jboss.tools.jst.web.kb.internal.KbProject.addKbProject(KbProject.java:216)
at
org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:154)
at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
at org.jboss.tools.jst.web.kb.internal.KbBuilder.build(KbBuilder.java:100)
at
org.jboss.tools.jst.web.kb.KbProjectFactory$1KbBuilderEx.build(KbProjectFactory.java:107)
at org.jboss.tools.jst.web.kb.KbProjectFactory$1.run(KbProjectFactory.java:122)
at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Another code path:
java.lang.NullPointerException
at
org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
at
org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.update(AbstractClassPathMonitor.java:73)
at
org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.build(JSF2ProjectBuilder.java:116)
at
org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.<init>(JSF2ProjectBuilder.java:71)
at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.load(JSF2Project.java:261)
at
org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolveStorage(JSF2Project.java:247)
at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolve(JSF2Project.java:254)
at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project$1.run(JSF2Project.java:172)
at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)