You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by je...@Guardian.com on 2003/10/30 22:48:42 UTC
Unable to locate .VM files in Jar (Velocity 1.3.1)
I have a project setup in JBuilder With a structure that looks something
like this:
com.company.tool.generator
-contains class files
com.company.tool.generator.templates
-contains all the .VM Files
com.company.tool.generator.properties
-contains properties files
I create a runnable jar by including the above, plus the entire velocity
package (with dependencies).
However,
The program is unable to locate the .VM Files.
I've tried varies setting for the resource loader - including the
following:
resource.loader=classpath, file,jar
classpath.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
file.resource.loader.class=org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path=./templates, templates, /templates,
/com/company/tool/generator/templates
jar.resource.loader.class=org.apache.velocity.runtime.resource.loader.JarResourceLoader
jar.resource.loader.path=jar:file:templates.jar
templates.jar was another attempt - but the VM files are located in the
com/company/tool/generator/templates path - so Velocity is unable to find
them.
It seems the only way I can get to my Template (VM) files is if I move them
out of the jar where the 'file' resource can see them, or put them in the
root of my jar - which is really messy.
Could the jar resource loader be extended so something like this:
jar.resource.loader.path=jar:file:templates.jar/com/company/tool/generator/templates
could happen?
or is there another way to accomplish what I'm looking for?
Thank you,
JoeE
This communication may contain information that is legally privileged, confidential, or exempt from disclosure. If you are not the intended recipient, please note that any dissemination, distribution, or copying is strictly prohibited. If you have received this message in error please notify the sender by telephone, fax, or return email and delete this message from your computer. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by Charles Oliver Nutter <he...@headius.com>.
On second read I see the problem...the context classloader always
returns something, but if the thread creator doesn't change it, it's not
the correct one.
Yeah, I'd think this is definitely not correct behavior...if you're
creating/managing threads that have specially configured classloaders,
you should be setting context classloaders for them...
The ClasspathResourceLoader could try both classloaders, as a short-term
measure...
- Charlie
Geir Magnusson Jr. wrote:
>
> On Friday, October 31, 2003, at 05:30 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Thursday, October 30, 2003, at 08:14 PM, Charles Oliver Nutter wrote:
>>
>>> Let me know if you need any help!
>>>
>>> Seriously though, it wouldn't be a bad idea to put this in place
>>> wherever ClassLoader is used; for example, in locating
>>> ResourceLoader instances. As it is, I created my own
>>> ThreadContextResourceLoader so I could load from a jar in an EJB
>>> container...but I had to put that classloader in a jar at the same
>>> level as the Velocity jar (system-wide). An app should be able to
>>> configure resource loaders that might only exist in its context
>>> classloader.
>>>
>>> I'm sure there's other places also.
>>
>>
>> You're exactly right. It's a simple change so we can see where else
>> we have it.
>>
>> It did break a texen test case, so I'm chasing that down now.
>> Started last night, but decided it was time to carve pumpkins for my
>> 5 month old. I had fun - seems like at that age, it's mostly for the
>> parents. She didn't give a hoot, other than trying to lick one. I
>> guess a big orange vegetable is good for that at that age.
>>
>
> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>
> so Thread.currentThread().getContextClassloader()
>
> return the primordial classloader, which of course, doesn't have the
> classpath that you set in the ant build script. I you use the canonical
>
> this.getClass().getClassloader()
>
> you get the ant classloader, which has your classpath.
>
> I'm asking the ant crew about what to do.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Friday, October 31, 2003, at 11:06 AM, Charles Oliver Nutter wrote:
> I suppose it could fall back on the getClass classloader if no context
> classloader is available. It probably makes sense that environments
> that don't manage classloader partitioning might not set the context
> classloader...although I'm sure applications servers do--no way to
> handle partitioning without it.
If that was the case, I'd do that. The problem is that it's not
yes-or-no. if no thread in the chain since the primordial thread sets
a context classloader, you get the classloader of the primordial
thread...
We could probably do a check looking for the primoridal loader and make
a decision then, but this really is kinda yecchy.
>
> You'd think it would be a simple add for Ant to set one, also. It does
> have a couple levels of classloading, last I checked, and it probably
> should be providing a context classloader the its threads...
They did it in 1.6
>
> - Charlie
>
> Geir Magnusson Jr. wrote:
>
>>
>> On Friday, October 31, 2003, at 05:30 AM, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Thursday, October 30, 2003, at 08:14 PM, Charles Oliver Nutter
>>> wrote:
>>>
>>>> Let me know if you need any help!
>>>>
>>>> Seriously though, it wouldn't be a bad idea to put this in place
>>>> wherever ClassLoader is used; for example, in locating
>>>> ResourceLoader instances. As it is, I created my own
>>>> ThreadContextResourceLoader so I could load from a jar in an EJB
>>>> container...but I had to put that classloader in a jar at the same
>>>> level as the Velocity jar (system-wide). An app should be able to
>>>> configure resource loaders that might only exist in its context
>>>> classloader.
>>>>
>>>> I'm sure there's other places also.
>>>
>>>
>>> You're exactly right. It's a simple change so we can see where else
>>> we have it.
>>>
>>> It did break a texen test case, so I'm chasing that down now.
>>> Started last night, but decided it was time to carve pumpkins for my
>>> 5 month old. I had fun - seems like at that age, it's mostly for
>>> the parents. She didn't give a hoot, other than trying to lick one.
>>> I guess a big orange vegetable is good for that at that age.
>>>
>>
>> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>>
>> so Thread.currentThread().getContextClassloader()
>>
>> return the primordial classloader, which of course, doesn't have the
>> classpath that you set in the ant build script. I you use the
>> canonical
>>
>> this.getClass().getClassloader()
>>
>> you get the ant classloader, which has your classpath.
>>
>> I'm asking the ant crew about what to do.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by Charles Oliver Nutter <he...@headius.com>.
I suppose it could fall back on the getClass classloader if no context
classloader is available. It probably makes sense that environments that
don't manage classloader partitioning might not set the context
classloader...although I'm sure applications servers do--no way to
handle partitioning without it.
You'd think it would be a simple add for Ant to set one, also. It does
have a couple levels of classloading, last I checked, and it probably
should be providing a context classloader the its threads...
- Charlie
Geir Magnusson Jr. wrote:
>
> On Friday, October 31, 2003, at 05:30 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Thursday, October 30, 2003, at 08:14 PM, Charles Oliver Nutter wrote:
>>
>>> Let me know if you need any help!
>>>
>>> Seriously though, it wouldn't be a bad idea to put this in place
>>> wherever ClassLoader is used; for example, in locating
>>> ResourceLoader instances. As it is, I created my own
>>> ThreadContextResourceLoader so I could load from a jar in an EJB
>>> container...but I had to put that classloader in a jar at the same
>>> level as the Velocity jar (system-wide). An app should be able to
>>> configure resource loaders that might only exist in its context
>>> classloader.
>>>
>>> I'm sure there's other places also.
>>
>>
>> You're exactly right. It's a simple change so we can see where else
>> we have it.
>>
>> It did break a texen test case, so I'm chasing that down now.
>> Started last night, but decided it was time to carve pumpkins for my
>> 5 month old. I had fun - seems like at that age, it's mostly for the
>> parents. She didn't give a hoot, other than trying to lick one. I
>> guess a big orange vegetable is good for that at that age.
>>
>
> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>
> so Thread.currentThread().getContextClassloader()
>
> return the primordial classloader, which of course, doesn't have the
> classpath that you set in the ant build script. I you use the canonical
>
> this.getClass().getClassloader()
>
> you get the ant classloader, which has your classpath.
>
> I'm asking the ant crew about what to do.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Friday, October 31, 2003, at 12:02 PM, Charles Oliver Nutter wrote:
> I like option 3: use both classloaders. If all is done like it should
> be, the context classloader will get the resource just fine. That
> ought to cover most cases. If it fails, we can fall back to the old
> method.
What I don't like about this is that you could be getting data
incorrectly, because not finding the data in the context classloader
might be *right*. I.e. when you deployed the app, you didn't include
that resource for some reason, and thus getting from some other
classloader violates your intent in deployment.
>
> I agree, I'd rather not have another resource loader...just imagine
> the questions on the list about which ClasspathResourceLoader to use.
> Plus, unless people understand thread-context class loaders, they'll
> still use the old one and have it not work.
>
> If we must create a new one, I'd say "ThreadContextResourceLoader" is
> about as clear as can be.
Yes, that's a good idea.
>
> - Charlie
>
> Geir Magnusson Jr. wrote:
>
>>
>> On Friday, October 31, 2003, at 09:44 AM, Geir Magnusson Jr. wrote:
>>
>>> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>>>
>>> so Thread.currentThread().getContextClassloader()
>>>
>>> return the primordial classloader, which of course, doesn't have the
>>> classpath that you set in the ant build script. I you use the
>>> canonical
>>>
>>> this.getClass().getClassloader()
>>>
>>> you get the ant classloader, which has your classpath.
>>>
>>> I'm asking the ant crew about what to do.
>>
>>
>> I talked to the ant team, and this is fixed in ant 1.6. What this
>> means is
>>
>> a) if we make this change, we need to use ant 1.6 to test with and we
>> run a significant risk of breaking other things where [strange, IMO]
>> things are done with the classloader. I don't like either of those.
>> I was darn happy w/ ant 1.4, and we don't want to break things.
>>
>> or
>>
>> b) We add a new class, ContextClasspathResourceLoader
>>
>> As much as I *hate* adding a new loader, it's the only way I can
>> imagine that we do this w/o breaking someone, and quite frankly,
>> classloader bugs are amazingly hard to track down sometimes..
>>
>> geir
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by Charles Oliver Nutter <he...@headius.com>.
I like option 3: use both classloaders. If all is done like it should
be, the context classloader will get the resource just fine. That ought
to cover most cases. If it fails, we can fall back to the old method.
I agree, I'd rather not have another resource loader...just imagine the
questions on the list about which ClasspathResourceLoader to use. Plus,
unless people understand thread-context class loaders, they'll still use
the old one and have it not work.
If we must create a new one, I'd say "ThreadContextResourceLoader" is
about as clear as can be.
- Charlie
Geir Magnusson Jr. wrote:
>
> On Friday, October 31, 2003, at 09:44 AM, Geir Magnusson Jr. wrote:
>
>> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>>
>> so Thread.currentThread().getContextClassloader()
>>
>> return the primordial classloader, which of course, doesn't have the
>> classpath that you set in the ant build script. I you use the canonical
>>
>> this.getClass().getClassloader()
>>
>> you get the ant classloader, which has your classpath.
>>
>> I'm asking the ant crew about what to do.
>
>
> I talked to the ant team, and this is fixed in ant 1.6. What this
> means is
>
> a) if we make this change, we need to use ant 1.6 to test with and we
> run a significant risk of breaking other things where [strange, IMO]
> things are done with the classloader. I don't like either of those.
> I was darn happy w/ ant 1.4, and we don't want to break things.
>
> or
>
> b) We add a new class, ContextClasspathResourceLoader
>
> As much as I *hate* adding a new loader, it's the only way I can
> imagine that we do this w/o breaking someone, and quite frankly,
> classloader bugs are amazingly hard to track down sometimes..
>
> geir
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Friday, October 31, 2003, at 09:44 AM, Geir Magnusson Jr. wrote:
> Hoo boy. Here's the beef. Ant doesn't set the context classloader
>
> so Thread.currentThread().getContextClassloader()
>
> return the primordial classloader, which of course, doesn't have the
> classpath that you set in the ant build script. I you use the
> canonical
>
> this.getClass().getClassloader()
>
> you get the ant classloader, which has your classpath.
>
> I'm asking the ant crew about what to do.
I talked to the ant team, and this is fixed in ant 1.6. What this
means is
a) if we make this change, we need to use ant 1.6 to test with and we
run a significant risk of breaking other things where [strange, IMO]
things are done with the classloader. I don't like either of those. I
was darn happy w/ ant 1.4, and we don't want to break things.
or
b) We add a new class, ContextClasspathResourceLoader
As much as I *hate* adding a new loader, it's the only way I can
imagine that we do this w/o breaking someone, and quite frankly,
classloader bugs are amazingly hard to track down sometimes..
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Friday, October 31, 2003, at 05:30 AM, Geir Magnusson Jr. wrote:
>
> On Thursday, October 30, 2003, at 08:14 PM, Charles Oliver Nutter
> wrote:
>
>> Let me know if you need any help!
>>
>> Seriously though, it wouldn't be a bad idea to put this in place
>> wherever ClassLoader is used; for example, in locating ResourceLoader
>> instances. As it is, I created my own ThreadContextResourceLoader so
>> I could load from a jar in an EJB container...but I had to put that
>> classloader in a jar at the same level as the Velocity jar
>> (system-wide). An app should be able to configure resource loaders
>> that might only exist in its context classloader.
>>
>> I'm sure there's other places also.
>
> You're exactly right. It's a simple change so we can see where else
> we have it.
>
> It did break a texen test case, so I'm chasing that down now. Started
> last night, but decided it was time to carve pumpkins for my 5 month
> old. I had fun - seems like at that age, it's mostly for the parents.
> She didn't give a hoot, other than trying to lick one. I guess a big
> orange vegetable is good for that at that age.
>
Hoo boy. Here's the beef. Ant doesn't set the context classloader
so Thread.currentThread().getContextClassloader()
return the primordial classloader, which of course, doesn't have the
classpath that you set in the ant build script. I you use the canonical
this.getClass().getClassloader()
you get the ant classloader, which has your classpath.
I'm asking the ant crew about what to do.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, October 30, 2003, at 08:14 PM, Charles Oliver Nutter wrote:
> Let me know if you need any help!
>
> Seriously though, it wouldn't be a bad idea to put this in place
> wherever ClassLoader is used; for example, in locating ResourceLoader
> instances. As it is, I created my own ThreadContextResourceLoader so I
> could load from a jar in an EJB container...but I had to put that
> classloader in a jar at the same level as the Velocity jar
> (system-wide). An app should be able to configure resource loaders
> that might only exist in its context classloader.
>
> I'm sure there's other places also.
You're exactly right. It's a simple change so we can see where else we
have it.
It did break a texen test case, so I'm chasing that down now. Started
last night, but decided it was time to carve pumpkins for my 5 month
old. I had fun - seems like at that age, it's mostly for the parents.
She didn't give a hoot, other than trying to lick one. I guess a big
orange vegetable is good for that at that age.
geir
>
> - Charlie
>
> Geir Magnusson Jr. wrote:
>
>> I'm going to fix that right now. Been meaning to. it seems like the
>> right thing to do, and I can't think of a reason why not.
>>
>> geir
>>
>> On Thursday, October 30, 2003, at 05:03 PM, Charles Oliver Nutter
>> wrote:
>>
>>> 1. Specify the full path to the template. If it's contained within a
>>> jar in the path my/path/to/template, you'd prepend that path to the
>>> name of the template file.
>>> 2. If you are loading Velocity in one classloader (like at the
>>> system level) and trying to access the template within another
>>> classloader (like at the EJB container level) you'll need to
>>> implement your own ClasspathResourceLoader that uses
>>> Thread.currentThread().getContextClassLoader() instead of
>>> getClass().getClassLoader(). There's a bug on this at
>>>
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>>>
>>> - Charlie
>>>
>>> jenfield@Guardian.com wrote:
>>>
>>>> I have a project setup in JBuilder With a structure that looks
>>>> something
>>>> like this:
>>>>
>>>> com.company.tool.generator
>>>> -contains class files
>>>> com.company.tool.generator.templates
>>>> -contains all the .VM Files
>>>> com.company.tool.generator.properties
>>>> -contains properties files
>>>>
>>>> I create a runnable jar by including the above, plus the entire
>>>> velocity
>>>> package (with dependencies).
>>>>
>>>> However,
>>>> The program is unable to locate the .VM Files.
>>>>
>>>> I've tried varies setting for the resource loader - including the
>>>> following:
>>>>
>>>> resource.loader=classpath, file,jar
>>>> classpath.resource.loader.class=org.apache.velocity.runtime.resource
>>>> .l oader.ClasspathResourceLoader
>>>> file.resource.loader.class=org.apache.velocity.runtime.resource.load
>>>> er .FileResourceLoader
>>>> file.resource.loader.path=./templates, templates, /templates,
>>>> /com/company/tool/generator/templates
>>>> jar.resource.loader.class=org.apache.velocity.runtime.resource.loade
>>>> r. JarResourceLoader
>>>> jar.resource.loader.path=jar:file:templates.jar
>>>>
>>>> templates.jar was another attempt - but the VM files are located in
>>>> the
>>>> com/company/tool/generator/templates path - so Velocity is unable
>>>> to find
>>>> them.
>>>>
>>>> It seems the only way I can get to my Template (VM) files is if I
>>>> move them
>>>> out of the jar where the 'file' resource can see them, or put them
>>>> in the
>>>> root of my jar - which is really messy.
>>>>
>>>> Could the jar resource loader be extended so something like this:
>>>> jar.resource.loader.path=jar:file:templates.jar/com/company/tool/
>>>> generator/templates
>>>> could happen?
>>>>
>>>> or is there another way to accomplish what I'm looking for?
>>>>
>>>> Thank you,
>>>> JoeE
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This communication may contain information that is legally
>>>> privileged, confidential, or exempt from disclosure. If you are
>>>> not the intended recipient, please note that any dissemination,
>>>> distribution, or copying is strictly prohibited. If you have
>>>> received this message in error please notify the sender by
>>>> telephone, fax, or return email and delete this message from your
>>>> computer. Thank you.
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> velocity-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> velocity-user-help@jakarta.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by Charles Oliver Nutter <he...@headius.com>.
Let me know if you need any help!
Seriously though, it wouldn't be a bad idea to put this in place
wherever ClassLoader is used; for example, in locating ResourceLoader
instances. As it is, I created my own ThreadContextResourceLoader so I
could load from a jar in an EJB container...but I had to put that
classloader in a jar at the same level as the Velocity jar
(system-wide). An app should be able to configure resource loaders that
might only exist in its context classloader.
I'm sure there's other places also.
- Charlie
Geir Magnusson Jr. wrote:
> I'm going to fix that right now. Been meaning to. it seems like the
> right thing to do, and I can't think of a reason why not.
>
> geir
>
> On Thursday, October 30, 2003, at 05:03 PM, Charles Oliver Nutter wrote:
>
>> 1. Specify the full path to the template. If it's contained within a
>> jar in the path my/path/to/template, you'd prepend that path to the
>> name of the template file.
>> 2. If you are loading Velocity in one classloader (like at the
>> system level) and trying to access the template within another
>> classloader (like at the EJB container level) you'll need to
>> implement your own ClasspathResourceLoader that uses
>> Thread.currentThread().getContextClassLoader() instead of
>> getClass().getClassLoader(). There's a bug on this at
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>>
>> - Charlie
>>
>> jenfield@Guardian.com wrote:
>>
>>> I have a project setup in JBuilder With a structure that looks
>>> something
>>> like this:
>>>
>>> com.company.tool.generator
>>> -contains class files
>>> com.company.tool.generator.templates
>>> -contains all the .VM Files
>>> com.company.tool.generator.properties
>>> -contains properties files
>>>
>>> I create a runnable jar by including the above, plus the entire
>>> velocity
>>> package (with dependencies).
>>>
>>> However,
>>> The program is unable to locate the .VM Files.
>>>
>>> I've tried varies setting for the resource loader - including the
>>> following:
>>>
>>> resource.loader=classpath, file,jar
>>> classpath.resource.loader.class=org.apache.velocity.runtime.resource.l
>>> oader.ClasspathResourceLoader
>>> file.resource.loader.class=org.apache.velocity.runtime.resource.loader
>>> .FileResourceLoader
>>> file.resource.loader.path=./templates, templates, /templates,
>>> /com/company/tool/generator/templates
>>> jar.resource.loader.class=org.apache.velocity.runtime.resource.loader.
>>> JarResourceLoader
>>> jar.resource.loader.path=jar:file:templates.jar
>>>
>>> templates.jar was another attempt - but the VM files are located in
>>> the
>>> com/company/tool/generator/templates path - so Velocity is unable
>>> to find
>>> them.
>>>
>>> It seems the only way I can get to my Template (VM) files is if I
>>> move them
>>> out of the jar where the 'file' resource can see them, or put them
>>> in the
>>> root of my jar - which is really messy.
>>>
>>> Could the jar resource loader be extended so something like this:
>>> jar.resource.loader.path=jar:file:templates.jar/com/company/tool/
>>> generator/templates
>>> could happen?
>>>
>>> or is there another way to accomplish what I'm looking for?
>>>
>>> Thank you,
>>> JoeE
>>>
>>>
>>>
>>>
>>>
>>> This communication may contain information that is legally
>>> privileged, confidential, or exempt from disclosure. If you are
>>> not the intended recipient, please note that any dissemination,
>>> distribution, or copying is strictly prohibited. If you have
>>> received this message in error please notify the sender by
>>> telephone, fax, or return email and delete this message from your
>>> computer. Thank you.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I'm going to fix that right now. Been meaning to. it seems like the
right thing to do, and I can't think of a reason why not.
geir
On Thursday, October 30, 2003, at 05:03 PM, Charles Oliver Nutter wrote:
> 1. Specify the full path to the template. If it's contained within a
> jar in the path my/path/to/template, you'd prepend that path to the
> name of the template file.
> 2. If you are loading Velocity in one classloader (like at the system
> level) and trying to access the template within another classloader
> (like at the EJB container level) you'll need to implement your own
> ClasspathResourceLoader that uses
> Thread.currentThread().getContextClassLoader() instead of
> getClass().getClassLoader(). There's a bug on this at
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>
> - Charlie
>
> jenfield@Guardian.com wrote:
>
>> I have a project setup in JBuilder With a structure that looks
>> something
>> like this:
>>
>> com.company.tool.generator
>> -contains class files
>> com.company.tool.generator.templates
>> -contains all the .VM Files
>> com.company.tool.generator.properties
>> -contains properties files
>>
>> I create a runnable jar by including the above, plus the entire
>> velocity
>> package (with dependencies).
>>
>> However,
>> The program is unable to locate the .VM Files.
>>
>> I've tried varies setting for the resource loader - including the
>> following:
>>
>> resource.loader=classpath, file,jar
>> classpath.resource.loader.class=org.apache.velocity.runtime.resource.l
>> oader.ClasspathResourceLoader
>> file.resource.loader.class=org.apache.velocity.runtime.resource.loader
>> .FileResourceLoader
>> file.resource.loader.path=./templates, templates, /templates,
>> /com/company/tool/generator/templates
>> jar.resource.loader.class=org.apache.velocity.runtime.resource.loader.
>> JarResourceLoader
>> jar.resource.loader.path=jar:file:templates.jar
>>
>> templates.jar was another attempt - but the VM files are located in
>> the
>> com/company/tool/generator/templates path - so Velocity is unable to
>> find
>> them.
>>
>> It seems the only way I can get to my Template (VM) files is if I
>> move them
>> out of the jar where the 'file' resource can see them, or put them in
>> the
>> root of my jar - which is really messy.
>>
>> Could the jar resource loader be extended so something like this:
>> jar.resource.loader.path=jar:file:templates.jar/com/company/tool/
>> generator/templates
>> could happen?
>>
>> or is there another way to accomplish what I'm looking for?
>>
>> Thank you,
>> JoeE
>>
>>
>>
>>
>>
>> This communication may contain information that is legally
>> privileged, confidential, or exempt from disclosure. If you are not
>> the intended recipient, please note that any dissemination,
>> distribution, or copying is strictly prohibited. If you have
>> received this message in error please notify the sender by telephone,
>> fax, or return email and delete this message from your computer.
>> Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Unable to locate .VM files in Jar (Velocity 1.3.1)
Posted by Charles Oliver Nutter <he...@headius.com>.
1. Specify the full path to the template. If it's contained within a jar
in the path my/path/to/template, you'd prepend that path to the name of
the template file.
2. If you are loading Velocity in one classloader (like at the system
level) and trying to access the template within another classloader
(like at the EJB container level) you'll need to implement your own
ClasspathResourceLoader that uses
Thread.currentThread().getContextClassLoader() instead of
getClass().getClassLoader(). There's a bug on this at
http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
- Charlie
jenfield@Guardian.com wrote:
>I have a project setup in JBuilder With a structure that looks something
>like this:
>
>com.company.tool.generator
> -contains class files
>com.company.tool.generator.templates
> -contains all the .VM Files
>com.company.tool.generator.properties
> -contains properties files
>
>I create a runnable jar by including the above, plus the entire velocity
>package (with dependencies).
>
>However,
>The program is unable to locate the .VM Files.
>
>I've tried varies setting for the resource loader - including the
>following:
>
>resource.loader=classpath, file,jar
>classpath.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
>file.resource.loader.class=org.apache.velocity.runtime.resource.loader.FileResourceLoader
>file.resource.loader.path=./templates, templates, /templates,
>/com/company/tool/generator/templates
>jar.resource.loader.class=org.apache.velocity.runtime.resource.loader.JarResourceLoader
>jar.resource.loader.path=jar:file:templates.jar
>
>templates.jar was another attempt - but the VM files are located in the
>com/company/tool/generator/templates path - so Velocity is unable to find
>them.
>
>It seems the only way I can get to my Template (VM) files is if I move them
>out of the jar where the 'file' resource can see them, or put them in the
>root of my jar - which is really messy.
>
>Could the jar resource loader be extended so something like this:
>jar.resource.loader.path=jar:file:templates.jar/com/company/tool/generator/templates
>could happen?
>
>or is there another way to accomplish what I'm looking for?
>
>Thank you,
>JoeE
>
>
>
>
>
>This communication may contain information that is legally privileged, confidential, or exempt from disclosure. If you are not the intended recipient, please note that any dissemination, distribution, or copying is strictly prohibited. If you have received this message in error please notify the sender by telephone, fax, or return email and delete this message from your computer. Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org