Yeah, the new snapshot only prints once per package requirement now:
| 09:44:08,906 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule
jboss-threads-deployer-classloader:1.0.0.Alpha resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLo
"[EMAIL PROTECTED]" wrote : "[EMAIL PROTECTED]" wrote : I've uploaded a
2.0.2-SNAPSHOT of jboss-cl with a fix for this bug if you want to try it.
|
| It seems to work. In JBossAS minimal configuration, it prints the warning
several times:
|
|
| | 08:37:13,719 WARN [ClassLoadingSp
"[EMAIL PROTECTED]" wrote : I've uploaded a 2.0.2-SNAPSHOT of jboss-cl with a
fix for this bug if you want to try it.
It seems to work. In JBossAS minimal configuration, it prints the warning
several times:
| 08:37:13,719 WARN [ClassLoadingSpace] VFSDeploymentClassLoaderPolicyModule
jboss
"[EMAIL PROTECTED]" wrote : OK, taking this another way - was my solution of
adding the two package dependencies the correct one? Is there a better
solution? In particular, are the MC kernel bits implicitly exported as a
module inside JBossAS somewhere that I can't find, so that I could import
I've uploaded a 2.0.2-SNAPSHOT of jboss-cl with a fix for this bug
https://jira.jboss.org/jira/browse/JBCL-77
if you want to try it.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194633#4194633
Reply to the post :
http://www.jboss.com/index.html?module=bb&op
OK, taking this another way - was my solution of adding the two package
dependencies the correct one? Is there a better solution? In particular, are
the MC kernel bits implicitly exported as a module inside JBossAS somewhere
that I can't find, so that I could import a module or modules instead
"[EMAIL PROTECTED]" wrote : Just to clarify - I put import-all="false" on both
of my deployments and the effect is unchanged...
On your deployments this is already false by default. ;-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194535#4194535
Reply to th
Just to clarify - I put import-all="false" on both of my deployments and the
effect is unchanged...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194517#4194517
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194517
__
Hm. I see that this is "classloader" not "classloading". Perhaps I should
have grepped more specifically than "classload". :-)
Which leaves me at square zero. No idea what to fix to make this work in
jbossas. I'll poke around some more...
View the original post :
http://www.jboss.com/index
Ah, great. Where should I make this change in JBossAS? in deployers.xml? I
see this:
|
| ${jboss.lib.url}jboss-deployers-core-spi.jar
| ${jboss.lib.url}jboss-deployers-core.jar
| ${jboss.lib.url}jboss-deployers-client-spi.jar
| ${jboss.lib.url}jboss-deplo
"alesj" wrote : "alesj" wrote : I'll check the NPE.
| | Trying to mock your case.
| I've copied your xml config.
| Running my demos boot, I don't get NPE.
| ClassLoadingSpace:325 is used, but it's all fine.
Found it. ;-)
It's what I suspected in the first place - 1st post with import-all
"alesj" wrote : I'll check the NPE.
| Trying to mock your case.
I've copied your xml config.
Running my demos boot, I don't get NPE.
ClassLoadingSpace:325 is used, but it's all fine.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194479#4194479
Reply to the
"alesj" wrote : Quick check/hack,
| what if you put import-all="false" to classloading element?
Although this should be there by default ...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194475#4194475
Reply to the post :
http://www.jboss.com/index.html?mo
Quick check/hack,
what if you put import-all="false" to classloading element?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194474#4194474
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194474
_
I'll check the NPE.
Trying to mock your case.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194472#4194472
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194472
___
jboss-use
If it matters, the jboss-classloading.xml of the jboss-threads.jar looks like
this:
|
|
|
|
|
|
|
|
|
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194470#4194470
Reply to the post :
http://www.j
BTW, the @VERSION@ thing gets replaced with my real version number during build
(yes, I checked it).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194468#4194468
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194468
_
OK, latest update. Figuring that it was due to the fact that the classloading
configuration for my deployer did not include the appropriate deployer classes,
I changed my jboss-classloading.xml as follows:
|
|
|
|
|
|
|
|
|
|
Now I
Schema fixed in trunk. Will work some more on this tonight...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194155#4194155
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194155
Scott was seeing this here:
- http://lists.jboss.org/pipermail/jboss-dev-forums/2008-November/028087.html
Dunno what he did to fix it.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194135#4194135
Reply to the post :
http://www.jboss.com/index.html?module=bb
btw: deployers go into deployers/
- file:/home/david/src/java/jbossas/trunk/build/output/jbos
s-5.0.0.GA/server/default/deploy/jboss-threads.deployer
Although they should work in deploy/ as well. :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194134#41941
"[EMAIL PROTECTED]" wrote : So I guess I'm back to my original problem of
finding where that class went :)
|
It's still there:
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/branches/Branch_2_0/deployers-vfs/src/main/java/org/jboss/deployers/vfs/deployer/kernel/BeanMetaData
"[EMAIL PROTECTED]" wrote : Also it uses 'required="true"' etc when it should
be using 'use="required"'. I seem to recall reporting this before. :-)
|
| Can I commit a fix for this without screwing anything up?
Sure, go ahead.
I'll port it to branch then.
View the original post :
http://ww
Now I see that jboss-deployers doesn't have a tag for BeanMetaDataFactory
deployers. So I guess I'm back to my original problem of finding where that
class went :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194121#4194121
Reply to the post :
http://ww
Also it uses 'required="true"' etc when it should be using 'use="required"'. I
seem to recall reporting this before. :-)
Can I commit a fix for this without screwing anything up?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194120#4194120
Reply to the pos
Wait, I see where this is coming from. I'm still declaring my deployer like
this:
| deployment xmlns="urn:jboss:bean-deployer:2.0">
|
|
|
org.jboss.threads.metadata.ThreadsMetaData
|
|
|
|
|
|
org.jboss.thr
26 matches
Mail list logo
