Quantcast

User defined fields, best approach to crack

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

User defined fields, best approach to crack

dipeg
Hello

we're building an application using FIX44. Application connects to two different brokers, both having data dictionaries with fields numbers > 5000

Right now, we extract fields by field number. Looks like all fields up to 9999 are standard anyway, where fields 5000-9999 are custom fields, but only in the sense that these are officially registered tags, contributed by dealers/brokers or banks.

So it looks like all fields up to 9999 are "standard" and in all Fix Messages, field 6617 means always "SecondaryOrderId"?

Or is it better to use quickfix-core and decicated packages with fields, compiled with data dictionary of dealer/broker and then extract fields use the types (generated classes?).

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

On 09/21/2015 08:40 AM, dipeg wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello
>
> we're building an application using FIX44. Application connects to two
> different brokers, both having data dictionaries with fields numbers > 5000
>
> Right now, we extract fields by field number. Looks like all fields up to
> 9999 are standard anyway, where fields 5000-9999 are custom fields, but only
> in the sense that these are officially registered tags, contributed by
> dealers/brokers or banks.
>
> So it looks like all fields up to 9999 are "standard" and in all Fix
> Messages, field 6617 means always "SecondaryOrderId"?
>
> Or is it better to use quickfix-core and decicated packages with fields,
> compiled with data dictionary of dealer/broker and then extract fields use
> the types (generated classes?).
>
>
>
>
>
> --
> View this message in context: http://quickfix-j.364392.n2.nabble.com/User-defined-fields-best-approach-to-crack-tp7579224.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884 +1.541.306.6556
http://www.marketcetera.org


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Grant Birchmeier
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I personally prefer to regenerate the QF/j source with my custom DD xml and rebuild, and I highly recommend that everyone do that.

