September 2007 - jboss-dev-forums

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : So there is a circular dependencies between mc and aop at least in terms of how the mc is now setup as an assembly type of project. If I try to release jboss-container, it depends on the parent jboss-microcontainer from build/pom.xml and does not have a container/{trunk,tags} structure for an individual release. | | | | aop depends on jboss-container. I can manually release jboss-container, but how should these projects bet setup so that the mvn release process works for such interdependent projects? | | | | Like I said before. The container project (and the classloader project) | shouldn't be in the MC build. They are only there because the MC was initially | the major consumer while we developed them. ok, a task for that: http://jira.jboss.com/jira/browse/JBMICROCONT-207 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082217#4082217 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082217

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "bill.burke(a)jboss.com" wrote : | | If you saw my original post, this just isn't feasible as the EJB container (or any component that uses EE metadata references) might be referencing something that is MC-unaware. I.e. a third-party JMS implementation. | | | | In that case you impose a weaker dependency, either no dependency at all | or something like the JNDIDependencyItem. | What you need is something that says this needs the weaker notion, | I thought that already existed? Also we've been talking about having the notion of "optional" dependency in the MC. It sort of already exists with the install callbacks (with cardinality=0) The idea being you don't wait for the dependency to start, but if it appears later then it gets injected at that time. Similarly if it disappears you don't get undeployed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082216#4082216 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082216

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : | If you saw my original post, this just isn't feasible as the EJB container (or any component that uses EE metadata references) might be referencing something that is MC-unaware. I.e. a third-party JMS implementation. | In that case you impose a weaker dependency, either no dependency at all or something like the JNDIDependencyItem. What you need is something that says this needs the weaker notion, I thought that already existed? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082214#4082214 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082214

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by mark.little＠jboss.com

OK, the problem there might be that the recovery manager isn't looking at the right object store for the log? Why not clear out the existing ObjectStore and just re-use it in the next test? That's what our JBossTS QA does. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082213#4082213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082213

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

"adrian(a)jboss.org" wrote : Then a JNDIDependencyItem does something like: | | | public boolean isResolved() | | { | | Object realName = jndiRegistry.getRealName(jndiBinding); | | if (realName != null) | | { | | setIDependOn(realName); | | setResolved(true); | | } | | return super.isResolved(); | | } | | | | Now the iDependOn is set, we know when the providing service is removed | so we need to be removed/recycled. | If you saw my original post, this just isn't feasible as the EJB container (or any component that uses EE metadata references) might be referencing something that is MC-unaware. I.e. a third-party JMS implementation. "adrian(a)jboss.org" wrote : | In practice, as I discussed with Carlo, it is more difficult for ejb(3) | since you can actually depend on is the "ejb-link-ref-name", | resource-ref-name, etc. not the jndi name. | Its actually more difficult than that. EJB-refs might only know the interface of the EJB they are refencing, no other information. They also have to look first within the EJB-jar, then EAR, then globally for beans of this type. PersistenceUnits have exact same scoping rules as well, except that units defined in EJB jars or Wars are private. Making it even more complicated. For @Resource entries we rely on the mapped-name() attribute which we assume is a JNDI name. There is no other way to do it generically. "adrian(a)jboss.org" wrote : | Only when the application providing the link is deployed do you know what the | real jndi name is. This is something that could be resolved either by | | 1) a seperate registry/dependency item for links provided by the | javaee deployers/containers | | or | | 2) a more complicated jndi registry that understands deployments/links and | their contexts. | | I think (1) is easier and cleaner. But the devil is always in the details. :-) We already do (1) (or did? not sure if carlo totally refactored this incorrectly) for @EJB, @PersistenceContext, and @PersistenceUnit. It is just not possible to do it for datasources, JMS objects, and other resources. That's why I think a service is needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082209#4082209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082209

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Cannot release javaee project

by scott.stark＠jboss.org

"wolfc" wrote : I got a subcomponent jboss-ejb3-cache which is dependent on jboss-ejb-api 3.0.0. Either I'm going to depend on jboss-javaee (bummer) or we need the individuals. Then I need to go through the individuals and re-release them with a Beta1 extension. That is what I was trying to do as part of the maven release but dropped it when I went to do this by hand. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082207#4082207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082207

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

"julien(a)jboss.com" wrote : Why the repository component of that release does not declare any imports ? | | http://repository.jboss.com/jboss/microcontainer/2.0.0.Beta4/component-in... | | It makes MC very difficult to be consumed by other projects. | | "scott.stark(a)jboss.org" wrote : The basic mc 2.0.0.Beta4 is released and is now used by jboss5. The aggregate assembly seems broken so I don't know if we are putting out a standalone release as well. | | I'll update this from the maven pom dependencies today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082206#4082206 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082206

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

Hmm, the snapshots with the latest mc contents have been in head all week. I guess that was not communicated well enough. We can replace the Beta4 if you want. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082205#4082205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082205

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by clebert.suconic＠jboss.com

We play with starting/stopping the TransactionManager during our testsuite... And we use different ObjectStores for each time we start another TransactionManager, by doing: System.setProperty(com.arjuna.ats.arjuna.common.Environment.OBJECTSTORE_DIR, newObjectStore + new GUID().toString()); I have already tried to create XidImple only after starting the TransactionManager and I still get a failure.... I will investigate this. Thanks Mark! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082204#4082204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082204

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by mark.little＠jboss.com

Once TxControl has been initialized, it shouldn't affect any other tests. The ObjectStore contains logs on behalf of many different transactions. Your test infrastructure doesn't delete the ObjectStore contents by any chance? TS won't do that, so we're safe there. But is there a chance something else is? You can ls the contents of the ObjectStore at the end of each test. That might help to determine what's left there to recover (or not). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082200#4082200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082200

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