This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Now, in file .netbeans\6.8beta\config\org-netbeans-modules-javacard\servers\Java_Card_Platform_1 the value for javacard.device.apdutool.contactedProtocol=-t0. It should be t1.
Correction: The value for the attribute should be empty.
Need a little more info here. We provide a UI for customizing the value of this; possible values are -t0 and -t1. How should I indicate to the user that the value is "no value"? BTW, what is the difference between javacard.device.contactedProtocol=T=1 javacard.device.apdutool.contactedProtocol=-t1 and does the latter do anything? Anki?
This is a bit confusing. The protocol values are correct (T=0, T=1). But unfortunately the apdutool takes only one, that is -t0. if -t0 is not specified, then it is assumes T=1, but no need to have any value. That is why we have 2 properties stored automatically. The bug is -- -t0, instead of "" (Empty) string for javacard.device.apdutool.contactedProtocol The correct combination is javacard.device.contactedProtocol=T=1 javacard.device.apdutool.contactedProtocol= javacard.device.contactedProtocol=T=0 javacard.device.apdutool.contactedProtocol=-t0 (Note that if contactedProtocol is T=1 then there should be no value for apdutool.contactedprotocol. another possible solution is to have the build file do this conversion.
Yuck. I suppose there is no possibility of making these compatible with each other - i.e. the apdutool gets -contactedProtocol T=0 ? :-/
Okay. Currently the defaults we set up are: javacard.device.contactedProtocol=T=1 javacard.device.apdutool.contactedProtocol=-t1 This is what you get when you create a new card. org.netbeans.modules.javacard.ri.platform.installer.DevicePropertiesPanel correctly changes javacard.device.apdutool.contactedProtocol to the empty string if the user changes the contacted protocol to T=0. So, all of this looks correct - it should not be possible to get into a situation with conflicting or unusable values for these unless you manually edit the device definition somehow. Is there something more that needs to be done here, or can I close this issue?
No further comment, closing.