November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

That's the problem. These are not dependencies, but simple attributes. If I use your approach, the Controller treats them as dependencies and won't install. I figured out a better approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989052#3989052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989052

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by scott.stark＠jboss.org

ServiceAttributeMetaData: | // set attributes | List<ServiceAttributeMetaData> attrs = new ArrayList<ServiceAttributeMetaData>(); | ServiceAttributeMetaData attr = new ServiceAttributeMetaData(); | attr.setName("TransactionManagerFactory"); | ServiceDependencyValueMetaData dependencyValue = new ServiceDependencyValueMetaData(); | dependencyValue.setDependency(getTransactionManagerServiceName()); | dependencyValue.setProxyType("attribute"); | attr.setValue(dependencyValue); | attrs.add(attr); | | ejbModule.setAttributes(attrs); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989051#3989051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989051

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

by bill.burke＠jboss.com

+1 for Weston. Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989041#3989041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989041

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

by mark.little＠jboss.com

"weston.price(a)jboss.com" wrote : anonymous wrote : | | It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-) | | | | Red Herring. Nice try. | | anonymous wrote : | | You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway. | | | | This is the crux of the issue. Technically, IMO this scnerio should never involve the use of an external TM to begin with. Rather, it should be handled locally per ResourceManager. This would be something I think we should consider looking at as a'solution'. | Hey, who said we'd not agree on something ;)? anonymous wrote : | anonymous wrote : | | Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits. | | | | Yes! Please refer to my previous comment. | | anonymous wrote : | | If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate. | | | | I am not sure 'benefits' is the right term. What customers typically *DO NOT* want is for stuff that worked in one version to suddenly stop working in the next. | That depends how you explain it to them. Remember: A is for Atomic ;-) anonymous wrote : | anonymous wrote : | | I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance! | | | | Sigh...As I *thought* I clearly stated, I am not advocating this solution. | | My quotes: | | anonymous wrote : | | | | 'I am not saying we 'should' support it...' | | | | and | | | | 'Let me reiterate, I am not advocating this type of configuration.' | | | | finally | | | | Since this functionality exists in JBossTM, I believe this warrants some discussion. | | | | | | Again, I am not advocating so much as I am raising it as a red flag moving forward. | | anonymous wrote : | | Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-) | | | | I can think of another word *A* stands for right about now ;-) | Yeah, me too and I haven't even got to C yet ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989039#3989039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989039

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - HAConnectionFactory UseCase question

by clebert.suconic＠jboss.com

I have to define what's the UseCase on HAConnectionFactory. I could either define the load balancing policy on jndi.lookup or connectionFactory.createConnection. Let me explaing through examples: On these examples I have serverA, B and C. Immagine subsequent calls to either jndi.lookup or factory.createConnection doing a load balancing. (Round Robbin probably) Example I: connectionFactory.createConnection(); << returns a connection pointing to server A | connectionFactory.createConnection(); << server B | connectionFactory.createConnection(); << server C | Example II: | ConnectionFactory factoryA = jndi.lookup(); // this connection will always point to A | ConnectionFactory factoryB = jndi.lookup(); // this connection will always point to B | ConnectionFactory factoryC = jndi.lookup(); // this connection will always point to c | We could implement it either way. At this point I have assume Example I, but we need to define if this is the correct behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989029#3989029 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989029

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

This is actually proving to be a bit more tricky than what I had previously thought. Rather than push the envelope, I started with a JAXP compliant parser deployer (though this can be changed). The parsising of the *-ds(x).xml file is the trivial part. Generating the apprpriate MBeans is proving to be the real *catch*. The org.jboss.resource.connectionmanager.RARDeployment, as well as all the other JCA related MBeans (JBossManagedConnectionPool, ConnectionManager etc) extend ServiceMBean support and as a result, rely on the default constructor being called. As a result, there is no way to inject the DeploymentData into them with the org.jboss.resource.deployment.RARDeployment. Unfortunately, I have as of yet been unable to figure out how to set properties on the MBeans using the ServiceMetaData API. I can set dependencies, but what about regular attributes? The only thing I could find was the ServiceElementValueMetaData/ServiceJavaBeanValueMetaData. Is there an API I am missing to set simple attributes on MBeans programmatically? So, to support programmatic deployment, something has to be done. Either the existing RARDeployment has to be rewritten to extend ServiceDynamicMBeanSupport (and all the other MBeanss), or new MBeans have to be created to support this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989027#3989027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989027

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions

by weston.price＠jboss.com

anonymous wrote : | It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-) | Red Herring. Nice try. anonymous wrote : | You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway. | This is the crux of the issue. Technically, IMO this scnerio should never involve the use of an external TM to begin with. Rather, it should be handled locally per ResourceManager. This would be something I think we should consider looking at as a'solution'. anonymous wrote : | Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits. | Yes! Please refer to my previous comment. anonymous wrote : | If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate. | I am not sure 'benefits' is the right term. What customers typically *DO NOT* want is for stuff that worked in one version to suddenly stop working in the next. anonymous wrote : | I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance! | Sigh...As I *thought* I clearly stated, I am not advocating this solution. My quotes: anonymous wrote : | | 'I am not saying we 'should' support it...' | | and | | 'Let me reiterate, I am not advocating this type of configuration.' | | finally | | Since this functionality exists in JBossTM, I believe this warrants some discussion. | | Again, I am not advocating so much as I am raising it as a red flag moving forward. anonymous wrote : | Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-) | I can think of another word *A* stands for right about now ;-) anonymous wrote : | It would make a very good present ;-) | It's a crapshoot. anonymous wrote : | I've a wife and two kids to support, plus 3 cats. | Thanks for sharing! I always love hearing about the personal lives of celebrities. anonymous wrote : | GO AND BUY IT AGAIN. | Once the demmand for the book dies down, I will see if I can *sneak* in and grab a copy. anonymous wrote : | You know if makes sense ;-) | HAPPY CHRISTMAS!!!!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989019#3989019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989019

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Zero turnaround Java/JBoss

by scott.stark＠jboss.org

Provided that components are properly defined with their dependencies, one should be able to start with a component such as a servlet and transition back to a state where the class loader is defined and then roll forward with the same metadata. We are a long way from having this level of integration between the deployers and mc such that we have the complete object graph described to the mc along with dependencies and install/uninstall actions. There is also a disconnect with how the class loader is defined at the deployer layer rather than via a factory that can be re-run to recreate the class loader (I believe), not to mention tracking dependicies based on type usage associated with the class loader. I believe looking at copying a deployment object graph along the lines of what Sacha is indicating is where we want to get to first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989011#3989011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989011

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Web Console: Context Menus and Navigation

by tom.baeyens＠jboss.com

i would still would not use fixed context menus that are most of the time disabled. i think that 4 links can be easily fitted on one line as the first line in the content. but all arguments pro and con have been discussed. so you should just decide what you think is best and go ahead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989006#3989006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989006

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.2 web-console not working?

by luismolivares

Ok, then there is no IDE available to create the forms? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989005#3989005 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989005

19 years, 4 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 November 2006