Re: [Quickfixj-users] RES: separating custom messages

[Brad H. <Bra...@gb...>]

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