[ 
https://issues.apache.org/jira/browse/CAMEL-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134638#comment-13134638
 ] 

Eliot Chen edited comment on CAMEL-4568 at 10/24/11 11:41 PM:
--------------------------------------------------------------

Hi Willem,

Thanks for looking into this.

I don't think I have made our requirements clear.  What we need is being able 
to use SLF4JLog as the logFactory and at the same time use Jdbc as the 
MessageStoreFactory (we do NOT want to use jdbc logFactory).

The code intends to, as you mentioned, allow configuration of ONE logFactory 
and ONE MessageStoreFactory (defines where messages are persisted for session 
management). That is actually in line with what we want. 

However, because both logFactory and MessageStoreFactory share the same 
settings - JdbcDriver, it assumes that we intend to use jdbc logFactory even 
though the intention was to use jdbc for MessageStore hence it skipped the 
SLF4J setting (refer to isSL4JLog() method).

>From what I observed, it does not throw an exception when more than one 
>logFactoies are configured, it just skipped the logFactory setting once there 
>is already one logFactory configured (see inferLogFactory() method).

That is why I proposed to switch those two lines in the code 

298: isJdbcLog(settings, impliedLogFactories);
299: isSL4JLog(settings, impliedLogFactories);

By switching those two lines, SL4J setting will be picked up as logFactory and 
jdbc setting will be ignored. However, jdbc setting will still be picked up as 
the MessageStoreFactory. Another solution is to have different jdbc setting for 
logFactory and MessageStoreFactory.

                
      was (Author: eliotc):
    Hi Willem,

Thanks for looking into this.

I don't think I have made our requirements clear.  What we need is being able 
to use SLF4JLog as the logFactory and at the same time use Jdbc as the 
MessageStoreFactory (we do NOT want to use jdbc logFactory).

The code intends to, as you mentioned, allow configuration of ONE logFactory 
and ONE MessageStoreFactory (defines where messages are persisted for session 
management). That is actually in line with what we want. 
However, because both logFactory and MessageStoreFactory share the same 
settings - JdbcDriver, it assumes that we intend to use jdbc logFactory even 
though the intention was to use jdbc for MessageStore hence it skipped the 
SLF4J setting (refer to isSL4JLog() method).

>From what I observed, it does not throw an exception when more than one 
>logFactoies are configured, it just skipped the logFactory setting once there 
>is already one logFactory configured (see inferLogFactory() method).

That is why I proposed to switch those two lines in the code 

298: isJdbcLog(settings, impliedLogFactories);
299: isSL4JLog(settings, impliedLogFactories);

By switching those two lines, SL4J setting will be picked up as logFactory and 
jdbc setting will be ignored. However, jdbc setting will still be picked up as 
the MessageStoreFactory. Another solution is to have different jdbc setting for 
logFactory and MessageStoreFactory.

                  
> SLF4JLog does not work with JdbcDriver for Quickfix/J
> -----------------------------------------------------
>
>                 Key: CAMEL-4568
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4568
>             Project: Camel
>          Issue Type: Bug
>    Affects Versions: 2.8.0
>            Reporter: Eliot Chen
>            Assignee: Willem Jiang
>              Labels: Quickfix
>             Fix For: 2.8.3, 2.9.0
>
>
> I discovered that to use SLF4J log, JdbcDriver cannot be present in the 
> Quickfix/J config file. Otherwise, the default LogFactory - ScreenLogFactory 
> will be used. We need JdbcDriver setting as it is used for persisting FIX 
> messages into database for FIX session management.
> After debugging the code, I found out that this could be fixed by swapping 
> those two lines in QuickfixjEngine.java
> 298: isJdbcLog(settings, impliedLogFactories);
> 299: isSL4JLog(settings, impliedLogFactories);
> Can we please have this fixed for the next release?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to