I'll check that later. Didn't find a easy way.
what I don't understand if this :
OK
//WarDeploymentConfiguration config = new WarDeploymentConfiguration(ctx,
loaderEntry.getValue(), defaultWebApp);
BAD
WarDeploymentConfiguration config = new
WarDeploymentConfiguration(ctx, serverLibLoader, defaultWebApp);
is what is different between the both classloader ?
theses 2 lines will execute the same code but it look like the problem is
the ClassLoader created before theses calls.
2009/11/9 Survivant 00 <survivant00_at_gmail.com>
> thanks.
>
> I'll generate a jar file for the guy so I can continue to use Grizzly. and
> take more time to do it correctly.
>
>
>
> 2009/11/9 Hubert Iwaniuk <neotyk_at_kungfoo.pl>
>
> I couldn't find time to fix it, and see that user is asking for it, so
>> Sebastien if you have free cycle please help.
>> General idea I've had for this fix was:
>> 1. in WarDeployer modify fromURI method to call createWarCLJarBased to
>> create warCL
>> 2. add method createWarCLJarBased similar to createWarCL only making sure
>> that we choose jar:file protocol over file: protocol if we can.
>>
>> That is based on observation that both classpaths differ only in protocol
>> part for / and /WEB-INF/classes
>>
>> Though I'm not sure any more about it, as I failed to create a test case
>> that would isolate this issue.
>>
>> HTH,
>> Hubert.
>>
>>
>>
>> On Thu, Nov 5, 2009 at 11:48 PM, Survivant 00 <survivant00_at_gmail.com>wrote:
>>
>>> thanks.
>>>
>>> I'll provide backup if you need. and do regression test on my side after
>>> we patch it.
>>>
>>>
>>>
>>> 2009/11/5 Hubert Iwaniuk <neotyk_at_kungfoo.pl>
>>>
>>>> First look at classloaders produced by old and new approach shows
>>>> following differences:
>>>> war contents in old is referenced vis jar:file: protocol while with new
>>>> one via file: protocol to exploded location.
>>>> Same stands for WEB-INF/classes.
>>>> So it should not produce any difference, but apparently it somehow does.
>>>> I'll try looking into it a bit more.
>>>>
>>>> Cheers,
>>>> Hubert
>>>>
>>>>
>>>>
>>>> On Thu, Nov 5, 2009 at 8:27 PM, Survivant 00 <survivant00_at_gmail.com>wrote:
>>>>
>>>>> I couldn't wait until tonight.
>>>>>
>>>>> I been able to make it works, but I had to change a little code. (now
>>>>> I'm pretty sure that something missing in the ClassLoader).
>>>>>
>>>>> here what I changed : (call the older classloader instead for this
>>>>> test)
>>>>>
>>>>> public void deployWar(
>>>>> String location, String context, URLClassLoader
>>>>> serverLibLoader, WebApp defaultWebApp) throws DeployException {
>>>>> String ctx = context;
>>>>> if (ctx == null) {
>>>>> ctx = getContext(location);
>>>>> int i = ctx.lastIndexOf('.');
>>>>> if (i > 0) {
>>>>> ctx = ctx.substring(0, i);
>>>>> }
>>>>> }
>>>>> Map.Entry<String, URLClassLoader> loaderEntry = null;
>>>>> try {
>>>>> loaderEntry = explodeAndCreateWebAppClassLoader(location,
>>>>> serverLibLoader);
>>>>> } catch(Exception e){
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> WarDeploymentConfiguration config = new
>>>>> WarDeploymentConfiguration(ctx, loaderEntry.getValue(), defaultWebApp);
>>>>> if (logger.isLoggable(Level.FINER)) {
>>>>> logger.log(Level.FINER, String.format("Configuration for
>>>>> deployment: %s.", config));
>>>>> }
>>>>> deployer.deploy(ws, new File(location).toURI(), config);
>>>>> }
>>>>>
>>>>>
>>>>> and spring found the files.
>>>>>
>>>>>
>>>>> Do you want me to go deeper ? (into the code :0 )
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
>>> http://twitter.com/survivant
>>>
>>
>>
>
>
> --
>
> Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
> http://twitter.com/survivant
>
--
Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
http://twitter.com/survivant