[Design of JBoss Build System] - LC_ALL quation
by scott.stark＠jboss.org
I run into this when using the older command line svn client with the mvn release process.
Seaching for the error found that setting LC_ALL=C fixes the problem. Anyone know what this is about?
| [INFO] Unable to check for local modifications
| Provider message:
| The svn command failed.
| Command output:
| svn: error: cannot set LC_ALL locale
| svn: error: environment variable LANG is not set
| svn: error: please check that your locale name is correct
|
| [INFO] ------------------------------------------------------------------------
| [INFO] For more information, run Maven with the -e switch
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 4 seconds
| [INFO] Finished at: Fri Oct 19 14:38:54 PDT 2007
| [INFO] Final Memory: 19M/358M
| [INFO] ------------------------------------------------------------------------
| [starksm@succubus jbossmc]$ export LC_ALL=C
| [starksm@succubus tmp]$ uname -a
| Linux succubus.starkinternational.com 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 17:57:31 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097126#4097126
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097126
18 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown
by clebert.suconic＠jboss.com
"anil.saldhana(a)jboss.com" wrote : http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/main/org/jboss...
|
| .....
|
| You should see some deadlock (server hang) on the server side or client side.
Anil,
How do you run your test?
I'm trying it here with:
./build.sh -Dtest=org.jboss.test.security.test.EJBSpecUnitTestCase one-test
And the test fails on a deployment error: (which I don't know if it's because of the metadata change, or something else)
16:42:58,526 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/extra/clebert/workspaces/svn-trunk-jboss/trunk/testsuite/output/lib/security-spec.jar state=PostClassLoader mode=Manual requiredState=Real
| org.jboss.deployers.spi.DeploymentException: Error deploying: jboss:service=jacc,id=security-spec.jar
| at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:126)
|
| .....
|
|
| Caused by: java.lang.NullPointerException
| at org.jboss.ejb.EJBPermissionMapping.createPermissions(EJBPermissionMapping.java:72)
| at org.jboss.deployment.security.JaccPolicyUtil.createPermissions(JaccPolicyUtil.java:137)
| at org.jboss.deployment.security.JaccPolicy.create(JaccPolicy.java:88)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
|
|
|
Anyway, that hang issue was solved
if you still have a problem, then is something else.. but due to the current state of trunk, I can't run your test.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097123#4097123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097123
18 years, 8 months
[Design of JBossCache] - JBCACHE-1153 - structural nodes
by mircea.markus
this jira is about not considering the structural nodes for eviction. This performance optimisation makes sense considering that nothing can be evicted from those nodes as they don't have an attribute map, but the eviction events are created, processed, etc(also interceptor stack when passivation is on).
Now, considering how eviction curently works, I think things can be optimized even more: by ignoring all the nodes that have empty attribute maps from eviction (this includes the prev defined structural nodes). By ignoring them from eviction I mean not generating eviction events on access on those nodes. Even at this point, when Cache.evict(fqn) is called on such an empty node, the impl works as follows:
a) fqn is NOT eaf, then then empty the attribute map
b) node is leaf, then remove it entirelly.
In the case of a) for empty nodes nothing really happens. Though when this call is performed some eviction events got processed, which is not necessary
I think the case of b should be preserved though, as keeping empty paths is not optimal.
So the optimisation would rather be: don't consider empty, not-leafs nodes for eviction.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097061#4097061
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097061
18 years, 8 months
[Design of JBossXB] - Re: Too much resolution?
by scott.stark＠jboss.org
Well, when I added the following "http://www.jboss.com/xml/ns/javaee" namespace binding to the JBoss50MetaData.class the binding time speed up 10x:
| public static SchemaBindingResolver initResolver()
| {
| DefaultSchemaResolver resolver = new DefaultSchemaResolver();
| resolver.addClassBindingForLocation("ejb-jar_2_0.dtd", EjbJar20MetaData.class);
| resolver.addClassBindingForLocation("ejb-jar_2_1.xsd", EjbJar21MetaData.class);
| resolver.addClassBindingForLocation("jboss_3_0.dtd", JBoss50DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss_3_2.dtd", JBoss50DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss_4_0.dtd", JBoss50DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss_4_2.dtd", JBoss50DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss_5_0.dtd", JBoss50DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss_5_0.xsd", JBoss50MetaData.class);
| // Workaround wildard resolution slowness
| resolver.addClassBinding("http://www.jboss.com/xml/ns/javaee", JBoss50MetaData.class);
| return resolver;
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097049#4097049
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097049
18 years, 8 months