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

[Design the new POJO MicroContainer] - Re: Circular dependency error msg problem

by adrian＠jboss.org

Something like this needs including in the main deployers version of the ICDE http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=69861 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140560#4140560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140560

16 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Dependency conflicts lost during AS mavenization

by dimitris＠jboss.org

In the legacy build, jbossws-spi is only referenced by jbossws modules. In the maven thirdparty build, jbossws-spi is imported from 2 different places (jboss.jbossws-spi vs org.jboss) Both seem wrong. Shouldn't be org.jboss.jbossws:jbossws-spi or org.jboss.jbossws-spi:jbossws-spi ? | ... | +- jboss.jbossws-spi:jbossws-spi:jar:1.0.3-SNAPSHOT:compile | ... | +- org.jboss:jboss-metadata:jar:1.0.0-SNAPSHOT:compile | | +- org.jboss:jbossws-spi:jar:1.0.0.GA:compile | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140553#4140553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140553

16 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru

by scott.stark＠jboss.org

We said we would define the missing integration spis as needed to break any dependency on internals and break the circular dependency between ejb3 and jbossas. This just needs to be done in the coming two weeks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140551#4140551 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140551

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Circular dependency error msg problem

by alesj

"scott.stark(a)jboss.org" wrote : In reality D should not be in the missing dependency list, but because the resolution was stopped as soon as the first unresolved dependency was seen it does. | Yeah, I don't see what D is doing there, since it should be OK. It shouldn't matter that it is referenced by some other bean as its dependency. Which resolution you're talking about? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140548#4140548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140548

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Circular dependency error msg problem

by scott.stark＠jboss.org

Yes, D is reported as the cause. It is simply because the logic in IncompleteDeployments.calculateContextsError removes any context that has missing dependencies as root causes. This ultimately leaves D which has no dependencies. In reality D should not be in the missing dependency list, but because the resolution was stopped as soon as the first unresolved dependency was seen it does. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140547#4140547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140547

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: XmlSeeAlso

by heiko.braun＠jboss.com

I've tested the scenario with both Metro and Native. I had to put the XmlSeeAlso annotation manually (tooling issue): @XmlSeeAlso(USAddressType.class) public class AddressResponse { ... } Both Native and Metro handle request and response in the same way. They receive a USAddress instance (requires casting though) and respond with a correct xsd:type attribute on the AddressResponse super element. IMO, everything is fine and works as expected, besides the tooling problem. But that's something we cannot easily fix without going to JAXWS 2.1. Here's is a quick oveview how JAXB handles xsd:any types: https://jaxb.dev.java.net/guide/Mapping_of__xs_any___.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140546#4140546 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140546

16 years, 1 month

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Re: XMBean NotSerializationExceptions issue

by yichong_yang_jboss

Would anyone from JBOSS answer this question? Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140541#4140541 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140541

16 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: Security and JCA

by anil.saldhana＠jboss.com

There were multiple Util classes in the security project and I renamed a few. I think the one you are affected is renamed to CryptoUtil. I did create a JBAS issue to get the JCA security integration fixed for AS5 some time ago. Let me get the jira issue for you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140540#4140540 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140540

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation hash check with security enabled

by alesj

"alesj" wrote : which I think is somehow too strict to require security check, since is a simple equals/hash call made by HashSet to remove annotation metadata. Doing direct '==' would probably do the trick, but that's too impl specific. Not to mention the horrible code that would come out of it. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140537#4140537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140537

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Annotation hash check with security enabled

by alesj

With my recent changes of INSTANCE scope inspection, I have the following code to check if there is some other non-annotation metadata present: | Set<Object> checkSet = new HashSet<Object>(); | Object[] allMetaData = levelMetaData.getMetaData(); | Annotation[] annotations = levelMetaData.getAnnotations(); | // all meta data is not null, since instance metadata is not empty | checkSet.addAll(Arrays.asList(allMetaData)); | checkSet.removeAll(Arrays.asList(annotations)); | | // do we have something else than annotations | if (checkSet.isEmpty() == false) | return true; | but I already stumbled upon this | 7828 ERROR [AbstractKernelController] Error installing to Instantiated: name=SimpleBean state=Described | java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers) | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | at java.security.AccessController.checkPermission(AccessController.java:427) | at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) | at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1662) | at java.lang.Class.checkMemberAccess(Class.java:2125) | at java.lang.Class.getDeclaredMethods(Class.java:1762) | at sun.reflect.annotation.AnnotationInvocationHandler.getMemberMethods(AnnotationInvocationHandler.java:257) | at sun.reflect.annotation.AnnotationInvocationHandler.equalsImpl(AnnotationInvocationHandler.java:169) | at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:40) | at $Proxy34.equals(Unknown Source) | at java.util.Arrays$ArrayList.indexOf(Arrays.java:2384) | at java.util.Arrays$ArrayList.contains(Arrays.java:2391) | at java.util.AbstractSet.removeAll(AbstractSet.java:146) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.hasMetaDataAtLevel(AOPConstructorJoinpoint.java:213) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.checkForMetaDataAtSubInstanceLevel(AOPConstructorJoinpoint.java:189) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.methodHasSubInstanceMetaData(AOPConstructorJoinpoint.java:166) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(AOPConstructorJoinpoint.java:142) | at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.rootHasSubInstanceMetaData(AOPConstructorJoinpoint.java:122) | which I think is somehow too strict to require security check, since is a simple equals/hash call made by HashSet to remove annotation metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140533#4140533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140533

16 years, 1 month

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 April 2008