This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Recently the improvement was implemented in order to make the server configuration for headless builds simpler (iirc). In this solution the j2ee.server.home is configured to make paths in j2ee.platform.classpath variable based. It does not work for servers with multiple roots, such as for example binaries and domain.
David's comment from issue 189141: I'm not sure what can be done with some paths not being relative - the solution implemented was very simple (without an API contract): as most of the server jars are under server installation directory then let's store server installation directory and use relative paths to access jars. For WL this is not true as some of the jars are outside of server installation directory. Perhaps an API contract might be necessary to give a chance to WL to make paths relative?
(In reply to comment #1) > David's comment from issue 189141: > > I'm not sure what can be done with some paths not being relative - the solution > implemented was very simple (without an API contract): as most of the server > jars are under server installation directory then let's store server > installation directory and use relative paths to access jars. Ok for me. I'm not sure whether we should spend some more time implementing this enhancement. > For WL this is > not true as some of the jars are outside of server installation directory. > Perhaps an API contract might be necessary to give a chance to WL to make paths > relative? Well I think API would not help as there is no guarantee that the paths have common ancestor. In other words server dir, domain dir and (perhaps even) middleware dir can be located on completely different paths. Simple and clear solution would be to map platform roots to multiple j2ee.server.home vars such as j2ee.server.home.1, j2ee.server.home.2 etc. Naming of such props (replacing .2 with .domain) would be better but could significantly increase the complexity and cost of the solution imo with ugly corner cases and only a small benefit for users.
I am not sure how often you have server dir outside of the middleware dir. Would it be good enough to just use middleware dir and relativize classpath against that? This would solve this for the common cases, no?
PetrH, I agree with you.
Considering server sharability it is a defect.
Separate properties for home, domain and middleware: web-main 8f528cc092cb.
Integrated into 'main-golden', will be available in build *201011020000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8f528cc092cb User: Petr Hejl <phejl@netbeans.org> Log: #190387 j2ee.server.home works only for server with single root
Shared server libraries disabled - web-main 3ed8f955f8b9 and 7be1522822a8.
Integrated into 'main-golden', will be available in build *201011030000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3ed8f955f8b9 User: Petr Hejl <phejl@netbeans.org> Log: #190387 j2ee.server.home works only for server with single root - disabling sharable server