[Design of EJB 3.0] - Re: jboss-ejb3-project
by ALRubinger
Some more thoughts:
Naming
I like "org.jboss.ejb3:jboss-ejb3"
Remove the component artifacts from JBossAS
If we provide a unified assembly for all EJB3 projects, then we may provide "jboss-ejb3.jar" as one artifact into AS. This provides the following benefits:
1) No more user confusion as to what version of the EJB3 project is in AS. A check into the manifest will simply say "1.0.0".
2) Removes the half-upgraded problem. Users won't be upgrading ejb3-core while neglecting to update ejb3-proxy or ejb3-common.
3) We can do away with the explicit dependencies upon the client classifier JARs:
<version.org.jboss.ejb3>1.0.0</version.org.jboss.ejb3> < This one stays
| <version.org.jboss.ejb3.common.client>1.0.0</version.org.jboss.ejb3.common.client>
| <version.org.jboss.ejb3.core.client>1.0.0</version.org.jboss.ejb3.core.client>
| <version.org.jboss.ejb3.proxy.client>1.0.0</version.org.jboss.ejb3.proxy.client>
| <version.org.jboss.ejb3.proxy.clustered.client>1.0.0</version.org.jboss.ejb3.proxy.clustered.client>
| <version.org.jboss.ejb3.security.client>1.0.0</version.org.jboss.ejb3.security.client>
Refactoring Required
In order to implement this, each component must have a dedicated namespace, ie. "org.jboss.ejb3.core" that doesn't conflict anywhere else. Otherwise there will be overwrites when we pack everything into one assembly. Take for instance in ejb3-core:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/...
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206230#4206230
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206230
15 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Configure a queue to be ordering aware
by timfox
So.. I'm struggling a bit here to see where this thread is going.
Let me try and piece it together.
The way the messaging ordering is currently implemented in JBM is messages are ordered when they hit the server. This is the way it works/will work in JBM 2.0.
Ordering messages by adding a time stamp on the *client* is not something I have heard of before, and I do not know of any other messaging systems that implement it that way.
Using a timestamp from the client would have issues with clock synchronization on the client. The differences between timings on clients would probably far outweigh the time taken to send a message from client to server, thus rendering it pointless. For that reason, that option does not seem worth pursuing.
There seems to be another issue on this thread regarding how this functionality is configured - whether the queue is configured as "ordered", or whether this is done on the connection factory.
This second issue seems unrelated to whether we use timestamp from the client or order on the server.
As I mentioned in my previous post I would prefer to configure on the connection factory since this is more consistent with JBM 2.0 and also does not restrict the entire queue to be "strictly" ordered only.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206213#4206213
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206213
15 years, 2 months