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

[Design of POJO Server] - Invalid jboss-deployers-vfs-spi POM

by ALRubinger

Caught this today: [WARNING] POM for 'org.jboss.microcontainer:jboss-deployers-vfs-spi:pom:2.0.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.jboss.microcontainer:jboss-deployers-vfs-spi at Artifact [org.jboss.microcontainer:jboss-deployers-vfs-spi:pom:2.0.0-SNAPSHOT:compile] ...while running EJB3 Aggregator Build. FYI. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135906#4135906 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135906

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Eager state push on failure with Buddy Replication

by manik.surtani＠jboss.com

Are regions replicated on the buddy backup as well? The region marker, I mean? Just wondering if the concept in itself still holds true. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135905#4135905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135905

18 years

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by manik.surtani＠jboss.com

Well, A's put on /a/b/c doesn't become a "remote" put, the entire call is proxied to B. I.e., B handles the put. It becomes local to B, and is treated just as any other tx on B. The purpose of this is so that it can get into the TX Log that A is building up for D. The reason why it isn't just added directly is so that ordering can be maintained. Regarding A's local put on /1/2/3 before D requests a state transfer, perhaps we need to wait for this tx to finish? But in the meanwhile, proxy new local txs on A to B, and start recording remote txs that come in to A? This would bring back the need for idempotency of operations though, since we don't know if the state generated would already contain stuff in the tx log or not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135903#4135903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135903

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBDEPLOY-3 issues

by alesj

Regarding this: - http://jira.jboss.com/jira/browse/JBDEPLOY-10 What kind of annotations should we scan for? I currently just ported what is already in the real EARStructure (in AS5_trunk), which is just recognizing ear's children. With annotation scanning, I really think we should do this in generic fashion, once for all utils/frameworks that depend on annotation existence - e.g. EJB3, Seam, ... Providing the hooks for them to plug-in into our generic solution and get pre-scanned results. Or making this lazy, and let them trigger the initial scanning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135901#4135901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135901

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM With Seam

by kukeltje

ah... I did see that part... just did not look at it as the next-gen console due to the name.... Does that mean a there will become a separation between the 'admin' part and a gui for RAD purposes? I'd favour that... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135898#4135898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135898

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Removing HSQLDB

by kukeltje

JBoss should standardize on one DB. If SOA/ESB decided on H2, we should too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135897#4135897 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135897

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by wolfc

"scott.stark(a)jboss.org" wrote : Working through the resolution implementation more, we want a simple lookup to resolve a reference, so the ejbName of the providing cannot be part of at least one form of the key. That is an unknown element from the point of view of the referencer. We need multiple keys for each provider, some of which may be non-unique. | @EJB(beanInterface=X.class) | translates to a lookup of the provider "ejb/X". If we have multiple providers of the X interface, only the first to be processed would be the provider? If we want to fail an attempt at injection of a non-unique provider, we would have to track the duplicate providers to thrown an exception with the duplicates. | Exception if there are multiple providers are found in the same ear. "scott.stark(a)jboss.org" wrote : | @EJB(beanInterface=X.class, name="XBean") | translates to a lookup of "ejb/X/XBean". The ejb-name is only unique within an ejb-jar, so here again we can have duplicates sources matching this key. We are talking MC lookups here, right? "scott.stark(a)jboss.org" wrote : | @EJB(beanInterface=X.class, name="some.jar#XBean") | translates to a lookup of "ejb/X/some.jar/XBean". This is the only guaranteed unique key within a deployment. And I say reverse the bind. So the bind becomes: "ejb/X/some.jar/XBean" some.jar: | class TestBean { @EJB X a; } Hooks java:comp/env/TestBean/a to MC "ejb/X/some.jar" (which is a map). If the during injection the map contains more than 1 item, exception. @EJB(beanName="XBean") X b; Hooks java:comp/env/TestBean/b to MC "ejb/X/some.jar/XBean". @EJB(beanName="other.jar#XBean") X c; Hooks java:comp/env/TestBean/c to MC "ejb/X/other.jar/XBean". Note: 'name' is something else: @EJB(name="x", beanName="XBean") X d; Hooks java:comp/env/x to MC "ejb/X/some.jar/XBean". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135895#4135895 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135895

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by wolfc

"alesj" wrote : "scott.stark(a)jboss.org" wrote : I'm fuzzy on the bean factory details in terms of whether the pooling is something that can live in the mc code. | | | To repeat my 'proposal' more publicly. | I don't know how much this would help, but we can make our MC beanfactory more flexible by doing something like this: | e.g. able to change the underlying impl class from GenericBeanFactory to anything that implments BeanFactory | And I would also change the BeanFactory.createBean() method signature to createBean(Object... args). | Being able to pass in additional information when creating/pooling bean. | And we wouldn't be breaking any previous beanfactory usage. | What would the args be? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135888#4135888 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135888

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: webservices ejb3 api usage

by wolfc

Define an interface for the SessionContainer.localInvoke. This interface is part of ejb3-ws-spi and is implemented by ejb3-core. How do you get the correct ObjectName? For WebServiceContext injection I'm also in favor of 2.2, but it should be a requirement for the new (MC?) JavaEE injection component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135886#4135886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135886

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet runtime meta data extension

by thomas.heute＠jboss.com

Cool, i wanted something like that. It will be cleaner from what i had to do so far. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135883#4135883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135883

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