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

[Design of the JBoss EJB Container] - Re: Multiple store managers

by alex.loubyansky＠jboss.com

I would say 2. CMP2 is now in maintenance only, unless it's something very critical there won't be any new major development or refactoring. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036293#4036293 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036293

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jdbc2.StoreManager2 and key-generators

by alex.loubyansky＠jboss.com

The second option is ok. Would you like to contribute? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036289#4036289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036289

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: JBAS-4304 - Jboss calls ejbStore inside ejbPostCreate on

by alex.loubyansky＠jboss.com

Unless someone has a better idea, I could do it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036288#4036288 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036288

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Multiple store managers

by jesper.pedersen

I'm investigating the migration of one of our applications to the 'cmp2.x jdbc2 pm' configuration. One issue that I've found is that it isn't possible to use multiple store managers in each archive. The problem is that the store managers currently makes a specific cast to the implementation f.ex. | JDBCStoreManager2 manager = (JDBCStoreManager2)managers.get(i); | and use the specific methods (see f.ex. JDBCStoreManager2::start) making it impossible to define CMRs between the beans. F.ex. take the following entities: A <-> B -> C If you want to use the 'cmp2.x jdbc2 pm' for the 'A' and 'B' beans and the 'Standard CMP 2.x Entity Bean' configuration for 'C', since 'C' are basically a read-only bean. Using the 'Standard CMP 2.x Entity Bean' will limit the object creation, reduce memory and garbage collection of the bean if defined with commit option 'A' (as in our case) and should therefore increase performance for that bean. I see two solutions to this: 1) Define a common interface for the store manager and port the existing ones to that interface. 2) Leave it as it is - document behavior. I think that 1) will be a task that will involve 'some' work and with focus on EJB3 will require a lot commitment to make it happen. I personally can live with solution 2), since all our new applications are based on Seam (and therefore EJB3). Comments, thoughts, ideas ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036287#4036287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036287

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - jdbc2.StoreManager2 and key-generators

by jesper.pedersen

I'm investigating the migration of one of our applications to the 'cmp2.x jdbc2 pm' configuration. One issue that I've found is that currently all key-generators (jdbc.keygen) doesn't implement the jdbc2.CreateCommand interface and therefore can't be used together with the StoreManager2 implementation. I see three possible solutions to this: 1) Define a common interface that both StoreManager's can use and port the existing key generators to that interface 2) Create a jdbc2.keygen package that implements key generators for all databases and define them in standardjboss.xml under new names. 3) Let the existing key generators implement CreateCommand and bridge the new methods internally in each class. Since the interface for jdbc.StoreManager and jdbc2.StoreManager2 are very different I see 2) as best solution currently until a common interface for store managers have been defined. I know it is not a pretty solution, but it will work without messing with existing code. Comments, thoughts, ideas ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036282#4036282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036282

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: JBAS-4304 - Jboss calls ejbStore inside ejbPostCreate on

by dimitris＠jboss.org

Alexey have you decided if you want to fix this for 4.2.0.GA? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036276#4036276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036276

19 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Break up jboss common?

by wolfc

If you're thinking about a breakup, can org.jboss.util.id.SerialVersion be put in a seperate module? Then the javaee module doesn't have so many transitive dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036261#4036261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036261

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: JSR-170 message store

by burrsutter

I thought JCR has a class/category trick but that might not be exposed through the Message Store API which should abstract it. However, your work on the CBR wouldn't have to use the actions I was requesting. These actions are so end-users of the ESB could easily store a message and later easily retrieve one. I can see people configuring an ESB service called something like "ToBeReviewed" as a holding tank. And have another service that A) returns all the IDs B) returns the message for a specific ID. So these messages can be reviewed and perhaps pushed back out to other services in the ESB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036211#4036211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036211

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: JSR-170 message store

by kurt.stam＠jboss.com

I think we need one extra argument, a message store id/message classification. I think we want to use the message store for all sorts of purposes. One example would be the DLQ I was talking about, so we need to be able to have 'substore' in this store, where I can store messages for this purpose. Is this posiible? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036209#4036209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036209

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: JSR-170 message store

by burrsutter

Cool. Can you give me 2 out-of-the-box ESB actions? MessageSave (or whatever) -returns the UUID in the message header property MessageRetreive - has a to fetch the right one. Therefore I could easily use them in my jboss-esb.xml without have to write Java code to the Message Store APIs (or JCR APIs). Or just tell me if I'm crazy. :-) Burr View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036208#4036208 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036208

19 years, 1 month

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