Menu
▾
▴
quickfixj-users
|
From: Lev G. <lev...@db...> - 2007-07-02 17:05:46
|
Hello all. Here is the situation. Suppose I add some more custom messages, components, fields to one of the resource .xml files, say FIX44.xml. What I want to do now, is separate into another package hierarchy the stuff that's been changed/added by the compilation process, so that I can use the original quickfix.jar as is and make the added/changed classes part of my application. Has anyone had any experience similar to this? Lev Grevnin Rates IT work: 7 495 644 3191, mobile: 7 917 504 3004 --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. |
|
From: Alexander G. <ago...@ac...> - 2007-07-02 17:56:28
|
Hi, I'm not sure that I understood the question, but you can set the = DataDictionary=3Dmy_fix44.xml in the quickfix.cfg, put the my_fix44.xml = into a place accessible by the classpath, and pack the related classes = together with you application.=20 ----- Original Message -----=20 From: Lev Grevnin=20 To: qui...@li...=20 Cc: Andrey Tapekha=20 Sent: Monday, July 02, 2007 7:05 PM Subject: [Quickfixj-users] separating custom messages QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ -------------------------------------------------------------------------= ----- Hello all.=20 Here is the situation. Suppose I add some more custom messages, = components, fields to one of the resource .xml files, say FIX44.xml. = What I want to do now, is separate into another package hierarchy the = stuff that's been changed/added by the compilation process, so that I = can use the original quickfix.jar as is and make the added/changed = classes part of my application. Has anyone had any experience similar to this? =20 Lev Grevnin Rates IT work: 7 495 644 3191, mobile: 7 917 504 3004 =20 --- This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in = error) please notify the sender immediately and delete this e-mail. Any = unauthorized copying, disclosure or distribution of the material in this = e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for = additional EU corporate and regulatory disclosures. -------------------------------------------------------------------------= ----- = -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -------------------------------------------------------------------------= ----- _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Toli K. <to...@ma...> - 2007-07-02 18:15:49
|
Lev, Alexander is right - that's exactly what we do in our platform, here's a link to our Spring config file if you need an example: http://trac.marketcetera.org/trac.fcgi/browser/platform/trunk/oms/src/main/resources/quickfixj.xml#L50 and we keep our custom fields in http://trac.marketcetera.org/trac.fcgi/browser/platform/trunk/core/src/main/java/org/marketcetera/quickfix/customfields The next version of QFJ will have separate quickfxj-core and quicfkixj-msg-fix4x jar files, so it'll be a little cleaner and easier to do what you are trying to accomplish. On 7/2/07, Alexander Gorbachev <ago...@ac...> wrote: > QuickFIX/J Documentation: > http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I'm not sure that I understood the question, but you can set the > DataDictionary=my_fix44.xml in the quickfix.cfg, put the my_fix44.xml into a > place accessible by the classpath, and pack the related classes together > with you application. > > > ----- Original Message ----- > > From: Lev Grevnin > To: qui...@li... > Cc: Andrey Tapekha > Sent: Monday, July 02, 2007 7:05 PM > Subject: [Quickfixj-users] separating custom messages > > QuickFIX/J Documentation: > http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > ________________________________ > > > Hello all. > > Here is the situation. Suppose I add some more custom messages, components, > fields to one of the resource .xml files, say FIX44.xml. What I want to do > now, is separate into another package hierarchy the stuff that's been > changed/added by the compilation process, so that I can use the original > quickfix.jar as is and make the added/changed classes part of my > application. > > Has anyone had any experience similar to this? > > > > Lev Grevnin > Rates IT > work: 7 495 644 3191, mobile: 7 917 504 3004 > -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Danilo T. <tu...@po...> - 2007-07-02 18:33:52
|
> The next version of QFJ will have separate quickfxj-core and > quicfkixj-msg-fix4x jar files. This is really good news. Where will be the field classes? I wanted to use quickfixj in an applet, but a 4Mb jar is way too much! I was trying to build a jar with just the core, but without much success. -- Danilo |
|
From: Brad H. <Bra...@gb...> - 2007-07-02 22:46:39
|
Doesn't the core have a runtime dependency on the generated messages classes and fields anyway? Eg, if you receive a fix 4.4 message you'll need the corresponding fix 4.4 generated message class on the classpath, which in turn will depend on any fields it uses. Or does it know to use generic Message if the classes aren't found? I'm actually relying on this behaviour at the moment. The MessageCracker seemed a bit redundant (giant elseif + casts IIRC) so instead of using that my fromApp does instanceof checks and casts on the message types I expect to receive. Regards, Brad.=20 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: Tuesday, 3 July 2007 5:05 AM To: qui...@li... Subject: Re: [Quickfixj-users] RES: separating custom messages QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > >> The next version of QFJ will have separate quickfxj-core and=20 >> quicfkixj-msg-fix4x jar files. > > This is really good news. > Where will be the field classes? > > I wanted to use quickfixj in an applet, but a 4Mb jar is way too much! > I was trying to build a jar with just the core, but without much success. The field classes were stored in the core library since they are shared by the message JAR files and by code in the core library itself (Session, for example). QFJ 1.2.0 will be released within the next few days, but there are other packaging options we could discuss for future releases that would reduce the size of the core library even further. The core could be completely decoupled from the generated code. The core classes actually only use a small number of tag constants from the generated fields. If we eliminated the dependencies on these constants, wee could then remove the generated fields from the core library and either create a separate library for them or include them redundantly in the message JAR files (to make the message JARs standalone). This should make the core library very small. In response to the earlier question about Java packages... The QFJ 1.2.0 code generation supports generation of classes into any Java package and supports generated FIX version-specific packages of fields (instead of the single quickfix.fields package currently generated by default). However, for backwards compatibility the default code generation strategy hasn't changed. There will be more details with the 1.2.0 release. Regards, Steve ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Steve B. <st...@te...> - 2007-07-03 00:17:37
|
> Doesn't the core have a runtime dependency on the generated messages > classes and fields anyway? Eg, if you receive a fix 4.4 message you'll > need the corresponding fix 4.4 generated message class on the classpath, > which in turn will depend on any fields it uses. Or does it know to use > generic Message if the classes aren't found? That's true if you are using the DefaultMessageFactory. Even though this factory implementation is in the core library, I don't really consider it a core class. At some point, I'd like to create the notion of a message "module", a JAR file that has meta-data describing it's default data dictionary and message factory. The module could be specified in the settings instead of the data dictionary or a module could be specified with an overridden custom dictionary file. It's just a rough idea right now, but I'd like to eventually have ready-to-go message modules for various exchanges. > I'm actually relying on this behaviour at the moment. The > MessageCracker seemed a bit redundant (giant elseif + casts IIRC) so > instead of using that my fromApp does instanceof checks and casts on the > message types I expect to receive. I don't usually use MessageCrackers either. Some of these parts of QFJ are remnants of the C++ JNI implementation. Steve |
|
From: Brad H. <Bra...@gb...> - 2007-07-03 03:08:56
|
Makes perfect sense, thanks :)=20 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: Tuesday, 3 July 2007 10:17 AM To: qui...@li... Subject: Re: [Quickfixj-users] RES: separating custom messages QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ > Doesn't the core have a runtime dependency on the generated messages=20 > classes and fields anyway? Eg, if you receive a fix 4.4 message=20 > you'll need the corresponding fix 4.4 generated message class on the=20 > classpath, which in turn will depend on any fields it uses. Or does=20 > it know to use generic Message if the classes aren't found? That's true if you are using the DefaultMessageFactory. Even though this factory implementation is in the core library, I don't really consider it a core class. At some point, I'd like to create the notion of a message "module", a JAR file that has meta-data describing it's default data dictionary and message factory. The module could be specified in the settings instead of the data dictionary or a module could be specified with an overridden custom dictionary file. It's just a rough idea right now, but I'd like to eventually have ready-to-go message modules for various exchanges. =20 > I'm actually relying on this behaviour at the moment. The=20 > MessageCracker seemed a bit redundant (giant elseif + casts IIRC) so=20 > instead of using that my fromApp does instanceof checks and casts on=20 > the message types I expect to receive. I don't usually use MessageCrackers either. Some of these parts of QFJ are remnants of the C++ JNI implementation. Steve ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Toli K. <to...@ma...> - 2007-07-02 18:47:32
|
Danilo, quickfixj-core.jar will include quickfix.field.* classes (and all the other non-generated classes). quickfixj-msg-4x.jar will have the generated messages, with each jar having the quickfix.fix4x package corresponding to each version. Here are the sizes (based on the current HEAD of SVN build): quickfixj-core.jar 750K quickfixj-msg-fix40.jar 85K quickfixj-msg-fix41.jar 116K quickfixj-msg-fix42.jar 268K quickfixj-msg-fix43.jar 757K quickfixj-msg-fix44.jar 2M > This is really good news. > Where will be the field classes? > > I wanted to use quickfixj in an applet, but a 4Mb jar is way too much! > I was trying to build a jar with just the core, but without much success. -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Danilo T. <tu...@po...> - 2007-07-02 18:53:29
|
> Here are the sizes (based on the current HEAD of SVN build): > quickfixj-core.jar 750K > quickfixj-msg-fix40.jar 85K > quickfixj-msg-fix41.jar 116K > quickfixj-msg-fix42.jar 268K > quickfixj-msg-fix43.jar 757K > quickfixj-msg-fix44.jar 2M The xml of each version is in the separate jar, right? > quickfixj-core.jar will include quickfix.field.* classes (and > all the other non-generated classes). What I really wanted to achieve was an even smaller package, with just a enumeration of the fields, instead of a class per field. But maybe this is going away from the quickfixj concept, doing things in a different way. -- Danilo |
|
From: Steve B. <st...@te...> - 2007-07-02 19:04:59
|
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > >> The next version of QFJ will have separate quickfxj-core and >> quicfkixj-msg-fix4x jar files. > > This is really good news. > Where will be the field classes? > > I wanted to use quickfixj in an applet, but a 4Mb jar is way too much! > I was trying to build a jar with just the core, but without much success. The field classes were stored in the core library since they are shared by the message JAR files and by code in the core library itself (Session, for example). QFJ 1.2.0 will be released within the next few days, but there are other packaging options we could discuss for future releases that would reduce the size of the core library even further. The core could be completely decoupled from the generated code. The core classes actually only use a small number of tag constants from the generated fields. If we eliminated the dependencies on these constants, wee could then remove the generated fields from the core library and either create a separate library for them or include them redundantly in the message JAR files (to make the message JARs standalone). This should make the core library very small. In response to the earlier question about Java packages... The QFJ 1.2.0 code generation supports generation of classes into any Java package and supports generated FIX version-specific packages of fields (instead of the single quickfix.fields package currently generated by default). However, for backwards compatibility the default code generation strategy hasn't changed. There will be more details with the 1.2.0 release. Regards, Steve |
|
From: Danilo T. <tu...@po...> - 2007-07-02 19:11:14
|
> If we eliminated the dependencies on these constants, wee > could then remove the generated fields from the core > library and either create a separate library for them. I'm interested in that packaging option! -- Danilo |
|
From: Steve B. <st...@te...> - 2007-07-02 19:19:13
|
> The xml of each version is in the separate jar, right? Yes. >> quickfixj-core.jar will include quickfix.field.* classes (and >> all the other non-generated classes). > > What I really wanted to achieve was an even smaller package, with just a > enumeration of the fields, instead of a class per field. But maybe this is > going away from the quickfixj concept, doing things in a different way. It's possible but it will require more work. If you'd like you can enter an RFE for this and we can try to work it in as time permits. It looks like a core JAR without the fields would be about 250K. You could reduce this further by eliminating classes like store and log implementations you don't need for your applet. I'm guessing you could reduce the library size to about 150K without a lot of difficulty. If you don't mind me asking, is this an applet for an open source product? Regards, Steve |
|
From: Danilo T. <tu...@po...> - 2007-07-02 19:26:55
|
> It looks like a core JAR without the fields would be about > 250K. You could reduce this further by eliminating classes > like store and log implementations you don't need for your > applet. I'm guessing you could reduce the library size to > about 150K without a lot of difficulty. That's what I'm trying to do, but right now I have some other things in my to-do list. > If you don't mind me asking, is this an applet for an open source > product? No, it's closed, sorry. Regards, Danilo |
Thanks for helping keep SourceForge clean.
X