Perforce Java API Line-Ending Style - java

My program needs to read a list of files from a Perforce repository using the Java API provided by Perforce. This program uses a shared read-only login, and fetches files without using a client workspace.
This all works fine, however the problem I have is that the files always appear to be checked out with \r\n line endings. I have tried various naughty hacks (e.g. setting the System property line.separator to \n), but these don't work. I have noticed that the line-ending style in the p4v client is set on the workspace. Am I required to have a workspace to set the line-ending style?
Unfortunately, whilst there are a few files which never change, and I can commit those as binary, the other files I retrieve cannot be committed as binary.

Yes - the line ends of local files are determined by the client (aka workspace) setting when calling "sync".
If you fetch files without syncing and without a client then you have to "print" them.
In that case you would have to do the line end translations yourself.
Perhaps you can sync the files by creating a temporary client.
Here's an example for that (look at method P4PublishTransaction).

Related

Check if I can remove file

I'm opening many types of files using external applications which are available on phone. For security reasons I need to delete this file when the external app does not need it. How can I check if I can safely remove file which are used by third app ?
First of all you need to know which files are used by the third app. You can simply do it by analyzing, (decompiling, if needed) the source code of the application. After knowing all the files used by the third party app you need to check if the third party app actually running or not, because the third party app might use some temporary files, which could be removed when it's no longer open.
If you just want to make a simple cleaner, which cleans the trash of all the apps, then you should simply just remove certain file types (like .tmp files) and remove the cache of the apps.
First of all, I think there is no 100% way to determine if file is not used by another application.
I you are asking about files in sandbox of other apps, by the way you be able to remove such files because they have granted permissions only for app that they are belong to. So you need root access in this case.
You can remove file like cache,tmp ... files like system app manager does. If third-party is built correctly this should not affect application.
Also another method is to determine how often file is being used is based on unix file timestamps, they are
Access - the last time the file was read
Modify - the last time the file was modified (content has been modified)
Change - the last time meta data of the file was changed (e.g. permissions)
You can check for example the date when app was installed, than check access time of the file and determine does the application require this file.
But again there is no 100% guarantee that you won't brake an app.

How to hide personal info from a publicly shared GitHub?

