headers
Martín Cabrera | 3 May 2005 23:02
Picon
Favicon

AuthorizationTransaction class example

Hi all;

Does somebody knows where can I find an example that uses the
AuthorizationTransaction class?

Thanks in advance.
Regards.

Martín.

Martín Cabrera
Chief System Architect
IT Department
Abitab S.A.
Montevideo – Uruguay
Phone: 598-2-9245825 ext. 456
Fax: 598-2-9245825 ext. 560
Mobile: 598-99-639094
martin.cabrera@...
www.abitab.com.uy

--

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.1 - Release Date: 02/05/2005
Permalink | Reply | 2 comments |
headers
Alejandro Revilla | 4 May 2005 00:20
Favicon
Gravatar

Re: AuthorizationTransaction class example

> 
> Does somebody knows where can I find an example that uses the
> AuthorizationTransaction class?
> 
These classes are 'parameters' passed to specific certified
CardAgent implementations, but those are not part of the OS offering,
specially because most of them are proprietary and specific to 
different acquirers.

The rationale behind this scheme is to provide an engine where
acquirers could create their own agents and provide them either 
in source or binary form to retailers (or its POS provider).
Permalink | Reply | 1 comment |
headers
Martín Cabrera | 4 May 2005 15:45
Picon
Favicon

RE: AuthorizationTransaction class example

thank you.

Martín.

   _____  

De: jpos-dev@...
[mailto:jpos-dev@...] En nombre de
Alejandro Revilla
Enviado el: martes, 03 de mayo de 2005 19:20
Para: jpos-dev@...
Asunto: Re: [jpos-dev] AuthorizationTransaction class example

> 
> Does somebody knows where can I find an example that uses the
> AuthorizationTransaction class?
> 
These classes are 'parameters' passed to specific certified
CardAgent implementations, but those are not part of the OS offering,
specially because most of them are proprietary and specific to 
different acquirers.

The rationale behind this scheme is to provide an engine where
acquirers could create their own agents and provide them either 
in source or binary form to retailers (or its POS provider).

   _____  

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
afedoren | 5 May 2005 09:12
Picon
Favicon

Configuration property names

Hello,

I would like to have method that returns all
property names in org.jpos.core.Configuration like :

public String[] getPropertyNames() ;

or

public Enumeration propertyNames() ;  // like in java.util.Properties

Thank you.

Alexander
Permalink | Reply | 5 comments |
headers
Alejandro Revilla | 5 May 2005 09:22
Favicon
Gravatar

Re: Configuration property names

While I'm not keen to change the interface, we can
add a getProperties() method to SimpleConfiguration,
would that be okay?

> 
> I would like to have method that returns all
> property names in org.jpos.core.Configuration like :
> 
> public String[] getPropertyNames() ;
> 
> or
> 
> public Enumeration propertyNames() ;  // like in java.util.Properties
> 
> 
> Thank you.
> 
> 
> Alexander
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
afedoren | 5 May 2005 09:53
Picon
Favicon

Re: Configuration property names

--- In jpos-dev@..., Alejandro Revilla <apr <at> j...> wrote:
> While I'm not keen to change the interface, we can
> add a getProperties() method to SimpleConfiguration,
> would that be okay?

Why not ?

Developers prefer to work with interfaces rather than with
implementation classes . SimpleConfiguration is just simple
implementation, anybody
can use another implementation based on interface.

In addition, "jpos" has only 2 classes that implement Configuration :
SimpleConfiguration and SubConfiguration  - not so much to change.

It would be nice to introduce such interface method from the very
beginning . I think it is very useful.

> 
> > 
> > I would like to have method that returns all
> > property names in org.jpos.core.Configuration like :
> > 
> > public String[] getPropertyNames() ;
> > 
> > or
> > 
> > public Enumeration propertyNames() ;  // like in java.util.Properties
> > 
> >
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alejandro Revilla | 5 May 2005 10:35
Favicon
Gravatar

Re: Re: Configuration property names


Although our current implementation is backed by a java.util.Properties
object, that's not mandated by the interface, and I think that's
actually good. I know of people using JDBC to back their configurations
(kind of SQLConfiguration), etc.

If we are to do it at the interface level, I think we'd do better
returning an Enumeration or List of property names as you've initially
suggested... this would give more flexibility to people implementing
Configuration.
Permalink | Reply | 2 comments |
headers
afedoren | 5 May 2005 11:32
Picon
Favicon

Re: Configuration property names

--- In jpos-dev@..., Alejandro Revilla <apr <at> j...> wrote:
> 
> Although our current implementation is backed by a java.util.Properties
> object, that's not mandated by the interface, and I think that's
> actually good. I know of people using JDBC to back their configurations
> (kind of SQLConfiguration), etc.
> 

Yes, sure . Maybe it is better to send notify to some component to
handle configuration changes instead of managing it in
code with concrete impl. The idea is not to know about particular
Configuration implementation to make jpos code reusable and flexible .

Here example :

/////////////////////////////////////////

My connector saves state : 

public class TpsIsoMux
    extends ISOMUX
    implements Stopable, Configurable, TpsIsoMuxMBean,
               GenericConnector, Financial, AuditEntityInterface ,
               ReadableConfigurable
{

  ........

  public void save() {
    ConnectorConfigurator.getInstanse().save( this );
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alejandro Revilla | 5 May 2005 14:01
Favicon
Gravatar

Re: Re: Configuration property names

> 
> Yes, sure . Maybe it is better to send notify to some component to
> handle configuration changes instead of managing it in
> code with concrete impl. The idea is not to know about particular
> Configuration implementation to make jpos code reusable and flexible .
> 
That direction raises a few alarms regarding possible leaks in QSP
and Q2 redeployments, We've tried to keep it as simple as possible,
just pushing the configuration into Configurable and ReConfigurable 
objects, but nothing stops you from extending Configuration with your 
own set of interfaces and implementations, including support for
configuration event listeners.

--Alejandro
Permalink | Reply | 0 comments |
headers
pie_fed | 5 May 2005 18:24
Picon
Favicon

Enhancement request: ability to obfuscate sensitive fields in ISOMsg.dump(..)

I have been logging ISOMsg.dump(..) to help me debug and build my
messages, and I would like to be able to include these dumps on my
production systems logs in debug mode, if there turns out to be a
problem somewhere. The problem is that I'm not allowed to have
sensitive information (credit card numbers, expiry dates, track data)
show up in my production logs, even in "debug" mode.

My enhancement request, then, is to add to ISOMsg:
void dump( PrintStream p, String indent, java.util.Set obfuscatedFields)
or, since you don't use Integers for set(..), maybe
void dump( PrintStream p, String indent, int[] obfuscatedFields)

The values of fields could then get replaced with "***" or similar - I
don't even want to be able to know the length.

Please think about it. If you like the idea, I'd be willing to
implement it myself and supply a patch, just let me know what method
signature you prefer.

Cheers,
Zac
Permalink | Reply | 1 comment |

Gmane