Following Meteor docs on how to use the import directory structure, Example directory layout.
The illustration says:
lists.js # definition of the Lists collection
Where lists.js path is app/imports/api/lists/list.js
The docs indicates that collections definitions need to be in lib folder because they need to be loaded on both the client and the server.
What is Meteor new way of achieving this with the imports file structure? Thanks
The new way is basically having 3 main folders:
client/main.js
server/main.js
imports
Then whatever you need on server, you import in server/main.js like:
import '/imports/lib/mylibrary.js';
import '/imports/collections/users.js';
The same goes for client/main.js. It's up to you to decide the structure of imports folder, you are the one to decide which files from there to import.
Public files (accessible on client) go to public, private files (accessible only on server by Assets API) go to private. And that's basically enough for starters.
Most common file structure is
'client' (all client side files, can be further grouped for routers,
appl logic..etc
'server' (all server methods and publications)
'lib' (common files to both client server with the additional value that
files in here will be loaded first by meteor)
'packages' (all external packages can be put here)
Any more folder names at this level will be common to both client and server but will not be loaded first.
Related
we have to export alfresco data and import into another repository, and not necessarily backup/restore process. we are aiming for script which can be run and extract data on some conditions, set of files, with all its metedata.
i have got below link, which talks about same, but it is old , and things cant be done like versions of the file, condition based extract.
https://www.ibm.com/developerworks/cn/xml/x-cmis2/index.html
i would like to know any approaches available for extract and import of the alfresco data into other repositories..
There is nothing out-of-the-box that will do this. The replication sub-system is not suitable for frequent replication of more than a small handful of nodes.
So, you will have to write a custom solution or look at third-party solutions that can do this. Simflofy is one example. Another example is the Parashift Alfstream module.
If you would like to develop this yourself, I suggest you do something like:
Write code to export one or more files to the file system. This should be storage that is shared between the source and all target repositories.
Alongside each file, write a "manifest" file that descries the file's metadata, including custom properties and property values. You should use the same format that the Bulk File System Import Tool expects when doing an import.
Add a message to a queue that describes where the exported data is sitting and where it needs to be imported.
In the target repository, write a listener that is subscribe to the queue.
When the listener gets a message it can initiate a Bulk File System Import in the target system. The BFSIT will import the files and set the metadata as described in the manifest file you generated in Step 2.
Optionally, the target system can place another message on the queue acknowledging that the import has been performed, which the source repo can then pick up to complete the task.
Some people have been successful using Apache Camel for this, but it is not strictly necessary.
I have some code that is used on both the client and the server, that I need to be loaded before all code in server/ and client/
I tried to put the common code in lib/, but then I run into issues when I have code in client/lib and server/lib that depends on the code in lib/ to be defined when they load.
Here's an example of file load order from the Meteor documentation under the section File Load Order:
nav.html
main.html
client/lib/methods.js
client/lib/styles.js
lib/feature/styles.js
lib/collections.js
client/feature-y.js
feature-x.js
client/main.js
According to this example, files in client/lib/ get loaded before files in lib/.
I need the files in lib/ to load before the files in client/lib/. Is there any way to change this?
I'm putting my collection definitions in lib/, and my client subscriptions in client/lib. Organizing it like this makes sense to me because, my helpers in client/helpers.js depend on client/lib/subscriptions.js, and my subscriptions depend on the collections defined in lib/collections.js, and both the client and the server need the collection definitions, so I put them in lib/.
I found a clever solution.
I essentially renamed ./client/lib/ to ./client/deps/, which changed the load order to the following.
./lib/collections.js
./client/deps/subscriptions.js
./client/helpers.js
I need this order because my subscriptions depend on a collection being defined, and my helpers depend on subscriptions being defined.
The folder ./client/lib/ will always be loaded before ./lib/, but ./client/deps/ will be loaded after ./lib/ and before ./client/helpers.js, because ./client/deps/ is a deeper folder than ./client/, as per the Meteor documentation on File Load Order.
I find the section on application structure in the official documentation quite confusing for me. It first says
The only server assets are JavaScript and files in the private
subdirectory.
but then immediately
Meteor gathers all your JavaScript files, excluding anything under the
client, public, and private subdirectories...
and later
Meteor gathers all JavaScript files in your tree, with the exception
of the server, public, and private subdirectories, for the client...
and
Files outside the client, server and tests subdirectories are loaded
on both the client and the server!
These seem contradicting for me. For example what if I put some JavaScript files in private, will they be gathered by Meteor? By 1 and 3, yes and to the server only; by 2, no; by 4, yes and to both server and client.
One possible explanation is that the set "JavaScript files" is not a subset of the set "files", which is not logically sound. I know this answer has provided a clear table for the structure and I may ultimately resort to that. But I still need someone to clearify the ambiguity of this part in the official documentation. Thank you.
First I ought to split up the files into 3 types of classes
Files that are parsed by Meteor as part of the project (not considered static)
Files that are considered as part of Meteor but are static
Other files like those necessary for tests
The only server assets are JavaScript and files in the private subdirectory.
These files are considered 'static' and js files in private are not run. What it means is that files in private and server are not visible to the client. (Part of 2 in the criteria above)
Files outside the client, server and tests subdirectories are loaded on both the client and the server!
It ought to say private and public too, private and public files aren't loaded on the browser. (These are mentioned this way, but are in reference to 1) hence the confusing language
Summary
tests -
Only used for tests, not parsed by Meteor
private Storing static files that are not parsed by meteor that the browser cannot access, can be accessed by the server only via Assets
public Storing static files that the browser can access, mapped to the the / path
server Files only run on the server and are parsed as part of Meteor,
client Files only run on the web browser and are part of Meteor
packages Stores packages that meteor will parse in a special way, can not contain anything apart from Meteor packages. Can contain code that is considered as parts of the private, public, client or server folders.
. (Folders and files beginning with .) - Ignored
..~ - Folders ending with the tilde - Ignored
Anything Else Parsed as part of Meteor, and runs both on the client side and the server side.
Anything that is run by the client or server and parsed by Meteor is usually concatenated and minified in production.
Static files accessible by the client - notes These will be separated from the app and run in a virtual static folder in production (e.g Images, Fonts, Videos, non js files)
This is not a table like the other question, which explains how to structure an app, but more how Meteor interprets the files in the folders above.
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.
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