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

[Design of Security on JBoss] - Re: Broken object names in jacc

by adrian＠jboss.org

I've found out why the simple name was coming back as the empty string and fixed it. http://jira.jboss.com/jira/browse/JBDEPLOY-18 But you still should really be using the full name (unless you have a mechanism to override the object name when they conflict). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137542#4137542 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137542

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by adrian＠jboss.org

"dimitris(a)jboss.org" wrote : | So the important bit is to make sure we fix those duplicate imports. It's more complicated than that. Let me give you an example of why the maven transitive dependencies stuff is broken (or at least impossible to manage effectively). X->Y means X depends on Y Lets suppose you have a util project with two versions common-core:1.0.0 common-core:1.0.1 then you have jbossxb:2.0.0 -> common-core:1.0.0 Now you have a project that uses both (but a different version of common-core) jbossmc:2.0.0 -> jbossxb:2.0.0 jbossmc:2.0.0 -> common-core:1.0.1 Which gets used? common-core:1.0.1 of course (it is explicit) You have another project that does jboss-deployers:2.0.0 -> jbossmc:2.0.0 jboss-deployers:2.0.0 -> jbossxb:2.0.0 Now which version of common-core gets used? The answer is common-core:1.0.1 because jbossmc is first in the list Finally here's the problem jbossas:5.0.0 -> jboss-deployers:2.0.0 jbossas:5.0.0 -> jbossxb:2.0.0 The version that gets used is common-core:1.0.0 Why? Even though jboss-deployers resolves to common-core:1.0.1 and it is first on the list, its link to common-core is two steps away, but jbossxb's link is one step away. Stupid. The only answer is go through all the poms and check them (what I call baby sitting). if you get the wrong answer then either do an exclusion or list the dependency you want explicitly. BUT DO YOU REALLY KNOW THAT YOU SHOULD BE USING common-core:1.0.1? What if you listed jbossxb before jboss-deployers in the jbossas project? The fundamental problem is that maven has no idea that 1.0.1 is after 1.0.0 and that regardless of where it is in the dependency hierarchy it should be used. The other approach is to list everything explicitly in every project but you've still got to "babysit" your pom when you upgrade dependencies to see wether its transitive dependencies are later and therefore need updating in your project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137534#4137534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137534

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by dimitris＠jboss.org

"pgier" wrote : Yes, normally this would work and the explicit dependency would win. The problem in some of our dependency trees has to do with artifacts that changed their name. So maven doesn't know that these two are really different versions of the same thing. | | AS --> ejb3 --> jboss-logging-jdk | AS --> jboss-common-logging-jdk | | The transitive one might actually come first in the classpath, because maven builds the tree doing a depth first traversal (This appears to be fixed in 2.0.9 http://jira.codehaus.org/browse/MNG-1412). So jboss-logging-jdk needs to be excluded from the ejb3 dep tree in the AS dependencies. | So the important bit is to make sure we fix those duplicate imports. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137521#4137521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137521

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Kernel module wip WARNING

by adrian＠jboss.org

I'm back to a working build at least upto the deployers. I haven't done reliance or OSGi. The fix is basically to exclude JBossXB from choosing the version of jboss-reflect I've updated all the snapshots so they are using consistent versions. You can update the microcontainer project as much as you want. BUT PLEASE DON"T MODIFY IT IN A WAY THAT BREAKS BACKWARDS COMPATIBILITY. I still haven't verified whether it is actually backwards compatible yet, but then the JBossAS all config isn't booting for me currently. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137518#4137518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137518

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Amazon S3 cache loader

by genman

Replying to the issue comments... I added pooled HTTP connections. Didn't help performance, though. I will add documentation. Not sure I have the time to add an S3 emulator. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137513#4137513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137513

18 years

1
0
0 / 0

[Design of JBoss Web Services] - XmlSeeAlso

by darran.lofthouse＠jboss.com

I am just trying to find out some further information on the level of support of XmlSeeAlso for. This annotation was added to JAXB 2.1 so on a super type the sub classes can be identified and used by the JAXB context. The JAX-WS 2.1 specification allows this annotation to be added to the service endpoint interface. We have JAXB 2.1 but not JAX-WS 2.1 so I can add the annotation to a type known to JAXB but not to the SEI. The scenario I have requires this annotation to be added when using wsconsume. One of the return types being returned from my SEI wraps an Object as in the WSDL it is defined as wrapping an xsd:anyType I need the object instance assigned to this to be marshaled correctly. The only way that I have found to get round this is to extend the object that is returned from the method an annotate that with XmlSeeAlso and return an instance of this instead. Do we have any other support for XmlSeeAlso? Adding it manually to the SEI did not achieve anything? Is there any way to get wsconsume to add it to the generated classes so I don't need this workaround? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137512#4137512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137512

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Configurator and MethodJoinpoints replacement

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | So, what exactly has to go out of Configurator then? | | Since I had no idea tidyup involved that part. | | The idea was to reduce it to what actually gets used | and to make it more comprehensible (if possible). | | Its just a helper class that's been through so many iterations that there's | all sorts of unused cruft in there. | | The property stuff has long since changed to a get/set on the Bean/PropertyInfo | but that doesn't mean the Configurator knew this. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137495#4137495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137495

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Configurator and MethodJoinpoints replacement

by alesj

"adrian(a)jboss.org" wrote : No this goes back to the configurator tidyup task you just closed. | | These methods are no longer used except by the obsolete "OldConfigureAction". | | They should have been removed (and so should the obsolete action). | OK, I'll reopen the task then. So, what exactly has to go out of Configurator then? Since I had no idea tidyup involved that part. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137490#4137490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137490

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving to CR1 releases of the MC projects

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : I am working on the aop-mc-int xml parsing. Am I OK to commit to aop-mc-int? | Yes. The issue was I didn't people to update the maven snapshots, but it is too late now, Ales already did it. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137489#4137489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137489

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Kernel module wip WARNING

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | The jboss-mdr snapshot you released yesterday depends on the old | | jboss-reflect-2.0.0.Beta11 | | | MDR change was a small bug fix. | If it helps, you can revert it. | I know where to find it and fix it again. | | So, even though Reflection didn't have any impact on my MDR change, I should move this dependency to snapshot in MDR? The way the poms are currently setup is broken. The reflection dependency is coming from jbossxb. But if you remove that, then it comes from mdr. That's what I'm fixing now. In general you don't have to update to the snapshot unless it is really dependent on the change. But as a matter of policy, we should be updating the poms regularly to run over the latest *stable* releases we expect to support. Otherwise we'll never find problems when people change things inconsiderately :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137488#4137488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137488

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008