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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by ovidiu.feodorov＠jboss.com

OK. Let's store non-essential JMS-related attributes as core headers. One observation, though: Tim wrote : | Ovidiu wrote : This is what migration utilities are for. We won't have to live forever with it, we will just have to go through the trouble of writing a migration tool. We need to do this while migrating from 1.0 to 1.2 anyway. | We don't need this for 1.2 since we have specifically said no compatibility until after 1.2. This is why it needs to be done now. | Well, we do. For people who want to migrate from 1.0 to 1.2 and have persistent messages in the database. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012076#4012076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012076

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: http://jira.jboss.org/jira/browse/JBMESSAGING-808 - Fail

by clebert.suconic＠jboss.com

I'm about to commit the fix for http://jira.jboss.org/jira/browse/JBMESSAGING-809 But I realized something.. If I disable the retry detection (I mean... the query to verify the duplication). I get a PrimaryKey duplication exception... but the JDBCPersistentManager can always perform the update after a retry: I don't have any other thread receiving messages (the receive would happen afterwards the send is completed). I don't know what would delete the reference allowing the retry to work. 11:23:01,267 WARN @WorkerThread#1[127.0.0.1:45094] [JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1 | java.sql.BatchUpdateException: Duplicate entry '10-4353' for key 1 | at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:648) | at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:517) | at org.jboss.messaging.core.plugin.JDBCPersistenceManager.updateWithRetry(JDBCPersistenceManager.java:3454) | at org.jboss.messaging.core.plugin.JDBCPersistenceManager.updateWithRetryBatch(JDBCPersistenceManager.java:3337) | at org.jboss.messaging.core.plugin.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:2021) | at org.jboss.messaging.core.plugin.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:3709) | at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:201) | at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:436) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:99) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) | at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java) | at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:81) | at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:125) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:715) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:553) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:378) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:158) | 11:23:01,268 WARN @WorkerThread#1[127.0.0.1:45094] [JDBCPersistenceManager] Trying again after a pause | 11:23:01,765 WARN @WorkerThread#1[127.0.0.1:45094] [JDBCPersistenceManager] Update worked after retry | 11:23:01,766 TRACE @WorkerThread#1[127.0.0.1:45094] [JDBCPersistenceManager] Batch update INSERT INTO JMS_MESSAGE_REFERENCE (CHANNELID, MESSAGEID, TRANSACTIONID, STATE, ORD, PAGE_ORD, DELIVERYCOUNT, RELIABLE, SCHED_DELIVERY) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?), inserted | total of 0 rows | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012074#4012074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012074

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FYI: Latest ClassInfo changes.

by alesj

Ok, I'll add the static notion to BeanInfo. Should I remove the loose modifier strictness in Config method lookup? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012065#4012065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012065

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FYI: Latest ClassInfo changes.

by adrian＠jboss.org

I don't see a problem with having a seperate invokeStatic() that does the plumbing for you to make things easy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012058#4012058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012058

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FYI: Latest ClassInfo changes.

by adrian＠jboss.org

That doesn't look very good. You don't want to invoke a static method on a bean by mistake. I'd rather see it search for a static method only if the "bean" parameter is null. But then these methods should really be throwing an exception if you pass a null bean. If you really want to invoke a static method, you should be using beanInfo.getClassInfo() since you are no longer in the bean abstraction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012056#4012056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012056

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

Also bear in mind that JBoss MQ, does not store the jms headers in separate columns, so it's not as if people who are used to JBossMQ will be losing out: JBosMQ: | CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, \ | DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1), \ | MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) ) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012050#4012050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012050

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FYI: Latest ClassInfo changes.

by alesj

"adrian(a)jboss.org" wrote : | Only the constructor is supported by the BeanInfo. I had to loosen this - added 'boolean strict' to Config.getMethodJoinpoint - in order to support Scott's factory construction in JavaBean2. See AbstractBeanInfo.invoke. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012048#4012048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012048

19 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Creating a subversion trunks folder in JBoss Common

by pgier

I noticed that the trunks folder does not work when accessing svn through the anonymous URL because the aliases are all pointing to the https url. Do we need to have a separate anonymous URL? I've set up subversion in the past where read access is anonymous, but when you try to commit, you are prompted for a password. This way you can have both types of access without 2 URLs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012043#4012043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012043

19 years, 2 months

1
0
0 / 0

[Design of JBossXB] - ValueAdapter not getting invoked for a top level type.

by adrian＠jboss.org

I fixed a problem I found where if you define a ValueAdapter for a type it doesn't get invoked when the type is associated with the top level element. See TopLevelValueAdapterUnitTestCase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012031#4012031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012031

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: commands & EJB 3

by tom.baeyens＠jboss.com

just checked JACC. this is my current line of thinking: a AuthorizationService should be configurable. this service knows how to check permissions. there is already such service in the core sources. not currently used though :-) now when a command is presented to the command execution service, it should check the jbpmContext for the presence of a AuthorizationService. If such a service is present, the command execution service creates a CommandPermission and passes the command-to-be-executed in the constructor of the CommandPermission. Then, the authorization service is asked to check this permission. Now, the authorization service can still decide to map the command to specific permissions. e.g. One impl of the authorization service could map the commands to a set of roles and use jacc EJBRoleRefPermission's or WebRoleRefPermission's before it delegates the authorization check to AccessControlContext or SecurityManager. makes sense ? this approach also allows for the default set up to be without any authorization service and hence without any authorization. easy to get going. but it also allows for flexible authorization based on the current java standards if desired. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012027#4012027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012027

19 years, 2 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 February 2007