Discussion:
Alternate javax.smartcardio provider
Michael Traut
2013-07-16 15:03:22 UTC
Permalink
The initial release for an alternate javax.smartcardio provider is now
included in https://github.com/intarsys/smartcard-io/.

This was an interesting task that we used as a chance to review & cleanup
some API's in our basic implementation. And, unbelievable, there are still
"corner cases" that had failed up to now. Another interesting aspect was
the mapping from out "event driven" API to the blocking API of smartcardio
(and i must say i prefer the event driven one). So, even if nobody may care
of this lib, we've already gained...

For the smartcardio implementation itself we have the following state:

* Intended differences
** dedicated PCSC context for terminals, terminal and card (true
concurrency)
** waitForChange(timeout) semantics improved(?), state change is reset even
in case of timeout
** reader insertion is handled, too
** no finalizer for card!

* Open design questions
** "exclusive" card access is NOT restricted to a Java thread. We found no
technical reason for this constraint. imho this makes handling of shared
and pooled resources ugly. Next to "Only one PSCS context" this would be my
top level reason *not* to use smartcardio. Any opinions?
** "connect" always returns the identical {@link Card} object. This is why?
This implementation currently opens a new shared connection. If we revert
to the spec, i'd at least expect some kind of reference counting. Opinions?

* Todos
** no channel support yet
** implement "GET RESPONSE"
** no permission checks so far
** review exceptions to be standard compliant (IllegalStateException)

We'd be very happy if someone around wants to use and verify the lib in
their own project (as we do not rely on smartcardio...)

The next step for this project will be to "clean up" the proprietary
smartcard abstraction layer and implementation that we use ourselves (this
may result in minor API changes).

Regards, Michael Traut
Ludovic Rousseau
2013-08-04 12:21:43 UTC
Permalink
Hello,
Post by Michael Traut
The initial release for an alternate javax.smartcardio provider is now
included in https://github.com/intarsys/smartcard-io/.
Thanks for the publication.

I am very new to Eclipse tool. What project file should I open in Eclipse?
I want to rebuild everything from source code.

You provide .jar files in lib/ and deploy/. In general only the source
code is stored in git. The binary results can be provide in a .tar.bz2
archive or something similar.

My 1st goal is to reproduce the sample at [1] using your code.

Regards,

[1] http://ludovicrousseau.blogspot.fr/2010/06/pcsc-sample-in-java.html
--
Dr. Ludovic Rousseau
Michael Traut
2013-08-04 15:47:36 UTC
Permalink
Hello,

this is only a small add-on to your appreciated work in the PCSC domain. We
have to thank you.

We have been new to git with this release, so we missed the "best practice
tip" to create eclipse projects one level below the git module. That said -
after a clone you can import the the root directory directly via
File->Import->General->Existing projects. With a current eclipse and Java 7
it should compile immediately. If you want to compile *everything* from
source, you should also clone the "intarsys/runtime" and
"intarsys/native-c" respositories and treat them the same way. The
dependencies into "runtime" are quite small but to much to get rid of (at
least for this release).

For the deployment, we wanted to create a deliverable that is able to
compile without much effort. We will have a look if we can manage this in a
more standard way.

To get your code running, don't forget to add the new provider before the
standard Sun one. One way to do this is in the working examples in the
"examples" folder.

Regards, Michael
Post by Ludovic Rousseau
Hello,
Post by Michael Traut
The initial release for an alternate javax.smartcardio provider is now
included in https://github.com/intarsys/smartcard-io/.
Thanks for the publication.
I am very new to Eclipse tool. What project file should I open in Eclipse?
I want to rebuild everything from source code.
You provide .jar files in lib/ and deploy/. In general only the source
code is stored in git. The binary results can be provide in a .tar.bz2
archive or something similar.
My 1st goal is to reproduce the sample at [1] using your code.
Regards,
[1] http://ludovicrousseau.blogspot.fr/2010/06/pcsc-sample-in-java.html
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Frank Marien
2013-08-05 07:50:41 UTC
Permalink
Post by Ludovic Rousseau
Hello,
For the deployment, we wanted to create a deliverable that is able to
compile without much effort. We will have a look if we can manage this
in a more standard way.
(for java) I would recommend using Maven if possible.

http://maven.apache.org/

