• Bug
  • Status: Closed
  • 1 Critical
  • Resolution: Fixed
  • amiller
  • Reporter: tgautier
  • March 27, 2008
  • 0
  • Watchers: 0
  • May 01, 2008
  • April 29, 2008

Attachments

Description

I suspected that the following:

file:///./lib

Would specify the lib directory in the current directory for repos, however this gets converted into /lib

Comments

Alex Miller 2008-03-27

It’s not valid (AFAIK) to use relative paths in URIs. Relative URIs are typically formed by combining a base URI (not sure what that would be in our case - could be current directory or tc install but we would need to specify) with a path. The example above is a bastard hybrid of those. :)

For probably no really good reason the only thing that works here now is a valid absolute file URL. If you want to jettison the idea of supporting an arbitrary URL (not just file://), then you could switch to a file path and get what you want.

I think there is real potential value in supporting non-file urls so someone could load a TIM direct from our forge or elsewhere. So, another alternative would be to support a variable substitution for the install directory in the file url which would cover the case above.

And another option would be to support both URL and file path in which case you could instead say just “./lib”.

I think I’d vote for the last.

Fiona OShea 2008-03-28

Taylor sending email to tc-dev to get feedback on changing repo spec to file path

Fiona OShea 2008-04-08

Add support for relative paths (relative to working process)

Deprecate file URL – in 2.6.1 we will remove support for file URL

Alex Miller 2008-04-11

Changed tc schema to be xs:string instead of xs:anyURI. Changed Resolver code to take Strings representing either URL or file path (possibly relative) instead of URL. Changed a lot of internal code to use File instead of URLs. Allow URL but state warning saying that URL support is deprecated.

Changed Eclipse plugin to pick, use, and validate Files instead of URLs (but will still work if using tc-config with url from older release).

Changed tcbuild test framework to pass file paths instead of URLs. Changed tc-maven-plugin to work with file paths instead of urls.

Hung Huynh 2008-04-16

I tested with 2.6-stable1, here’s what I had in my tc-config.xml

d:\work\builds\terracotta-2.6-stable1\tools\sessions\configurator-sandbox\mystuff

The client started without any error in console log (which is bad since you don’t know what went wrong), but in the terracotta-client.log, I found this stack trace:

2008-04-16 19:14:35,876 [main] ERROR com.tc.plugins.ModulesLoader - Exception thrown java.net.MalformedURLException: unknown protocol: d at java.net.URL.(URL.java:574) at java.net.URL.(URL.java:464) at java.net.URL.(URL.java:413) at com.tc.bundles.EmbeddedOSGiRuntime$Factory.createOSGiRuntime(EmbeddedOSGiRuntime.java:51) at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:97) at com.tc.object.bytecode.hook.impl.DSOContextImpl.(DSOContextImpl.java:88) at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:540) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:390) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.systemLoaderInitialized(ClassProcessorHelper.java:711) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1327) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1286)

Hung Huynh 2008-04-16

If I use relative path, I got this

  <repository>mystuff</repository>

2008-04-16 19:30:15,948 [main] ERROR com.tc.plugins.ModulesLoader - Exception thrown java.net.MalformedURLException: no protocol: mystuff at java.net.URL.(URL.java:567) at java.net.URL.(URL.java:464) at java.net.URL.(URL.java:413) at com.tc.bundles.EmbeddedOSGiRuntime$Factory.createOSGiRuntime(EmbeddedOSGiRuntime.java:51) at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:97) at com.tc.object.bytecode.hook.impl.DSOContextImpl.(DSOContextImpl.java:88) at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:540) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:390) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.systemLoaderInitialized(ClassProcessorHelper.java:711) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1327) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1286)

Alex Miller 2008-04-27

I made some changes for windows file paths (C:\foo\bar) and relative paths and these cases should be fixed.

Hung Huynh 2008-04-28

tested with 2.6 r8386

To reproduce:

  1. Extracted attached zip to “terracotta-2.6-nightly-rev8386/tools/sessions/configurator-sandbox”
  2. Start Session Configurator:
  3. Add these to tc-config.xml mymodules
  4. Click “Start All”

You’ll see the below exception. It doesn’t even consider the “mymodules” as a choice. I can confirm “configurator-sandbox” is the working directory because that’s the place the logs and statistics got printed out also.

2008-04-28 17:13:34,818 INFO - Terracotta 2.6-nightly-rev8386, as of 20080428-120411 (Revision 8386 by [email protected] from 2.6) 2008-04-28 17:13:35,349 INFO - Configuration loaded from the file at ‘C:\terracotta\builds\terracotta-2.6-nightly-rev8386\tools\sessions\configurator-sandbox\tomcat5.5\tc-config.xml’. 2008-04-28 17:13:35,974 FATAL - Unable to resolve TIM file for tim-ehcache-1.3 version 1.2.0-SNAPSHOT (group-id: org.terracotta.modules)

Attempted to resolve the TIM using the following descriptors:

  groupId: org.terracotta.modules
  name   : tim-ehcache-1.3
  Version: 1.2.0-SNAPSHOT

Expected the TIM’s filename to be:

  tim-ehcache-1.3-1.2.0-SNAPSHOT.jar

Expected these attributes to be in the manifest:

  Bundle-SymbolicName: org.terracotta.modules.tim-ehcache-1.3
  Bundle-Version     : 1.2.0.SNAPSHOT

Searched using the following repositories:

  + C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules

Tried to resolve the jar file using the following paths:

  + C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules\org\terracotta\modules\tim-ehcache-1.3\1.2.0-SNAPSHOT\tim-ehcache-1.3-1.2.0-SNAPSHOT.jar
  + C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules\tim-ehcache-1.3-1.2.0-SNAPSHOT.jar

If the jar file exists and is in one of the paths listed above, make sure that the Bundle-SymbolicName and Bundle-Version attribute in its manifest matches the ones that the resolver expects. 2008-04-28 17:13:35,974 ERROR - Exception thrown com.tc.bundles.exception.MissingBundleException: Unable to resolve TIM file for tim-ehcache-1.3 version 1.2.0-SNAPSHOT (group-id: org.terracotta.modules) at com.tc.bundles.Resolver.resolve(Resolver.java:172) at com.tc.bundles.Resolver.resolve(Resolver.java:191) at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:150) at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:98) at com.tc.object.tools.BootJarTool.(BootJarTool.java:231) at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2525)

Hung Huynh 2008-04-29

I tested relative path with chatter demo and it worked fine. I think the real problem is this issue DEV-1596