To make my Ant Generated swf as small as possible, i used the Runtime Shared Library like described in this URL.
By default, the RSL files should be located with the compiled swf (without RSL).
Thus, do you know how can I change the location's property of the SRL files?
Because I have the compiled swf in many directories, that's why we should have only one resource of the RSL as well as in one separated directory
Have a look at an RSL linkage definition:
<runtime-shared-library-path>
<path-element>libs/framework.swc</path-element>
<rsl-url>http://fpdownload.adobe.com/pub/swz/flex/4.6.0.23201/framework_4.6.0.23201.swz</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
<rsl-url>framework_4.6.0.23201.swz</rsl-url>
<policy-file-url></policy-file-url>
</runtime-shared-library-path>
The rsl-url nodes define where the application will look for the library. It will first try to get it from the first URL; if that fails it will try the second; and so on until it finds a link that works or fails.
You can add as many URL's as you like, but for framework RSL's you'll typically have a link to Adobe's repository as the first URL, and one fallback URL on your own server.
These URL's can be absolute or relative. If for instance you'd want you SDK RSL's to be located in a directory called 'sdk' under the same directory your application is in, just change the secondary rsl-url node to:
<rsl-url>sdk/framework_4.6.0.23201.swz</rsl-url>
The same principle applies if you wish to do it through compiler arguments. You could do it like this:
-runtime-shared-library-path=${swc},${swz.primary},http://fpdownload.adobe.com/pub/swz/crossdomain.xml,${swz.secondary}
Related
Is there any way how to implement dynamical file-resolver for missing Qml components in QmlEngine? How to implement dynamically loading of external resources to QmlEngine?
I can use following snippet to load qml component from any data stream:
QUrl uri(...)
QByteArray data(...);
QQmlComponent::setData(data,uri);
but when passed component refers to another one (not already loaded), QmlEngine stopped because of missing resource.
Is there any event/callback where it is possible to handle such missing resource?
Added use-case scenario:
We're developing some QML visual components. Some components are implemented as .qml files and some as QQuickItem.
For example imagine following situation (it's very simplified):
QmlItem "DiagramPoint", implemented in point.qml
QmlItem "Line" implemented in line.qml, class is using "DiagramPoint" item
QQuickItem (c++) "ConnectedLine" which internally using "Line" object
QmlProject which using "ConnectedLine" components.
In case that point.qml and line.qml are located on hdd or stored inside Qt Resources, everything works automatically. But what we would like to achieve is to store these files in encrypted form in our internal .dat file and decode it only on demand.
We're able to decode and load "Line" object from "ConnectedLine" implementation. But in case that "Line" (line.qml) depends on another encrypted file "DiagramPoint" (point.qml), this solution doesn't work.
Another possible solution
Another solution could be to register all decrypted .qml files on application startup and than use it. Something simillar to qmlRegisterType which allows to register c++ QQuickItems to QmlEngine.
Unfortunately none of these methods allow to register Qml snippet from string buffer.
I'm still a bit unsure about how you would do this, but you might find QQmlAbstractUrlInterceptor useful:
QQmlAbstractUrlInterceptor is an interface which can be used to alter URLs before they are used by the QML engine. This is primarily useful for altering file urls into other file urls, such as selecting different graphical assets for the current platform.
Relative URLs are intercepted after being resolved against the file path of the current QML context. URL interception also occurs after setting the base path for a loaded QML file. This means that the content loaded for that QML file uses the intercepted URL, but inside the file the pre-intercepted URL is used for resolving relative paths. This allows for interception of .qml file loading without needing all paths (or local types) inside intercepted content to insert a different relative path.
Compared to setNetworkAccessManagerFactory, QQmlAbstractUrlInterceptor affects all URLs and paths, including local files and embedded resource files. QQmlAbstractUrlInterceptor is synchronous, and for asynchronous files must return a url with an asynchronous scheme (such as http or a custom scheme handled by your own custom QNetworkAccessManager). You can use a QQmlAbstractUrlInterceptor to change file URLs into networked URLs which are handled by your own custom QNetworkAccessManager.
To implement support for a custom networked scheme, see setNetworkAccessManagerFactory.
It says that its synchronous, so perhaps you could decode the QML files when the URLs are intercepted to ensure that they exist?
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
I'm working with modules and each of it will be compiled (deployed) in a common folder in a webproject. In the main class I defined an array of module paths which I need for loading all these defined modules.
How can I make that more dynamically, for instance, I want to say, load all modules in a certain folder an its subfolders without to know each module by name.
You can't do anything in a Flex/AS3 related browser based app to get information about folders on the server.
You're going to have to write a server side service to get the information. Any technology should work, such as .NET, ColdFusion, PHP, Java, or whatever. Then just call the service, and it should send you back the information you need. In ColdFusion, you'd use the cfdirectory tag.
I have a large directory structure with JavaScript, images, etc. that depend on each other. I would like to encapsulate it all into a DLL so I only have to reference one thing and not have multiple copies of all these files across projects.
Because the files depend on each other, I'm thinking I can create an IHttpModule that registers a route to accept URLs such as /MyEmbeddedDir/subdir/file.js. Anything in MyEmbeddedDir would then be handled by a custom IHttpHandler that does the correct mapping. Each web application would then need to reference the DLL and add the module and handler to web.config. Does this seem reasonable?
Also, is there an easier way to embed/reference the files than to set the build action to embedded resource and add [assembly: WebResource(...)] to each file (there are dozens!)? Thanks!
Edit: If I'm not using WebResource.axd then I shouldn't need to add [assembly: WebResource(...)]
Yes, having a single container is a great way to manage large number of files (and no, SQLite won't help here! ;).
We have a product, named SolFS, which is a virtual file system, that lets you keep your data in custom storage (resource DLL is one of the options) and provides file API for accessing the files. We even implemented asynchronous pluggable protocol for IE (on the client side, but the task is very similar to yours). SolFS includes a manager application that lets you easily create container files and import files into container.
I ended up going with the IHTTPModule (register route) and IHTTPHandler (obtain embedded resource). The route is configurable in web.config in case it conflicts with existing content.
In my web application I have to send email to set of predefined users like finance#xyz.example, so I wish to add that to a .properties file and access it when required. Is this a correct procedure, if so then where should I place this file? I am using Netbeans IDE which is having two separate folders for source and JSP files.
It's your choice. There are basically three ways in a Java web application archive (WAR):
1. Put it in classpath
So that you can load it by ClassLoader#getResourceAsStream() with a classpath-relative path:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Here foo.properties is supposed to be placed in one of the roots which are covered by the default classpath of a webapp, e.g. webapp's /WEB-INF/lib and /WEB-INF/classes, server's /lib, or JDK/JRE's /lib. If the propertiesfile is webapp-specific, best is to place it in /WEB-INF/classes. If you're developing a standard WAR project in an IDE, drop it in src folder (the project's source folder). If you're using a Maven project, drop it in /main/resources folder.
You can alternatively also put it somewhere outside the default classpath and add its path to the classpath of the appserver. In for example Tomcat you can configure it as shared.loader property of Tomcat/conf/catalina.properties.
If you have placed the foo.properties it in a Java package structure like com.example, then you need to load it as below
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Note that this path of a context class loader should not start with a /. Only when you're using a "relative" class loader such as SomeClass.class.getClassLoader(), then you indeed need to start it with a /.
ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...
However, the visibility of the properties file depends then on the class loader in question. It's only visible to the same class loader as the one which loaded the class. So, if the class is loaded by e.g. server common classloader instead of webapp classloader, and the properties file is inside webapp itself, then it's invisible. The context class loader is your safest bet so you can place the properties file "everywhere" in the classpath and/or you intend to be able to override a server-provided one from the webapp on.
2. Put it in webcontent
So that you can load it by ServletContext#getResourceAsStream() with a webcontent-relative path:
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Note that I have demonstrated to place the file in /WEB-INF folder, otherwise it would have been public accessible by any webbrowser. Also note that the ServletContext is in any HttpServlet class just accessible by the inherited GenericServlet#getServletContext() and in Filter by FilterConfig#getServletContext(). In case you're not in a servlet class, it's usually just injectable via #Inject.
3. Put it in local disk file system
So that you can load it the usual java.io way with an absolute local disk file system path:
InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...
Note the importance of using an absolute path. Relative local disk file system paths are an absolute no-go in a Java EE web application. See also the first "See also" link below.
Which to choose?
Just weigh the advantages/disadvantages in your own opinion of maintainability.
If the properties files are "static" and never needs to change during runtime, then you could keep them in the WAR.
If you prefer being able to edit properties files from outside the web application without the need to rebuild and redeploy the WAR every time, then put it in the classpath outside the project (if necessary add the directory to the classpath).
If you prefer being able to edit properties files programmatically from inside the web application using Properties#store() method, put it outside the web application. As the Properties#store() requires a Writer, you can't go around using a disk file system path. That path can in turn be passed to the web application as a VM argument or system property. As a precaution, never use getRealPath(). All changes in deploy folder will get lost on a redeploy for the simple reason that the changes are not reflected back in original WAR file.
See also:
getResourceAsStream() vs FileInputStream
Adding a directory to tomcat classpath
Accessing properties file in a JSF application programmatically
Word of warning: if you put config files in your WEB-INF/classes folder, and your IDE, say Eclipse, does a clean/rebuild, it will nuke your conf files unless they were in the Java source directory. BalusC's great answer alludes to that in option 1 but I wanted to add emphasis.
I learned the hard way that if you "copy" a web project in Eclipse, it does a clean/rebuild from any source folders. In my case I had added a "linked source dir" from our POJO java library, it would compile to the WEB-INF/classes folder. Doing a clean/rebuild in that project (not the web app project) caused the same problem.
I thought about putting my confs in the POJO src folder, but these confs are all for 3rd party libs (like Quartz or URLRewrite) that are in the WEB-INF/lib folder, so that didn't make sense. I plan to test putting it in the web projects "src" folder when i get around to it, but that folder is currently empty and having conf files in it seems inelegant.
So I vote for putting conf files in WEB-INF/commonConfFolder/filename.properties, next to the classes folder, which is Balus option 2.
Ex: In web.xml file the tag
<context-param>
<param-name>chatpropertyfile</param-name>
<!-- Name of the chat properties file. It contains the name and description of rooms.-->
<param-value>chat.properties</param-value>
</context-param>
And chat.properties you can declare your properties like this
For Ex :
Jsp = Discussion about JSP can be made here.
Java = Talk about java and related technologies like J2EE.
ASP = Discuss about Active Server Pages related technologies like VBScript and JScript etc.
Web_Designing = Any discussion related to HTML, JavaScript, DHTML etc.
StartUp = Startup chat room. Chatter is added to this after he logs in.
It just needs to be in the classpath (aka make sure it ends up under /WEB-INF/classes in the .war as part of the build).
You can you with your source folder so whenever you build, those files are automatically copied to the classes directory.
Instead of using properties file, use XML file.
If the data is too small, you can even use web.xml for accessing the properties.
Please note that any of these approach will require app server restart for changes to be reflected.
Assume your code is looking for the file say app.properties. Copy this file to any dir and add this dir to classpath, by creating a setenv.sh in the bin dir of tomcat.
In your setenv.sh of tomcat( if this file is not existing, create one , tomcat will load this setenv.sh file.
#!/bin/sh
CLASSPATH="$CLASSPATH:/home/user/config_my_prod/"
You should not have your properties files in ./webapps//WEB-INF/classes/app.properties
Tomcat class loader will override the with the one from WEB-INF/classes/
A good read:
https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html