This implies creating a pom.xml file describing the project and its
dependencies.
Maven has all sorts of packaging and deployment plugins, and even an
eclipse plugin
that creates the eclipse project files for you.

inside the project, running

mvn eclipse:eclipse

will do just that: after that command the project can be imported into
eclipse and ran, debugged, etc..
In this way you can just ship your code + pom.xml, and have maven
download dependencies etc.. Makes it a lot easier for others, and for
everyone to to continuous builds etc..

build:
mvn clean install

One step further is setting up a maven repository for your project: With
this in place everyone wanting to
use your code can just add a few dependency lines to their own pom.xml.

I'd be happy to help you get started.

-f
Martin Paljak
2013-08-05 15:05:00 UTC
Permalink
Just my 0.02€:

for simple projects, the dependency on Maven and the somewhat enforced
structure does not always add much benefit, other than "you have to do
it like this".

I've found eclipse projects (because this is the platform/IDE of
choice for me) and ant build files are sufficient to "make it build"
for various types of self-contained libraries/projects.

But that's probably just me, who wants to see small and critical
things build in a way that is observable and understandable, I've seen
maven "do something" for 2 minutes, downloading
I-don-t-know-what-for-why off the internet before I could use
anything.

Handling dependencies is never easy and most of the solutions tie you
to to the solution, much like choosing between .deb and .rpm (and I do
know of alien)

That being said, it is always nice to have something which does "all
things for you" but having the option to do a simple small compile
yourself is a very, very good idea.
--
Martin
+372 515 6495
Post by Frank Marien
Post by Ludovic Rousseau
Hello,
For the deployment, we wanted to create a deliverable that is able to
compile without much effort. We will have a look if we can manage this
in a more standard way.
(for java) I would recommend using Maven if possible.
http://maven.apache.org/
This implies creating a pom.xml file describing the project and its
dependencies.
Maven has all sorts of packaging and deployment plugins, and even an
eclipse plugin
that creates the eclipse project files for you.
inside the project, running
mvn eclipse:eclipse
will do just that: after that command the project can be imported into
eclipse and ran, debugged, etc..
In this way you can just ship your code + pom.xml, and have maven
download dependencies etc.. Makes it a lot easier for others, and for
everyone to to continuous builds etc..
mvn clean install
One step further is setting up a maven repository for your project: With
this in place everyone wanting to
use your code can just add a few dependency lines to their own pom.xml.
I'd be happy to help you get started.
-f
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Michael Traut
2013-08-06 06:25:31 UTC
Permalink
So - you are the guy that can donate the ant :-)

What is your proposal for the deployment of the final "jar"?
Post by Martin Paljak
for simple projects, the dependency on Maven and the somewhat enforced
structure does not always add much benefit, other than "you have to do
it like this".
I've found eclipse projects (because this is the platform/IDE of
choice for me) and ant build files are sufficient to "make it build"
for various types of self-contained libraries/projects.
But that's probably just me, who wants to see small and critical
things build in a way that is observable and understandable, I've seen
maven "do something" for 2 minutes, downloading
I-don-t-know-what-for-why off the internet before I could use
anything.
Handling dependencies is never easy and most of the solutions tie you
to to the solution, much like choosing between .deb and .rpm (and I do
know of alien)
That being said, it is always nice to have something which does "all
things for you" but having the option to do a simple small compile
yourself is a very, very good idea.
--
Martin
+372 515 6495
Post by Frank Marien
Post by Ludovic Rousseau
Hello,
For the deployment, we wanted to create a deliverable that is able to
compile without much effort. We will have a look if we can manage this
in a more standard way.
(for java) I would recommend using Maven if possible.
http://maven.apache.org/
This implies creating a pom.xml file describing the project and its
dependencies.
Maven has all sorts of packaging and deployment plugins, and even an
eclipse plugin
that creates the eclipse project files for you.
inside the project, running
mvn eclipse:eclipse
will do just that: after that command the project can be imported into
eclipse and ran, debugged, etc..
In this way you can just ship your code + pom.xml, and have maven
download dependencies etc.. Makes it a lot easier for others, and for
everyone to to continuous builds etc..
mvn clean install
One step further is setting up a maven repository for your project: With
this in place everyone wanting to
use your code can just add a few dependency lines to their own pom.xml.
I'd be happy to help you get started.
-f
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Michael Traut
2013-08-06 06:23:49 UTC
Permalink
Thanks for the maven hint. I know maven and are forced to use this at a
client site. I must admit that i dislike the tool very much (i hope i dont
get a war started...). At least in combination with eclipse you get the
worst of both worlds.

