Adding request listener programmatic to QServer
PRASAD KUMBHARE
I am starting QServer programmatic in my code. My design is such that
user mention server port to use , request listener to use in one xml
file (not in server.xml). So before starting QServer, I set port
number to that server which I have method to set on QServer. I also
want to set request listener to QServer. But I don't find a way to do
this. I also looked at code of QServer and looks like no way is
offered to do so.
Can anybody already came across these type of requirement and done
anything about it?
You help is highly appreciated.
Thanks.
Prasad Kumbhare
Mark Salter
> I am starting QServer programmatic in my code. My design is such that
> user mention server port to use , request listener to use in one xml
> file (not in server.xml). So before starting QServer, I set port
> number to that server which I have method to set on QServer. I also
> want to set request listener to QServer. But I don't find a way to do
> this. I also looked at code of QServer and looks like no way is
> offered to do so.
You are almost fighting the 'Q' approach and this is causing your
struggling.
May I check if you have tried to create an instance of Q2 and allowed it
to control and dispatch the QBeans from xml files as it was intended to
do; as described in the Programmers Guide?
What caused you to take this approach - it feels an odd way to try to me
anyway?
If you want to do everything from code, then you are probably best
advised to use the jPOS components directly (like ISOServer), rather
than try to instance and interact with the QBeans that themselves
interact with lower level components. To try to do this *outside* of a
Q2/jpos-ee environment is I have to suspect doomed to fail.
Is there a good reason for your current approach?
--
Mark
Prasad Kumbhare
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
Mark Salter
> So trying to build a single XML file that developer of each project
> would modify and use this customized JPOS component for integration.
just secure the files against the users you don't want to be able to
change them? I would trust your version or source control to allow
tracing of 'culprits' and if a developer busts the environment, just
accept that as possibly ok - unless it is 'production'?
N.B. If it is a production/live system you are trying to protect in this
manner, I (and you should) have other worries; like how did the
developers get anywhere near it 8).
> Can you please advise.
Suggestions:-
1. Have your code use the jPOS components directly, read in the config
or properties file (simpler?) and apply the attributes from the config
to the components. Perhaps the property name could identify the
instance (name?) and value, but you would still need to derive the
method to pass the value into.
2. Expose the attributes you want them to be able to change in separate
files in a separate location and pull them into the Q2 file via xml
*include* - there was some fairly recent discussion on this mailing list.
3. Let the developers 'play', control the xml files under the same
facility as your source to permit recovery. Developers often break
things initially, but then in my world, it is their job to fix or
improve everything they broke.?
There may be other ways, but I would personally use Q2/jpos-ee as is and
tell the developers they have to fix everything they break or are not
allowed to change anything (secure the files).
--
Mark