I share my Java project on GitHub (because I believe in open-source code and no hidden tricks). Anyways, I have a unique UserAgent I got from a website for API usages... I want to know how I can hide that from GitHub without making my project private...
What can I do?
I tried searching Google, but no one seems to have the same problem. I can't use a separate file and then add it to .gitignore because it won't work when I deploy the project. Please help!
I want to know how I can hide that from GitHub without making my project private
You cannot push that information to the repo then.
What you can do is declaring a content filter driver which, on checkout, will check if it has access to a private source of information (elsewhere than your public repo, potentially elsewhere than GitHub), and generate the right file (which remains private, and is declared in the .gitignore).
That content filter driver is declared in a .gitattributes, and is taking a template file (which is versioned but contains, by its nature, no value), and will generate the complete file with:
default values (if the source of the private data isn't found)
sensitive values (if the script has access to the private source of information)
As suggested in comments: put this information in a config file.
Here is an example: this javascript project provides a config.js.template file, but the application expects a config.js file (which is gitignored). If this file doesn't exist, the template is copied.
That way, it will run with sensible default values even if the user doesn't take the time to write his own config first.
Moreover, since you're saying yo plan to "switch" to a config file, I guess those personal config values are currently in your code. So don't forget to also clean your old commits before pushing to github!
Just encrypt confidential info using GPG and also sign your tags.

how to write into a text file in Java

I am doing a project in java and in that i need to add and modify my
text file at runtime,which is grouped in the jar.
I am using class.getResourceAsStream(filename) this method we
can read that file from class path.
i want to write into the same textfile.
What is the possible solution for this.
If i can't update the text file in jar what other solution is there?
Appreciate any help.
The easiest solution here is to not put the file in the jar. It sounds like you are putting files in your jar so that your user only needs to worry about one file that contains everything related to that program. This is an artificial constraint and just add headaches.
There is a simple solution that still allows you to distribute just the jar file. At start up, attempt to read the file from the file system. If you don't find it, use default values that are encoded in you program. Then when changes are made, you can write it to the file system.
In general, you can't update a file that you located using getResourceAsStream. It might be a file in a JAR/ZIP file ... and writing it would entail rewriting the entire JAR file. It might be a remote file served up by a Url classloader.
For your sanity (and good practice), you should not attempt to update files that you access via the classpath. If you need to, read the file out of the JAR file (or whatever), copy it into the regular file system, and then update the copy.
I'm not saying that it is impossible to do this in all cases. Indeed, in most normal cases you can do it with some effort. However, this is not supported, and there are no standard APIs for doing this.
Furthermore, attempts to update resources are liable to cause anomalies in the classloader. For example, I'd expect resources in JAR files to not update (from the perspective of the application) until the application restarted. But resources in exploded JAR files probably would update ... though new resources might not show up.
Finally, there are cases where updating a resource is impossible:
When the user doesn't have write access to the application's installation directory. This is typical for a properly administered UNIX / Linux machine.
When the JAR file is fetched from a remote server, you are likely not to be able to write the updates back.
When you are using an arbitrary custom classloader, you've got no way of knowing where the actual bytes of an updated resource should be stored, and no way of storing them.
All JAR rewriting techniques in Java look similar. Open the Jar file, read all of it's contents, and write a new Jar file containing the unmodified contents (and the modifications you whished to make). Such techniques are not advisable for a Jar file on the class path, much less a Jar file you're running from.
If you decide you must do it this way, Java World has a few articles:
Modifying Archives, Part 1
Modifying Archives, Part 2
A good solution that avoids the need to put your items into a Jar file is to read (if present) a properties file out of a hidden subdirectory in the user's home directory. The logic looks a bit like this:
if (the hidden directory named after my application doesn't exist) {
makeTheHiddenDirectory();
writeTheDefaultPropertiesFile();
}
Properties appProps = new Properties();
appProps.load(new FileInputStream(fileInHiddenDir));
...
... After the appProps have changed ...
...
appProps.store(new FileOutputStream(fileInHiddenDir), "Do not modify this file");
Look to java.util.Properties, and keep in mind that they have two different load and store formats (key = value based and XML based). Pick the one that suits you best.
If i can't update the text file in jar what other solution is there?
Store the information in any of:
Cookies
The server
Deploy the applet using 1.6.0_10+, launch it using JWS and use the PersistenceService to store the information. Here is my demo. of the PersistenceService.
Also, if your users will agree to a trusted applet (which seems overkill for this), you might write the information to a sub-directory of user.home.

Create AppleDouble formatted file in Linux

I'm working on an application that syncs data. For Mac OS, files are uploaded and if they contain resource fork information, the fork is read and stored as a string using: file/..namedfork/rsrc
Users can access their files using a Web application(Java) that's running on a Linux server, is there a way that I can generate a valid AppleDouble format file using only the data fork and the string I read from the namedfork? I don't mind losing the Finder Metadata.
Note: The generated file will be downloaded (using the Web Application) as a single file for Mac OS users.
Is this possible?
Regards
As far as I'm aware, OS 9/OS X can only natively access the resource forks on files served by AppleTalk shares. For other media, e.g. SMB (Microsoft Networking) or HTTP, the only way to preserve the resource fork is to place the file in an archive.
There are several Mac-specific archive formats that support this, for example, StuffIt and HQX. I very much doubt the Linux binaries for StuffIt would allow packaging a resource fork from a separate file, but at least there is something for you to evaluate.
Looking at the AppleDouble Wikipedia entry, it seems it may be possible to create such a file from a non-Apple machine using an open source tool, and sending the resultant file using the multipart/appledouble MIME type. Perhaps you could call this binary from your Java code?
The wikipedia article states:
AppleSingle combined both file forks and the related Finder meta-file information into a single file, whereas AppleDouble stored them as two separate files.
The apple knowledgebase article states:
The second new file has the name of the original file prefixed by a "._ " and contains the resource fork of the original file.
So I assume you just have to save the content of your resource fork string into the appropriately named file.
Edit:
After your comment I'm not sure what you want. Your question was how to
Create AppleDouble formatted file in Linux
and the documentation I linked to shows that you need to create two files to do that one containing the data and one containing the resource fork with a name that has ._ prefixed. If that is not what you want then you need to ask a different question.

How to preview a file on the server in JBoss

I need some ideas on how I can best solve this problem.
I have a JBoss Seam application running on JBoss 4.3.3
What a small portion of this application does is generate an html and a pdf document based on an Open Office template.
The files that are generated I put inside /tmp/ on the filesystem.
I have tried with System.getProperties("tmp.dir") and some other options, and they always return $JBOSS_HOME/bin
I would like to choose the path $JBOSS_HOME/$DEPLOY/myEAR.ear/myWAR.war/WhateverLocationHere/
However, I don't know how I can programatically choose path without giving an absolute path, or setting $JBOSS_HOME and $DEPLOY.
Anybody know how I can do this?
The second question;
I want to easily preview these generated files. Either through JavaScript, or whatever is the easiest way. However, JavaScript cannot access the filesystem on the server, so I cannot open the file through JavaScript.
Any easy solutions out there?
Not sure how you are generating your PDFs, but if possible, skip the disk IO all together, stash the PDF content in a byte[] and flush it out to the user in a servlet setting the mime type to application/pdf* that responds to a URL which is specified by a link in your client or dynamically set in a <div> by javascript. You're probably taking the memory hit anyways, and in addition to skipping the IO, you don't have to worry about deleting the tmp files when you're done with the preview.
*****I think this is right. Need to look it up.
Not sure I have a complete grasp of what you are trying to achieve, but I'll give it a try anyway:
My assumption is that your final goal is to make some files (PDF, HTML) available to end users via a web application.
In that case, why not have Apache serve those file to the end users, so you only need your JBOSS application to know the path of a directory that is mapped to an Apache virtual host.
So basically, create a file and save it as /var/www/html/myappfiles/tempfile.pdf (the folder your application knows), and then provide http://mydomain.com/myappfiles (an Apache virtual host) to your users. The rest will be done by the web server.
You will have to set an environment variable or system property to let your application know where your folder resides (/var/www/html/myappfiles/ in this example).
Hopefully I was not way off :)
I agree with Peter (yo Pete!). Put the directory outside of your WAR and setup an environment variable pointing to this. Have a read of this post by Jacob Orshalick about how to configure environment variables in Seam :
As for previewing PDFs, have a look at how Google Docs handles previewing PDFs - it displays them as an image. To do this with Java check out the Sun PDF Renderer.
I'm not sure if this works in JBoss, given that you want a path inside a WAR archive, but you could try using ServletContext.getRealPath(String).
However, I personally would not want generated files to be inside my deployed application; instead I would configure an external data directory somewhere like $JBOSS_HOME/server/default/data/myapp
First, most platforms use java.io.tmpdir to set a temporary directory. Some servlet containers redefine this property to be something underneath their tree. Why do you care where the file gets written?
Second, I agree with Nicholas: After generating the PDF on the server side, you can generate a URL that, when clicked, sends the file to the browser. If you use MIME type application/pdf, the browser should do the right thing with it.

Categories