[Design of JBoss Build System] - Re: Maven 2.0 - single module and minimal server build
by c.vidal
Hi guys,
If I may, what's not supported is the following:
| /root
| pom.xml
| /module1
| pom.xml
| /module2
| pom.xml
|
This is the standard Maven 2 layout, but if you run mvn eclipse:eclipse at the root, it will generate the following which is not supported by eclipse:
| /root
| .project
| .classpath
| pom.xml
| /module1
| .project
| .classpath
| pom.xml
| /module2
| .project
| .classpath
| pom.xml
|
That's the nested kind of projects that eclipse doesn't support.
Whereas, the following alternative (known as "flat" in the M2 doc) is a safe layout:
| /root
| /root
| pom.xml
| /module1
| pom.xml
| /module2
| pom.xml
|
Because if you run mvn eclipse:eclipse at the root, it will generate the following which is supported by eclipse:
| /root
| /root
| .project
| .classpath
| pom.xml
| /module1
| .project
| .classpath
| pom.xml
| /module2
| .project
| .classpath
| pom.xml
|
For more information, here is the Maven 2 documentation:
http://maven.apache.org/guides/mini/guide-ide-eclipse.html
By the way, I'm really glad that you guys are looking into migrating the JBoss build system to Maven 2. As a long time Maven (1 and 2) user and a JBossAS afficionados, it has always been tricky to use JBoss libraries from a Maven 2 project (and before Maven 1). Such a move will make things a lot easier !
Is there a road map regarding that migration plan ?
Cheers
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958076#3958076
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958076
19 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Session recovery on rollback
by timfox
Point taken, the timing isn't important, but my understanding is the order is.
So if I receive messages A, B, C then rollback I should receive A, B, C.
The only exception to this if some of those messages have since expired or higher priority messages have arrived, in all other cases the order must be preserved. Is this correct?
In JBossMQ SpySession there is this comment:
"// Restart the delivery sequence including all unacknowledged messages
// that had
// been previously delivered. Redelivered messages do not have to be
// delivered
// in exactly their original delivery order."
Which seems to conflict with what the spec says.. although I guess I'm misinterpreting it wrong, although not sure where :( I would never make a good lawyer...
Perhaps I am confusing the order of receipt of the messages with the order of delivery of the messages.
E.g.
If I received A, B, C then rolled back and then received
A, D, B, C, E
then the delivery order is still preserved (A, B, C) it's just they're interleaved with D and E.
??
JMS1.1 4.4.11:
"In effect, the session?s series of delivered messages
is reset to the point after its last acknowledged message. The messages it now
delivers may be different from those that were originally delivered due to
message expiration and the arrival of higher-priority messages."
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958073#3958073
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958073
19 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Session recovery on rollback
by adrian@jboss.org
That's twice you've stated a non-requrement in the spec.
The only time the spec mentions anything related to the *timing* of
redelivery is when dealing with runtime exceptions thrown
by message listeners in AUTO/DUPS_OK acknowledge mode:
JMS1.1 - 4.5.2
"
The result of a listener throwing a RuntimeException depends on the session?s
acknowledgment mode.
? AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message
will be immediately redelivered. The number of times a JMS provider will
redeliver the same message before giving up is provider-dependent. The
JMSRedelivered message header field will be set for a message redelivered
under these circumstances.
"
Since this part of the spec is defines something that is non-portable
behaviour "provider-dependent", I don't see why you are trying to
expend this to rest of the JMS spec.
In fact, if your interpretation was true, JBossMQ (and other jms
providers) would not be allowed to have the "redelivery delay"
feature that stops cpu loops in the event of a broken listener/subscriber.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958066#3958066
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958066
19 years, 8 months