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.
KDE KWallet integration for the NetBeans Keyring API would be great! https://netbeans.org/bugzilla/show_bug.cgi?id=173413 has been closed without KWallet support. Let's see if this issue can show enough attraction for someone to implement it.
I want kwallet integration too! Does anyone knows where is some documentation about integrating with kwallet?
Does not look too hard from API documentation, though I am not sure what you need to do to work with 16-bit QString's.
As far as I can tell, it shall be possible to access kwallet: http://libwallet.evolvis.org/
I posted patch for it in orginal bug with keyring (forgot about this bug)
Please leave open until actually integrated into sources. Patch looks good. Sorry about the hassle, but I need to ensure you have signed the CA: http://netbeans.org/about/legal/ca.html https://sca.dev.java.net/CA_signatories.htm Comments, besides that on the mailing list (I can also make changes like these when integrating since they are minor): [JG01] getApplicationNameWithVersion needs to be fixed to pass the version into the MessageFormat. Probably can be merged with getApplicationName and take a boolean withVersion param. BTW prefer NbBundle.getMessage(Class,String,Object...). [JG02] commandString can be deleted, replace with Arrays.toString(argv).
Created attachment 93779 [details] kwallet keyring provider and junit
Created attachment 93780 [details] kwallet keyring integration - path1 - removed commandString
Created attachment 93781 [details] kwallet keyring integration - path2 - applied MessageFormat
I submited all pathes (in order of aplying) here
(In reply to comment #3) > As far as I can tell, it shall be possible to access kwallet: > http://libwallet.evolvis.org/ Too bad that one has to install libunixsocket-java manually to get it work [1]. [1] http://wiki.evolvis.org/libwallet/index.php/Programming_Example
this is the reason I didn't use java-dcop myself :P
[TM01] Couldn't we move External Execution API from IDE cluster to platform? IMHO not only this patch could benefit from it but also all platform users. What do you think?
(In reply to comment #12) > [TM01] Couldn't we move External Execution API from IDE cluster to platform? > IMHO not only this patch could benefit from it but also all platform users. > What do you think? I don't realy think, that I would make bether path if I used external execution api instead of standard java process ps: my ca has been accepted
(In reply to comment #13) > ps: my ca has been accepted Confirmed, thanks for your patience. I had to change the log message "application exit with code ..." to FINE from SEVERE since it is otherwise printed when running on non-KDE platforms, where there is no real error. http://hg.netbeans.org/core-main/rev/1a3138f382dd
I had to make more changes to get the unit test to pass on a Linux machine on which qdbus was not even installed (and thus, presumably, to avoid exceptions being thrown on a non-Linux developer machine). You can see the problem simply by replacing argv[0] = "qdbus"; with argv[0] = "nonexistent"; core-main #de87265cb643
(In reply to comment #15) > I had to make more changes to get the unit test to pass on a Linux machine on > which qdbus was not even installed (and thus, presumably, to avoid exceptions > being thrown on a non-Linux developer machine). You can see the problem simply > by replacing > > argv[0] = "qdbus"; > > with > > argv[0] = "nonexistent"; > > core-main #de87265cb643 I see - I assumed "command not found" would be the output of the command - which of course was stupid - my fault, should I provide path or have you resolved this ?
(In reply to comment #16) > I assumed "command not found" would be the output of the command Nope, IOException. Then a NPE from new String(null). > should I provide patch or have you resolved this? Just review my fix: http://hg.netbeans.org/core-main/rev/de87265cb643
Integrated into 'main-golden', will be available in build *201002120200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/1a3138f382dd User: Adam K?dziora <psychollek@netbeans.org> Log: #179839: KWallet support for Keyring API. (applied by jglick)
NB asks me for my KWallet password not only once but several times (easily reproducible e.g. with Exception Reporter, one has to enter his/her password twice or maybe three times) - I guess it is a bug? Should I reopen or file a new issue? Thanks.
(In reply to comment #19) > NB asks me for my KWallet password not only once but several times (easily > reproducible e.g. with Exception Reporter, one has to enter his/her password > twice or maybe three times) - I guess it is a bug? Should I reopen or file a > new issue? > > Thanks. have you clicked "allow always" ? if you clicked the "allow once" then this is not a bug - unfortunatelly you cannot make it open for one session - I could leave it open after you click allow - but then you canno't determine easily when it will timeout (and generally it is wrong way f using kwallet).
(In reply to comment #20) > have you clicked "allow always" ? Sure.
(In reply to comment #19) > NB asks me for my KWallet password not only once but several times See bug #181252, perhaps the same.
(In reply to comment #22) > (In reply to comment #19) > > NB asks me for my KWallet password not only once but several times > > See bug #181252, perhaps the same. bug not the same, but has the same reason - I'll work it out next week (or when i'll be bored with my current work) if nobody will post patch in a meantime.
Issue added to list [1] of community contributed features/bug fixes. Thanks Adam! [1] http://wiki.netbeans.org/NetFIXIssues