August 2007 - jboss-dev-forums - Jboss List Archives

by julien＠jboss.com

The detachment of the modules is starting to produce a jar hell :-) which was expectable because we need to use a snapshot mechanism to produce "snapshot" libs. And it produces lot of management additional work. So soon we probably will need to migrate to maven2 since it is designed to solve this kind of problems. Other JBoss projects which have already migrated to maven do make the distinction between 2 kind of repositories, one for released versions and one for snapshots versions. I think that snapshot repository is rebuild automatically (which makes sense to me). You can find more about it here : http://wiki.jboss.org/wiki/Wiki.jsp?page=Maven So for now we are going to continue to resolve this by ourselves (since mostly myself and bolek are working on detached modules, it's not much hard). Until we have completed the maven migration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078963#4078963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078963

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wrong methods on KernelControllerContext

by alesj

"adrian(a)jboss.org" wrote : | I removed applyMetaData() since that was completely unnecessary. | I factored out the MetaDataVisitor implementations from AbstractKernelControllerContext | to make it obvious that this stuff doesn't need to be in the context and is entirely orthogonal. | Yup, I agree. But since this was still stuck in AbstractKernelControllerContext, the applyMetaData was necessary. :-) If you just hinted this when I was splitting the initial visit ... ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078947#4078947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078947

18 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Redesign extended persistence context

by bstansberry＠jboss.com

"wolfc" wrote : Given those rules an entity drawn from a xpc and directly refered (from a field) by a SFSB must act as I said. JPA 3.2.4 says serializing an entity "may result" in a detached entity; it doesn't say it must. So, seems to me we have flexibility. That said, a developer wanting to write a portable app would need to assume the container is going to detach the entity, since some vendors might. I take it the way an app developer would handle that would be to do a merge of all entities in the @PostActivate callback, correct? anonymous wrote : Why would you want to keep managed entities around? Assuming the idea here is this is supposed to resemble pojo programming as much as possible, why would an app developer not want to? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078946#4078946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078946

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ORA-014161 - Help with Bug on Oracle Driver

by clebert.suconic＠jboss.com

I would be able to simply use insert and ignore for duplicate keys.. but Postgres would invalidate the transaction on those cases, throwing this message: "25P02, current transaction is aborted, commands ignored" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078928#4078928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078928

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ORA-014161 - Help with Bug on Oracle Driver

by clebert.suconic＠jboss.com

Just for the record.. I'm really disappointed with Oracle driver. This is a very basic feature IMO, I have found lots of references and complains on the internet about this and they don't seem to care about it. I will just avoid binding BLOBS on Select clauses on Oracle, as I don't want to deal with support cases on this later. The consequence will be an "if Oracle" on the code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078923#4078923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078923

18 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: jboss 4.2.1 causes org.springframework.transaction.NoTra

by bstansberry＠jboss.com

This is a forum to discuss development issues related to JBoss' clustering features. Please take this discussion to a user forum; not the clustering user forum unless there's some indication of clustering involvement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078906#4078906 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078906

18 years, 7 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: jboss 4.2.1 causes org.springframework.transaction.NoTra

by Ernie2705

I do have exactly the same problem. Anybody solved this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078905#4078905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078905

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Wrong methods on KernelControllerContext

by adrian＠jboss.org

While looking at the scoping changes, I discovered some wrong methods on the KernelControllerContext. To repeat what I said before, most of the runtime state/config should be done through the DependencyInfo not the ControllerContext. Where the ControllerContext holds state it is simply useful information to prevent repeated access/construction, e.g. BeanInfo in the POJO stuff or the legacy ServiceContext in the MBean stuff. I removed applyMetaData() since that was completely unnecessary. I factored out the MetaDataVisitor implementations from AbstractKernelControllerContext to make it obvious that this stuff doesn't need to be in the context and is entirely orthogonal. I moved isAutowireCandidate() to the DependencyInfo where it belongs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078895#4078895 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078895

18 years, 7 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: jboss portal 2.6.1 and AS 4.0 x

by thomas.heute＠jboss.com

I don't understand your latest statement. JBoss AS (4.0.5 or 4.2.1) is a J2EE application server. JBoss Portal is a web application that runs in JBoss Application Server (i just saw that the reference guide still mention 4.0.5+ but the same instructions apply to JBoss AS 4.2.1.GA) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078857#4078857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078857

18 years, 7 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: jboss portal 2.6.1 and AS 4.0 x

by jjoo

I am new bee for JBoss. Whenever I found some document available open community, the version of AS is not 4.2.1GA. This is why I am looking for AS 4.0.x (let me know if I am wrong). The AS which I am looking for is NOT for ONLY JBoss Portal, but for something else. We are looking for J2EE application server. Thanks, Jae View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078850#4078850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078850

18 years, 7 months

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 August 2007