It's a little more work upfront, but it provides more robust validation, and also easier coding because your auto-completes can actually find custom the classes and tags.  And you won't have error caused by accidentally using the wrong tag number (because you'll use tag-name constants).

On Mon, Sep 21, 2015 at 11:00 AM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

On 09/21/2015 08:40 AM, dipeg wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello
>
> we're building an application using FIX44. Application connects to two
> different brokers, both having data dictionaries with fields numbers > 5000
>
> Right now, we extract fields by field number. Looks like all fields up to
> 9999 are standard anyway, where fields 5000-9999 are custom fields, but only
> in the sense that these are officially registered tags, contributed by
> dealers/brokers or banks.
>
> So it looks like all fields up to 9999 are "standard" and in all Fix
> Messages, field 6617 means always "SecondaryOrderId"?
>
> Or is it better to use quickfix-core and decicated packages with fields,
> compiled with data dictionary of dealer/broker and then extract fields use
> the types (generated classes?).
>
>
>
>
>
> --
> View this message in context: http://quickfix-j.364392.n2.nabble.com/User-defined-fields-best-approach-to-crack-tp7579224.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
<a href="tel:888.868.4884" value="+18888684884">888.868.4884 <a href="tel:%2B1.541.306.6556" value="+15413066556">+1.541.306.6556
http://www.marketcetera.org


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Agreed that's the most robust approach.

On 09/21/2015 09:13 AM, Grant Birchmeier wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I personally prefer to regenerate the QF/j source with my custom DD xml and rebuild, and I highly recommend that everyone do that.

It's a little more work upfront, but it provides more robust validation, and also easier coding because your auto-completes can actually find custom the classes and tags.  And you won't have error caused by accidentally using the wrong tag number (because you'll use tag-name constants).

On Mon, Sep 21, 2015 at 11:00 AM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

On 09/21/2015 08:40 AM, dipeg wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello
>
> we're building an application using FIX44. Application connects to two
> different brokers, both having data dictionaries with fields numbers > 5000
>
> Right now, we extract fields by field number. Looks like all fields up to
> 9999 are standard anyway, where fields 5000-9999 are custom fields, but only
> in the sense that these are officially registered tags, contributed by
> dealers/brokers or banks.
>
> So it looks like all fields up to 9999 are "standard" and in all Fix
> Messages, field 6617 means always "SecondaryOrderId"?
>
> Or is it better to use quickfix-core and decicated packages with fields,
> compiled with data dictionary of dealer/broker and then extract fields use
> the types (generated classes?).
>
>
>
>
>
> --
> View this message in context: http://quickfix-j.364392.n2.nabble.com/User-defined-fields-best-approach-to-crack-tp7579224.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
<a moz-do-not-send="true" href="tel:888.868.4884" value="+18888684884">888.868.4884 <a moz-do-not-send="true" href="tel:%2B1.541.306.6556" value="+15413066556">+1.541.306.6556
http://www.marketcetera.org


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.


------------------------------------------------------------------------------


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884 +1.541.306.6556
http://www.marketcetera.org

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Robert Engels-2
In reply to this post by Grant Birchmeier
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Curious, how does that work if you have two different vendors that use the same message type, but have different fields?

Or two different vendors that have the same same user defined field, but different types (i.e. string is one, UTC in another).

We've found that it is far easier to just build custom classes for the various field and message types as needed.

We support 20+ fix connections, and a having a single monolithic jar (built from quickfixj source) to cover all of them to be unworkable.



On Mon, Sep 21, 2015 at 11:13 AM, Grant Birchmeier <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I personally prefer to regenerate the QF/j source with my custom DD xml and rebuild, and I highly recommend that everyone do that.

It's a little more work upfront, but it provides more robust validation, and also easier coding because your auto-completes can actually find custom the classes and tags.  And you won't have error caused by accidentally using the wrong tag number (because you'll use tag-name constants).

On Mon, Sep 21, 2015 at 11:00 AM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

On 09/21/2015 08:40 AM, dipeg wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello
>
> we're building an application using FIX44. Application connects to two
> different brokers, both having data dictionaries with fields numbers > 5000
>
> Right now, we extract fields by field number. Looks like all fields up to
> 9999 are standard anyway, where fields 5000-9999 are custom fields, but only
> in the sense that these are officially registered tags, contributed by
> dealers/brokers or banks.
>
> So it looks like all fields up to 9999 are "standard" and in all Fix
> Messages, field 6617 means always "SecondaryOrderId"?
>
> Or is it better to use quickfix-core and decicated packages with fields,
> compiled with data dictionary of dealer/broker and then extract fields use
> the types (generated classes?).
>
>
>
>
>
> --
> View this message in context: http://quickfix-j.364392.n2.nabble.com/User-defined-fields-best-approach-to-crack-tp7579224.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
<a href="tel:888.868.4884" value="+18888684884" target="_blank">888.868.4884 <a href="tel:%2B1.541.306.6556" value="+15413066556" target="_blank">+1.541.306.6556
http://www.marketcetera.org


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

Interested in joining the OptionsCity team? Check out our current openings and take a peek inside our offices on The Muse.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

dipeg
In reply to this post by Grant Birchmeier
Fair enough, however, given that the tag numbers are standard up to 9999 (looks like) and solution has strong QA requirements as well as UAT etc, I don't see any real benefit in compiling the sources and using the types generated from the DD.

We do validation with DataDictionary (custom DD) for incoming messages anyway ...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

dipeg
In reply to this post by Robert Engels-2
@Robert: exactly, how to handle jars for several vendors, avoiding type clashes.

To me it looks a lot safer to build some dedicated custom classes as needed (without rebuilding quickfix with two vendor DD from scratch).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Grant Birchmeier
In reply to this post by Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



My knee-jerk answer is to build a new jar for each vendor.

But then again, all my projects have been single-vendor projects.  If you have an application that needs to support multiple vendors at once, then I'm not sure what the best way would be.  Maybe keep using different QF/j builds, but try to put them in different namespaces?


On Mon, Sep 21, 2015 at 12:20 PM, Robert Engels <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Curious, how does that work if you have two different vendors that use the same message type, but have different fields?

Or two different vendors that have the same same user defined field, but different types (i.e. string is one, UTC in another).

We've found that it is far easier to just build custom classes for the various field and message types as needed.

We support 20+ fix connections, and a having a single monolithic jar (built from quickfixj source) to cover all of them to be unworkable.



On Mon, Sep 21, 2015 at 11:13 AM, Grant Birchmeier <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/



I personally prefer to regenerate the QF/j source with my custom DD xml and rebuild, and I highly recommend that everyone do that.

It's a little more work upfront, but it provides more robust validation, and also easier coding because your auto-completes can actually find custom the classes and tags.  And you won't have error caused by accidentally using the wrong tag number (because you'll use tag-name constants).

On Mon, Sep 21, 2015 at 11:00 AM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

On 09/21/2015 08:40 AM, dipeg wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello
>
> we're building an application using FIX44. Application connects to two
> different brokers, both having data dictionaries with fields numbers > 5000
>
> Right now, we extract fields by field number. Looks like all fields up to
> 9999 are standard anyway, where fields 5000-9999 are custom fields, but only
> in the sense that these are officially registered tags, contributed by
> dealers/brokers or banks.
>
> So it looks like all fields up to 9999 are "standard" and in all Fix
> Messages, field 6617 means always "SecondaryOrderId"?
>
> Or is it better to use quickfix-core and decicated packages with fields,
> compiled with data dictionary of dealer/broker and then extract fields use
> the types (generated classes?).
>
>
>
>
--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Chavez, Jose-3
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have done this before. Good way is to create vendor specific messages using the MessageCodeGenerator in QFJ.

1. Create/modify a DD file for each vendor
2. Create a class that will take the DD file, and vendor specific parameters, and generate classes. The parameters are passed to the MessageCodeGenerator. The most important parameter is the FieldPackage and MessagePackage params. These should be different for each vendor.
3. You can then package the generated class files and the DD into a jar for that vendor
4. Place the jars on the classpath, then use the generated MessageFactory from the packaged jar when creating your initiator/acceptor.
5. On message cracking, the MessageCracker should work, dependent on the proper MessageFactory being set.

- Jose

-----Original Message-----
From: Grant Birchmeier [mailto:[hidden email]]
Sent: Monday, September 21, 2015 1:36 PM
To: [hidden email]
Subject: Re: [Quickfixj-users] User defined fields, best approach to crack

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



That sounds like a better approach, but is there a way that it doesn't regenerate the common classes, or that is uses a common base class?

Meaning if Vendor B has some proprietary fields in NewOrderSingle, does it create a class like:

package vendor.A;

class NewOrderSingle extends quickfix.NewOrderSingle {
...
}

On Mon, Sep 21, 2015 at 2:38 PM, Chavez, Jose <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have done this before. Good way is to create vendor specific messages using the MessageCodeGenerator in QFJ.

1. Create/modify a DD file for each vendor
2. Create a class that will take the DD file, and vendor specific parameters, and generate classes. The parameters are passed to the MessageCodeGenerator. The most important parameter is the FieldPackage and MessagePackage params. These should be different for each vendor.
3. You can then package the generated class files and the DD into a jar for that vendor
4. Place the jars on the classpath, then use the generated MessageFactory from the packaged jar when creating your initiator/acceptor.
5. On message cracking, the MessageCracker should work, dependent on the proper MessageFactory being set.

- Jose

-----Original Message-----
From: Grant Birchmeier [mailto:[hidden email]]
Sent: Monday, September 21, 2015 1:36 PM
To: [hidden email]
Subject: Re: [Quickfixj-users] User defined fields, best approach to crack

QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

Interested in joining the OptionsCity team? Check out our current openings and take a peek inside our offices on The Muse.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Chavez, Jose-3
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


It does use a base class, though not the way you are thinking. The MessageCodeGenerator in QFJ 1.5.3 creates its own Message class:

public class com.vendor.fix.Message extends quickfix.Message {
...
}

It then creates all the message classes that extend the one above:

public class com.vendor.fix.NewOrderSingle extends com.vendor.fix.Message {
...
}

- Jose


-----Original Message-----
From: Robert Engels [mailto:[hidden email]]
Sent: Monday, September 21, 2015 2:52 PM
To: [hidden email]
Subject: Re: [Quickfixj-users] User defined fields, best approach to crack

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Robert Engels-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



So you can't have common code that works on the a base NewOrderSingle implementation...

Seems too restrictive to me vs. just rolling your own custom classes.

On Mon, Sep 21, 2015 at 3:50 PM, Chavez, Jose <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


It does use a base class, though not the way you are thinking. The MessageCodeGenerator in QFJ 1.5.3 creates its own Message class:

public class com.vendor.fix.Message extends quickfix.Message {
...
}

It then creates all the message classes that extend the one above:

public class com.vendor.fix.NewOrderSingle extends com.vendor.fix.Message {
...
}

- Jose


-----Original Message-----
From: Robert Engels [mailto:[hidden email]]
Sent: Monday, September 21, 2015 2:52 PM
To: [hidden email]
Subject: Re: [Quickfixj-users] User defined fields, best approach to crack

QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 (312) 605-4500 | F. +1 (312) 635-1751 

 

Interested in joining the OptionsCity team? Check out our current openings and take a peek inside our offices on The Muse.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Jose Chavez
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Common code wouldn't play a role in the generated class files, but rather in your quickfix.Application implementation, and MessageCracker handler methods.

If you are trying to handle all vendor messages in one implementation, then you may need to do some transformations:

@Handler
public void onMessage(com.vendorA.NewOrderSingle nosA, SessionID sessionID) {
  MyNewOrder order = transform(nosA);
  handleMyNewOrder(order);
}

@Handler
public void onMessage(com.vendorB.NewOrderSingle nosB, SessionID sessionID) {
  MyNewOrder order = transform(nosB);
  handleMyNewOrder(order);
}

- Jose

On Sep 21, 2015 3:57 PM, "Robert Engels" <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



So you can't have common code that works on the a base NewOrderSingle implementation...

Seems too restrictive to me vs. just rolling your own custom classes.

On Mon, Sep 21, 2015 at 3:50 PM, Chavez, Jose <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


It does use a base class, though not the way you are thinking. The MessageCodeGenerator in QFJ 1.5.3 creates its own Message class:

public class com.vendor.fix.Message extends quickfix.Message {
...
}

It then creates all the message classes that extend the one above:

public class com.vendor.fix.NewOrderSingle extends com.vendor.fix.Message {
...
}

- Jose


-----Original Message-----
From: Robert Engels [mailto:[hidden email]]
Sent: Monday, September 21, 2015 2:52 PM
To: [hidden email]
Subject: Re: [Quickfixj-users] User defined fields, best approach to crack

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/



------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--

Robert Engels

 

OptionsCity Software
200 W. Adams St., Suite 1010
Chicago, IL 60606

O. +1 <a href="tel:%28312%29%20605-4500" value="+13126054500" target="_blank">(312) 605-4500 | F. <a href="tel:%2B1%C2%A0%28312%29%20635-1751" value="+13126351751" target="_blank">+1 (312) 635-1751 

 

Interested in joining the OptionsCity team? Check out our current openings and take a peek inside our offices on The Muse.

 

Connect with OptionsCity at www.optionscity.com  | LinkedIn  |  Twitter  |  YouTube  |  Facebook

 

 


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User defined fields, best approach to crack

Tod Harter
In reply to this post by dipeg
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




On Mon, Sep 21, 2015 at 11:00 AM, <[hidden email]> wrote:
Message: 4
Date: Mon, 21 Sep 2015 09:00:04 -0700
From: Colin DuPlantis <[hidden email]>
Subject: Re: [Quickfixj-users] User defined fields, best approach to
        crack
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=windows-1252; format=flowed

IMO, the easiest way to go about this is to create a custom XML
dictionary for validation and retrieve custom fields by number.

I agree. You CAN produce custom versions of the QF/J jars that will allow you to use named fields (IE it will produce classes and enums for these custom fields), BUT then you can only handle one dealer per classloader. This is fine for an app that just talks to a single broker, but QF/J has a LOT of classes, and classloader gymnastics are painful, so you really don't want to be trying to load up 2 or more different versions at the same time in one app.

Using the tag numbers isn't REALLY all that painful anyway. Yes, technically its not typesafe, but frankly this sort of type safety is not THAT valuable anyway IMHO. Our product interfaces to potentially dozens of different vendors for instance, so we just go entirely by tag numbers anyway, its the only way to really create general purpose fix handling code (even so you'll need some logic per-vendor in most cases).

“Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” -Winston Churchill

"Sometimes I wonder whether the world is being run by smart people who are putting us on, or by imbeciles who really mean it." - Mark Twain

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Loading...