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

[Design the new POJO MicroContainer] - JBREFLECT-6 Skipping compilation step

by flavia.rainone＠jboss.com

Adrian, As I was studying JBoss Reflect issues, I stumbled upon https://jira.jboss.org/jira/browse/JBREFLECT-6 and I got curious about it :) "adrian(a)jboss.org" wrote : The JavassistReflectionFactory builds up a source to compile the method, constructor and field accesors. | These implementations are faster than the normal reflection equivalents, but using the compiler is slow. | These methods should be optimized to generate the bytecode directly. | Currently, the whole Javassist API uses Java code and compiles that code for instrumentation. So, do you mean to extend Javassist API so it accepts bytecode instructions as an option over Java code? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236862#4236862 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236862

16 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - JBAS-7010, SecurityContext creation

by scott.stark＠jboss.org

I found an issue with the JndiLoginInitialContextFactory not creating a SecurityContext and hence not being propagated correctly by the org.jboss.ejb3.security.client.SecurityClientInterceptor. Looking at the SecurityClientInterceptor it seems the logic for creating a SecurityContext if one is not found should be updated to include the principal and credential: | // Get Principal and credentials | Principal principal = SecurityActions.getPrincipal(); | if (principal != null) invocation.getMetaData().addMetaData("security", "principal", principal); | | Object credential = SecurityActions.getCredential(); | if (credential != null) invocation.getMetaData().addMetaData("security", "credential", credential); | | //Get the security context | SecurityContext sc = SecurityActions.getSecurityContext(); | if(sc == null) | { | sc = SecurityActions.createSecurityContext(); | SecurityActions.setSecurityContext(sc); | } | The problem I saw was that the JndiLoginInitialContextFactory has set the principal and credential, but had not created a SecurityContext, and therefore an SC with a null principal and credential was sent over, effectively rendering the principal and credential metadata useless. Any other older code that is not creating a SecurityContext will also starting failing with the newer SecurityContext based logic. We need to be using the principal and credential when creating a SecurityContext. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236860#4236860 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236860

16 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - ManagedObject interface for AS ChannelFactory

by bstansberry＠jboss.com

I'm currently working on fleshing out the MO for the JGroups ChannelFactory service. Design wiki is here: http://www.jboss.org/community/wiki/ManagedObjectinterfaceforASChannelFac... Any comments will be most appreciated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236855#4236855 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236855

16 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: EJB3 managed component names and types

by ips

After thinking about this some more, the instance metrics and invocation metrics for a given EJB3 SLSB are currently exposed via two different component instances, both of type EJB3:SLSB. This goes against the rule that all components of a given type should have the same signature (i.e. set of properties and operations). At least I think this should be a rule, and I think Scott is in agreement. Otherwise, clients end up needing to first query by type and then parse the returned component names to determine the component's "sub-type", rather than being able to query on the type alone. So in this case, I think we should either have 1) a single component type EJB3:SLSB with one component instance of that type per SLSB that exposes both instance and invocation metrics or 2) two component types EJB3:SLSB-instance and EJB3:SLSB-invocation with one component instance for each of these types per SLSB Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236854#4236854 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236854

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: WebServiceContext proxy

by uromahn

anonymous wrote : That message isn't applicable to the end users (i.e. bean/webservice application developers). We'll fix it appropriately. Since I am seeing the exact same "Warning" in 5.1.0.GA, when are you guys either suppress this warning or fix it once and forever. Also, is there an ETA for this "fix"? Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236853#4236853 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236853

16 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - EJB3 managed component names and types

by ips

"refs-ejb3-ejblink.ear-EjbLink1Bean-metrics-instance" "refs-ejb3-ejblink.ear-EjbLink1Bean-metrics-invocation" A dash doesn't seem like the best choice as a delimiter here, since dashes will commonly be found in the ear filename and may even be found in the ejb name. It makes the component name difficult to parse or query on. I suggest using '|' or '/' as the delimiter instead, e.g.: "refs-ejb3-ejblink.ear/EjbLink1Bean/metrics-instance" This allows me to easily parse out the three tokens that comprise the name. As for the last portion of the name, this seems redundant to be included in every name. Why not make it part of the component type name instead, e.g.: name: refs-ejb3-ejblink.ear/EjbLink1Bean type: EJB3:SLSB-instance Even better, why can't the instance and invocation metrics all be exposed by the same component type, so there would be a single component per EJB? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236851#4236851 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236851

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: BeanContainer.getAnnotation returning the old value

by ALRubinger

Any NPE's must be addressed. Would you please paste that stack trace here? You can open a JIRA for this under project JBMETA. Ultra bonus points if you want to attach a patch to the issue for a new test case exposing the NPE: http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/test/j... ...just add it in there. :) S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236848#4236848 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236848

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: BeanContainer.getAnnotation returning the old value

by zbedell

By any chance has any further development happened on this issue or its patch? It looks like JBoss 5.1.0-GA incorporates this patch, but I'm running into a NullPointerException in org.jboss.metadata.annotation.creator.ejb.jboss.RolesAllowedProcessor within the added code. This bit: if (existingMethod.getMethodName().equals(mmd.getMethodName()) | && existingMethod.getMethodParams().equals(mmd.getMethodParams())) | { | // Do nothing | return; | } When a method comes in with zero parameters (the exitingMethod MethodMetaData object toString() looks like "MethodMetaData(ejbName=EntitySessionBean,interface=null,method=*,params=null)", JBoss throws NPE on deployment when the exitingMethod.getMethodParams() call returns null and .equals() on that blows up. I haven't entirely ruled out some deployment and/or packaging problem with the application, but I'm not sure how best to figure that out. The app deploys fine under JBoss-4.2.3.GA, and there are no other messages even at TRACE level logging that point to a packaging problem. The app is using EJB3 annotations of course and is overriding some elements in both ejb-jar.xml and jboss.xml. Both of those pass schema validation using the jboss_5_0.xsd schemas. Any guidance would be much appreciated. Best regards, Zac Bedell New York State Unified Court System View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236846#4236846 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236846

16 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by tom.baeyens＠jboss.com

the current integration tests run as a remote application client. the services (repository, execution, task,...) delegate internally to the command service. the examples and test-db test suites use the these services directly (not the command service) user doesn't see the difference in their client api. between local usage and remote app server client usage. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236810#4236810 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236810

16 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by camunda

If you have a remote client you can ONLY use the CommandService. Why this should be not allowed? The CommandService + Commands are a pretty good defined interface I think. Using the ProcessEngine only works from INSIDE the app server. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236794#4236794 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236794

16 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009