June 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: No Security Context regression

by anil.saldhana＠jboss.com

I made some changes in aspects security and this morning we updated the version. I need to look at your tests to see what the problem is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157498#4157498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157498

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - No Security Context regression

by scott.stark＠jboss.org

Tests that were working this morning before updating trunk are now failing with the following exception. There is not security setup to check so there should be no such assertion in the client side interceptor. | java.lang.RuntimeException: No Security Context | at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:131) | at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125) | at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) | at AOPProxy$0.getViewManager(AOPProxy$0.java) | at org.jboss.test.profileservice.test.AbstractProfileServiceTest.getManagementView(AbstractProfileServiceTest.java:147) | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testSarDeploymentType(ProfileServiceUnitTestCase.java:244) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157496#4157496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157496

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - ESB FTP notifier - directory is relative to system root dir,

by ldimaggi＠redhat.com

The FTP notifier creates files in the path defined in the notifier relative to the system root, not the user's home dir. For example - as documented here: http://www.jboss.org/jbossesb/docs/4.3.GA/javadoc/esb/org/jboss/soa/esb/n... | <NotificationList type="OK" xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."> | <target class="NotifyFTP"> | <ftp URL="ftp://username:pwd@server.com/remote/dir" filename="{jbossesb.message.id}.txt"/> | </target> | </NotificationList> | The resulting file will be created in: /remote/dir Not in /home/username/remote/dir Is this intentional? Or a bug? Thx! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157479#4157479 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157479

16 years, 3 months

1
0
0 / 0

[Design of Management Features on JBoss] - JBAS-5557, Deployment type reimplemented in the management l

by scott.stark＠jboss.org

I have reimplemented the deployment type notion that was removed from the deployment spi in the management layer as an implementation detail of the ManagedDeploymentCreator registered with the MainDeployer. The http://jira.jboss.org/jira/browse/JBAS-5557 issue details the ways the deployment type is obtained. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157461#4157461 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157461

16 years, 3 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-3051: Adding server config to title

by scott.stark＠jboss.org

This could use the org.jboss.system.server.ServerConfig interface for the constants that represent the properties: SERVER_BIND_ADDRESS = "jboss.bind.address"; SERVER_NAME = "jboss.server.name"; but looks fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157460#4157460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157460

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: AOP and CL warning at undeploy

by kabir.khan＠jboss.com

The advisors referenced by AdviceBinding are the keys of a WeakHashMap. I attached a profiler to figure out if anything is keeping a strong references to the ExtendedManagedObjectAdvisors, but could not find anything. Using the profiler to force a garbage collection between undeployment of the app and shutdown of the server gets rid of the problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157430#4157430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157430

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alex.loubyansky＠jboss.com

Because name is the attribute, not a CDATA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157409#4157409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157409

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alex.loubyansky＠jboss.com

This is how you should the feature on the parser unmarshaller.setFeature("http://apache.org/xml/features/xinclude/fixup-base-uris", false); The test fails assertion now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157407#4157407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157407

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Variables in Mail Templates

by magro1202

Hi everyone I have tuned up a little the usage of variables in Mail Templates. usually when you want to use a variable like that | <mail-templates> | | <variable name="defaultSubject" value="Mail" /> | | <mail-template name='default'> | <actors>#{taskInstance.actorId}</actors> | <subject>#{defaultSubject}</subject> | <text><![CDATA[Mail von Geppi: | #{mailMessage}]]> | </text> | </mail-template> | the variable is evaluated correctly and the value of Subject is set to "Mail" but if you want to use variable references within the variables like this | <mail-templates> | | <variable name="defaultSubject" value="[#{processDefinition.name} #{processInstance.id}] generated Mail" /> | | <mail-template name='default'> | <actors>#{taskInstance.actorId}</actors> | <subject>#{defaultSubject}</subject> | <text><![CDATA[Mail von Geppi: | #{mailMessage}]]> | </text> | </mail-template> | the value within the variable is not evaluated. So i added a loop which evaluates the variable value until all references are solved. In class org.jbpm.mail.Mail: | public String getSubject() { | if (subject==null) return null; | Object parsedValue = null; | String ret = subject; | do { | ret = evaluate(ret); | ret = JbpmExpressionEvaluator.translateExpressionToDollars(ret); | parsedValue = new ExpressionEvaluatorImpl().parseExpressionString(ret); | } while (!(parsedValue instanceof String)); | | return ret; | } | | public String getText() { | if (text==null) return null; | Object parsedValue = null; | String ret = text; | do { | ret = evaluate(ret); | ret = JbpmExpressionEvaluator.translateExpressionToDollars(ret); | parsedValue = new ExpressionEvaluatorImpl().parseExpressionString(ret); | } while (!(parsedValue instanceof String)); | | return ret; | } | i will post a Jira Patch for this too regards Matthias View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157398#4157398 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157398

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Installing instance of wrong class gives weird error

by adrian＠jboss.org

That's not correct. It's now doing the check twice. Once when you do it and once inside the JDK reflection api. That's horribly inefficient, since these reflection calls are used everywhere. The whole point of ReflectionUtils is give more reasonable error messages after reflection calls fail, because the JDK is usually hopeless. e.g. you'll get something like | java.lang.IllegalArgumentException: wrong type java.lang.String | Without it telling you what invocation is being attempted or which parameter is wrong. What's required is to fix "handleErrors" to also check whether IllegalArgumentException is due to the wrong target object being passed for non-status invocations and not just assuming that it is due to an invalid parameter being passed. public static Throwable handleErrors(String context, Object target, + Class<?> clazz, + Object instance, Class<?>[] parameters, Object[] arguments, Throwable t) throws Throwable { if (t instanceof IllegalArgumentException) { if (target == null) throw new IllegalArgumentException("Null target for " + context); + if (clazz != null && instance != null && clazz.isAssignableFrom(instance) == false) + throw new IllegalArgumentException("Wrong target. " + instance.getClass().getName() + " is not a " + clazz.getName()); ArrayList expected = new ArrayList(); if (parameters != null) { for (int i = 0; i < parameters.length; ++i) expected.add(parameters.getName()); } ArrayList actual = new ArrayList(); if (arguments != null) { for (int i = 0; i < arguments.length; ++i) { if (arguments == null) actual.add(null); else actual.add(arguments.getClass().getName()); } } throw new IllegalArgumentException("Wrong arguments. " + context + " for target " + target + " expected=" + expected + " actual=" + actual); } else if (t instanceof InvocationTargetException) { throw ((InvocationTargetException) t).getTargetException(); } throw t; } and | public static Object invoke(Method method, Object target, Object[] arguments) throws Throwable | { | if (method == null) | throw new IllegalArgumentException("Null method"); | try | { | return method.invoke(target, arguments); | } | catch (Throwable t) | { | throw handleErrors(method.getName(), Strings.defaultToString(target), | + method.getDeclaringClass(), target, | method.getParameterTypes(), arguments, t); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157396#4157396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157396

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008