4:28 a.m.
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
4:46 a.m.
I suppose you could control that from conf/jboss-service.xml?
Still it's a different behavior, as you suggest
<server>
<!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
the shared JBOSS_HOME/common/lib directory. This can be restricted to
specific jars by specifying them in the archives attribute.
TODO: Move this configuration elsewhere
-->
<classpath codebase="${jboss.server.lib.url}"
archives="*"/>
<classpath codebase="${jboss.common.lib.url}"
archives="*"/>
Jaikiran Pai wrote:
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:15 a.m.
Previous VFS2 used JarUtils, which contained known archive suffixes.
If the file didn't match any of those, it was considered plain file (not-archive).
So no zip-handling context was created on top, hence no found inner entries.
New VFS3 has no JarUtils anymore, and it's this code in
VFSClassLoaderClassPathDeployer
if (canSeeParent == false || (canSeeParent &&
parentClassPath.contains(file) == false))
{
try
{
Automounter.mount(unit.getRoot(), file);
}
that mounts your .bak archive -- since "*" was used to filter the contents of
jboss-service'xml' classpath.
Putting "*.jar" there should fix your problem -- dunno if this should be the
proper fix?
On Mar 10, 2010, at 11:46 AM, Dimitris Andreadis wrote:
I suppose you could control that from conf/jboss-service.xml?
Still it's a different behavior, as you suggest
<server>
<!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
the shared JBOSS_HOME/common/lib directory. This can be restricted to
specific jars by specifying them in the archives attribute.
TODO: Move this configuration elsewhere
-->
<classpath codebase="${jboss.server.lib.url}"
archives="*"/>
<classpath codebase="${jboss.common.lib.url}"
archives="*"/>
Jaikiran Pai wrote:
> I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
> VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
> rename existing jar files to end with .bak name and replace them with
> the new patched jar file. So for example, if i had a fix in
> jboss-ejb3-core.jar, i would:
>
> 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
> JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
> 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
> 3) Restart the server
>
> The server would then pickup the new patched jar file and ignore the
> .bak file. After testing the fix, i would then revert back to the
> original jar file by renaming it back to its original name.
>
> However, with the recent upgrade to VFS3 in AS trunk, i notice that even
> the .bak is used for classloading (following is the output from
> -verbose:class JVM argument):
>
> [Loaded org.jboss.ejb3.EJBContainer from
>
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
>
> Looks like VFS3 picks up this non .jar suffix file for classloading. Is
> this expected? Shouldn't it be looking for only .jar files (atleast in
> this context)?
>
>
>
> regards,
> -Jaikiran
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:24 a.m.
Ales Justin wrote:
<snip/>
that mounts your .bak archive -- since "*" was used to filter the contents of
jboss-service'xml' classpath.
Putting "*.jar" there should fix your problem -- dunno if this should be the
proper fix?
Tried that after Dimitris mentioned it. But only a * wildcard is
supported in that attribute. It can't handle *.jar. The alternative is
to explicitly mention the entire list of archives (which isn't
practical). The documentation of "archives" attribute states:
<!-- The archives attribute specifies either the '*' wildcard to
indicate all contents of the
codebase should be included, or a comma seperated list of the jars to
include.
-->
<!ATTLIST classpath archives CDATA #IMPLIED>
regards,
-Jaikiran
On Mar 10, 2010, at 11:46 AM, Dimitris Andreadis wrote:
> I suppose you could control that from conf/jboss-service.xml?
>
> Still it's a different behavior, as you suggest
>
>
> <server>
>
> <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
> the shared JBOSS_HOME/common/lib directory. This can be restricted to
> specific jars by specifying them in the archives attribute.
> TODO: Move this configuration elsewhere
> -->
> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> <classpath codebase="${jboss.common.lib.url}"
archives="*"/>
>
>
> Jaikiran Pai wrote:
>> I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
>> VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
>> rename existing jar files to end with .bak name and replace them with
>> the new patched jar file. So for example, if i had a fix in
>> jboss-ejb3-core.jar, i would:
>>
>> 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
>> JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
>> 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
>> 3) Restart the server
>>
>> The server would then pickup the new patched jar file and ignore the
>> .bak file. After testing the fix, i would then revert back to the
>> original jar file by renaming it back to its original name.
>>
>> However, with the recent upgrade to VFS3 in AS trunk, i notice that even
>> the .bak is used for classloading (following is the output from
>> -verbose:class JVM argument):
>>
>> [Loaded org.jboss.ejb3.EJBContainer from
>>
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
>>
>> Looks like VFS3 picks up this non .jar suffix file for classloading. Is
>> this expected? Shouldn't it be looking for only .jar files (atleast in
>> this context)?
>>
>>
>>
>> regards,
>> -Jaikiran
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:31 a.m.
Ah, yes -- see SARArchiveFilter.
But this can easily be fixed -- we simply write "smarter" SARArchiveFilter.
On Mar 10, 2010, at 12:24 PM, Jaikiran Pai wrote:
Ales Justin wrote:
> <snip/>
>
> that mounts your .bak archive -- since "*" was used to filter the contents
of jboss-service'xml' classpath.
>
> Putting "*.jar" there should fix your problem -- dunno if this should be
the proper fix?
Tried that after Dimitris mentioned it. But only a * wildcard is
supported in that attribute. It can't handle *.jar. The alternative is
to explicitly mention the entire list of archives (which isn't
practical). The documentation of "archives" attribute states:
<!-- The archives attribute specifies either the '*' wildcard to
indicate all contents of the
codebase should be included, or a comma seperated list of the jars to
include.
-->
<!ATTLIST classpath archives CDATA #IMPLIED>
regards,
-Jaikiran
>
> On Mar 10, 2010, at 11:46 AM, Dimitris Andreadis wrote:
>
>> I suppose you could control that from conf/jboss-service.xml?
>>
>> Still it's a different behavior, as you suggest
>>
>>
>> <server>
>>
>> <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory
and
>> the shared JBOSS_HOME/common/lib directory. This can be restricted to
>> specific jars by specifying them in the archives attribute.
>> TODO: Move this configuration elsewhere
>> -->
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.common.lib.url}"
archives="*"/>
>>
>>
>> Jaikiran Pai wrote:
>>> I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
>>> VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
>>> rename existing jar files to end with .bak name and replace them with
>>> the new patched jar file. So for example, if i had a fix in
>>> jboss-ejb3-core.jar, i would:
>>>
>>> 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
>>> JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
>>> 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
>>> 3) Restart the server
>>>
>>> The server would then pickup the new patched jar file and ignore the
>>> .bak file. After testing the fix, i would then revert back to the
>>> original jar file by renaming it back to its original name.
>>>
>>> However, with the recent upgrade to VFS3 in AS trunk, i notice that even
>>> the .bak is used for classloading (following is the output from
>>> -verbose:class JVM argument):
>>>
>>> [Loaded org.jboss.ejb3.EJBContainer from
>>>
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
>>>
>>> Looks like VFS3 picks up this non .jar suffix file for classloading. Is
>>> this expected? Shouldn't it be looking for only .jar files (atleast in
>>> this context)?
>>>
>>>
>>>
>>> regards,
>>> -Jaikiran
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
9 a.m.
The primary reason JarUtils was removed is it didn't seem to have
anything to do with VFS. Most of the usage could be replaced by having
a standard SuffixMatchFilter containing the valid JAR suffixes to use
for matching jars. This is similar to the already existing
SuffixExcludeFilter named JARFilter in deployers.xml. This could then
be injected into whatever components need it in a similar fashion to
JARFilter. If having static access to the filter or the suffixes is
required, then something could get resurrected in deployers, since that
seems to be the most fitting place.
There was some discussion on this -->
http://community.jboss.org/thread/148212
On 3/10/10 5:15 AM, Ales Justin wrote:
Previous VFS2 used JarUtils, which contained known archive suffixes.
If the file didn't match any of those, it was considered plain file (not-archive).
So no zip-handling context was created on top, hence no found inner entries.
New VFS3 has no JarUtils anymore, and it's this code in
VFSClassLoaderClassPathDeployer
if (canSeeParent == false || (canSeeParent&&
parentClassPath.contains(file) == false))
{
try
{
Automounter.mount(unit.getRoot(), file);
}
that mounts your .bak archive -- since "*" was used to filter the contents of
jboss-service'xml' classpath.
Putting "*.jar" there should fix your problem -- dunno if this should be the
proper fix?
On Mar 10, 2010, at 11:46 AM, Dimitris Andreadis wrote:
> I suppose you could control that from conf/jboss-service.xml?
>
> Still it's a different behavior, as you suggest
>
>
> <server>
>
> <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory
and
> the shared JBOSS_HOME/common/lib directory. This can be restricted to
> specific jars by specifying them in the archives attribute.
> TODO: Move this configuration elsewhere
> -->
> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> <classpath codebase="${jboss.common.lib.url}"
archives="*"/>
>
>
> Jaikiran Pai wrote:
>
>> I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
>> VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
>> rename existing jar files to end with .bak name and replace them with
>> the new patched jar file. So for example, if i had a fix in
>> jboss-ejb3-core.jar, i would:
>>
>> 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
>> JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
>> 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
>> 3) Restart the server
>>
>> The server would then pickup the new patched jar file and ignore the
>> .bak file. After testing the fix, i would then revert back to the
>> original jar file by renaming it back to its original name.
>>
>> However, with the recent upgrade to VFS3 in AS trunk, i notice that even
>> the .bak is used for classloading (following is the output from
>> -verbose:class JVM argument):
>>
>> [Loaded org.jboss.ejb3.EJBContainer from
>>
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
>>
>> Looks like VFS3 picks up this non .jar suffix file for classloading. Is
>> this expected? Shouldn't it be looking for only .jar files (atleast in
>> this context)?
>>
>>
>>
>> regards,
>> -Jaikiran
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:06 a.m.
FYI - This behaviour seems to have introduced deployment failures
https://issues.jboss.org/browse/JBAS-8725
-Jaikiran
On Wednesday 10 March 2010 03:58 PM, Jaikiran Pai wrote:
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:52 a.m.
I'm on it.
Would be already done, if it wasn't for the broken trunk build ...
Running org.jboss.jbossas.embedded.testsuite.ServerIntegrationTest
Tests run: 9, Failures: 0, Errors: 8, Skipped: 1, Time elapsed: 36.157 sec <<<
FAILURE!
On Dec 10, 2010, at 11:06 AM, Jaikiran Pai wrote:
FYI - This behaviour seems to have introduced deployment failures
https://issues.jboss.org/browse/JBAS-8725
-Jaikiran
On Wednesday 10 March 2010 03:58 PM, Jaikiran Pai wrote:
> I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
> VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
> rename existing jar files to end with .bak name and replace them with
> the new patched jar file. So for example, if i had a fix in
> jboss-ejb3-core.jar, i would:
>
> 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
> JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
> 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
> 3) Restart the server
>
> The server would then pickup the new patched jar file and ignore the
> .bak file. After testing the fix, i would then revert back to the
> original jar file by renaming it back to its original name.
>
> However, with the recent upgrade to VFS3 in AS trunk, i notice that even
> the .bak is used for classloading (following is the output from
> -verbose:class JVM argument):
>
> [Loaded org.jboss.ejb3.EJBContainer from
>
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
>
> Looks like VFS3 picks up this non .jar suffix file for classloading. Is
> this expected? Shouldn't it be looking for only .jar files (atleast in
> this context)?
>
>
>
> regards,
> -Jaikiran
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5122
days inactive
5397
days old
jboss-development@lists.jboss.org
7 comments
4 participants
participants (4)
-
Ales Justin -
Dimitris Andreadis -
Jaikiran Pai -
John Bailey