Basically, we shouldn't use instance variables and methods in JSP declarations because it is not thread-safe. But GAE does not use threads. So should I use instance variables and methods in JSP declaration? I mean to ask whether it will cause any inaccurate data?
GAE does not use threads by default, but you can turn it on.
So, if you do not turn it on (by declaring your app thread-safe) you will not run into threading issues.
However, why would you want to use instance variables and methods in a JSP in the first place? A JSP should just produce page output and do nothing else. If it gets complex to the point where you want to throw in instance variables and methods, you probably want to move code out into a Java class (beans, servlets, filters).
Related
Reacts documentation says "Environment variables are embedded into the build, meaning anyone can view them by inspecting your app's files".
I am assuming its because the .env. file where I would define them will be included in the build (or not because of that?!)?
So then,what the point of using react environment variables if i cannot hide any keys?
Or do I just not understand it and I can hide keys using react environment variables (a tutorial I am watching says you can hide them using it)?
What if I define those variables inside my shell? Are they exposed as well?
Thank you!!
Environment variables help because they can let you customize settings without changing the source code. In terms of the code that runs, the end result is the same - yes, whatever client runs the code will be able to see what's going on, including any API keys you include with the app - but it makes the development process easier when there's a single place where you can set settings that can differ between environments without changing the code itself.
This is of the greatest benefit when using source control like Git. If you make a change to a build setting - such as the change to an API key - it wouldn't make sense for that change to be checked into the codebase's history. Rather, the convention is to instead have the application read its environment variables, and have those not checked into source control, allowing the settings to be easily changed without changing anything else in the application's code itself.
See An Introduction to Environment Variables and How to Use Them for a decent summary.
if i cannot hide any keys?
Hiding API keys is a completely separate issue - it's not something that environment variables are meant to solve. If you want to hide your keys, there are at least two approaches:
Put the keys on your server, and then have the client make requests to your server, and have your server use the (secret) API key to the external service, then echo the result back to the client
Some APIs which provide keys also provide the ability to whitelist requests from certain domains, and to block requests from others. For example, depending on what you're using, you may have the ability to go into the API's settings to enable your key with mysite.com, and block it from being recognized as valid from any other site. This way, even if the API key is public, it's not (much) of a problem.
Environmental variables in react are always prefixed with REACT_APP_ and are used when you want to change values across your frontend react application. They're not designed to hide API keys which are intended to be private.
Variables that do not start with that prefix will not be visible in the final build (You can also use two .env files).
No variables defined inside your server shell will be exposed.
I have an angular constant which defines webservice end point
angular.module('myModule').constant('mywebservice_url', 'http://192.168.1.100')
The problem is that for dev I have a different end point while staging and production its different. Every time I try to check in to git I have to manually reset this file.
Is there any way git permenantly ignore this file but checks out the file while clone or checkout?
Is there any way I can make angular pickup file dynamically from something like environment variable.
NOTE: I don't want to depend on server to do this, ie I don't want to use apach SSI or any of those technologies as it will work only one set of servers.
Delaying the injection via backend processing. I usually just create a global object on html page called pageSettings which values like this is getting injected from the backend, i.e. environment variables, etc. and just pass that global pageSettings object into that angular constant or value.
Build system injection. If you don't have a backend, i.e. pure SPA... maybe you can put this inside your build system, i.e. create multiple task for building the different environments in gulp or grunt and replace that value during the build process.
In e.a. your app init code:
var x = location.hostname;
Then define 2 different constants.
One based off the domain name of your develop environment and one for your production.
For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.
Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the #Singleton Annotation is working the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does it mean, that a #Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an #Singleton-Bean?
Or should I use neither nor and provide the Service within an #ApplicationScoped bean?
it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)
Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)
All those kinds of singletons (static, #javax.inject.Singleton, #javax.ejb.Singleton and #javax.enterprise.context.ApplicationScoped) are created once per JVM.
An object that is created once per user session must be annotated with #javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.
Notice that there are two #Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.
The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:
#javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (#javax.ejb.TransactionAttribute), read/write locking and time-outs (#javax.ejb.Lock, #javax.ejb.AccessTimeout), application startup (#javax.ejb.Startup, #javax.ejb.DependsOn) and so on.
#javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as #javax.enterprise.inject.Produces, #javax.annotation.PostConstruct, #javax.inject.Named, #javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
#javax.inject.Singleton is similar to #ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.
javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.
For More information refer this page number 45.
On GAE my handler calls a function that does all the heavy lifting. All the objects are created within the function. However after the function exits (which returns a string for response.out.write) the memory usage does not go down. The first http call to GAE works, but memory stays at about 100MBs afterwards. The second access attempt fails because private memory limit is reached.
I have cleared all class static objects that I wrote and called the close and clear functions of the third party library to no avail. How does one cleanly release memory? I'd rather force a restart than tracking down memory leaks. Performance is not an issue here.
I know that it is not due to GC. GAE reports that memory stays at high level for a long period of time. The two http calls above were separated by minutes or longer.
I've tried to do the import of my function in the Handler.get function. After serving the page I tried to del all imported third party modules and then my own module. In theory now each call should get a restart of all suspected modules but memory problem still persists. The only (intended) modules left between calls should be standard library modules (including lxml, xml etc).
EDIT:
I now use taskqueue to schedule the heavy duty part on a backend instance and use db.Blob to pass around the results. Getting backends to work solves the memory issue. GAE documentation on backends is complete but confusing. The key is that one needs to follow the instructions on 1) editing backends.yaml 2) using appcfg to update (deploying from launcher is not enough). Afterwards check in admin that the backends is up. Also taskqueue target= breaks on the development server so one needs to work around it on the development server.
This is (probably) due to the fact that there is nothing saying that the garbage collector (which is in charge of freeing unused memory) will kick in directly when your function returns.
You could manually force it to kick in via a few hacks but that will not solve anything if two http request happens aprox. at the same time.
Instead I recommend you to look over solutions which doesn't require you to do the heavy lifting on each request.
If the data generated is unique for each request see if you can do the computations outside of your (limited) private memory pool.
how do I manually start the Garbage Collector?
When your heavy weight variables have gone out of scope invoke the GC by using the below method.
import gc
...
gc.collect ()
I have been working on C-based Native Client module for Google Chrome. Many of the module functions that are called by the NaCl system have a parameter of PP_Instance which uniquely identifies the module instance.
My question: Is there any way to associate user data with this instance handle?
The C API specifies that it is an opaque handle. It provides no functions for linking user data to the handle. Right now, I have to use a bunch of global variables within the module to share state among the functions. It doesn't feel like the right solution. I'm not sure if more than one instance will ever share the process space but I'm not making any assumptions here.
I suppose I could implement some sort of look up table to map instances to unique contexts that happen to live in the global scope. But that also seems like it should be unnecessary for a C-based API. The C++ API avoids this by virtue of its classes.
PP_Instance should be used as a key to lookup state / object associated with the plugin instance. More than one plugin instance may be instantiated in a module as per the API, when, for example, multiple embed tags are present in the containing frame. Currently the NaCl implementation of Pepper does not do this -- instead, multiple processes each containing a single module each instantiating a single pepper plugin instance is created. However, this is an implementation detail (or maybe bug?) that is subject to change, and it would be better to defensively program and be able to handle multiple DidCreate events.
Of course, if your NaCl module is guaranteed to never be used by anyone else and you know you won't ever have two embeds of the same module, then it might be okay to assume singleton instance and use global state, but doing things the "right" way isn't that hard, so why not?
See native-client-discuss thread for more discussion on this topic.