Anyway, the offer is (as described in the readme) that i will include
gladly any contribution wrt maven or ant. I will not provide one.

The question i'm searching an answer for is if we should include the final
deliverable as a binary or not. Here a POM that will enable a client to add
the binary to his project may be very reasonable (your "one step further").
Building the project itself with maven seems overkill and is in no way
comaptible to our build & deploy.

thanks for your support!
Post by Frank Marien
Post by Ludovic Rousseau
Hello,
For the deployment, we wanted to create a deliverable that is able to
compile without much effort. We will have a look if we can manage this
in a more standard way.
(for java) I would recommend using Maven if possible.
http://maven.apache.org/
This implies creating a pom.xml file describing the project and its
dependencies.
Maven has all sorts of packaging and deployment plugins, and even an
eclipse plugin
that creates the eclipse project files for you.
inside the project, running
mvn eclipse:eclipse
will do just that: after that command the project can be imported into
eclipse and ran, debugged, etc..
In this way you can just ship your code + pom.xml, and have maven
download dependencies etc.. Makes it a lot easier for others, and for
everyone to to continuous builds etc..
mvn clean install
One step further is setting up a maven repository for your project: With
this in place everyone wanting to
use your code can just add a few dependency lines to their own pom.xml.
I'd be happy to help you get started.
-f
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Ludovic Rousseau
2013-08-05 18:10:44 UTC
Permalink
Post by Ludovic Rousseau
Hello,
this is only a small add-on to your appreciated work in the PCSC domain. We
have to thank you.
We have been new to git with this release, so we missed the "best practice
tip" to create eclipse projects one level below the git module. That said -
after a clone you can import the the root directory directly via
File->Import->General->Existing projects. With a current eclipse and Java 7
it should compile immediately. If you want to compile *everything* from
source, you should also clone the "intarsys/runtime" and "intarsys/native-c"
respositories and treat them the same way. The dependencies into "runtime"
are quite small but to much to get rid of (at least for this release).
I only have Java 1.6.0_51 on my Mountain Lion OS X system. The wrapper
needs Java 1.7 :-(

I know could install Java 1.7 from Oracle and try again. But I do not
want to break my system. I am not a Java expert (or even user AFAIK).

Thanks
--
Dr. Ludovic Rousseau
Michael Traut
2013-08-06 07:02:03 UTC
Permalink
That's right, we switched to 7 with the upcoming version. As this
environment is a security requirement with our customers we didn't see any
problems here...

In reality the code is not really dependent on version 7 - besides the fact
that eclipse code completíon will create an ugly syntax artifact (creation
of generic instances without concrete type, like new ArrayList<>, where
this information is redundant) that was not supported earlier. Adding types
will make the code compile...

But installing Java 7 JDK *without* installing the accompanying JRE into
the system *should* do the job. In eclipse, using
Preferences->Java->Installed JREs you can select this JDKs directory, est
it as default and you should be fine.

And if you're not a Java user there should be no risk anyway :-)
Post by Michael Traut
Post by Ludovic Rousseau
Hello,
this is only a small add-on to your appreciated work in the PCSC domain.
We
Post by Ludovic Rousseau
have to thank you.
We have been new to git with this release, so we missed the "best
practice
Post by Ludovic Rousseau
tip" to create eclipse projects one level below the git module. That
said -
Post by Ludovic Rousseau
after a clone you can import the the root directory directly via
File->Import->General->Existing projects. With a current eclipse and
Java 7
Post by Ludovic Rousseau
it should compile immediately. If you want to compile *everything* from
source, you should also clone the "intarsys/runtime" and
"intarsys/native-c"
Post by Ludovic Rousseau
respositories and treat them the same way. The dependencies into
"runtime"
Post by Ludovic Rousseau
are quite small but to much to get rid of (at least for this release).
I only have Java 1.6.0_51 on my Mountain Lion OS X system. The wrapper
needs Java 1.7 :-(
I know could install Java 1.7 from Oracle and try again. But I do not
want to break my system. I am not a Java expert (or even user AFAIK).
Thanks
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Loading...