We can have a persistence storage for Session Variables using SessionStateMode as SQLServer. Why don't we need that flexibility for Application Variables? Is it because their size should be very less (common for all users)?
If we are thinking of a .net Web Farm, we might need to make these Application variables to be consistent. Can the SessionStateMode also stores the Application Variables? I see a table [ASPStateTempApplications], but it only have the columns AppId, AppName.
Related
I have an xctestplan in a library that I'm building that contains all the tests for the library. The tests need to access sensitive data. I would like to store this data in the environment variables for a scheme, but the tests don't seem to have access to these variables when I run them using a test plan. They only have access to the environment variables defined in the configuration for the test plan.
Is it possible for an xctestplan to inherit/access the environment variables from a scheme?
The reason I want to do this is because this library is publicly available on github. I want the xctestplan file to be tracked by git so that users can run the unit tests themselves if they want to. This file is stored in JSON format. If I add environment variables to the test plan, then they show up in this file. Therefore, I cannot store any sensitive information in this file. The temporary solution I have implemented is a separate, untracked, copy of the test plan that contains the sensitive data in the environment variables. This is not ideal because I need to keep these copies in sync with each other.
Storing the environment variables in a scheme is a better solution because I don't need to change it whenever I make changes to the test plan. It's also simpler to exclude schemes from git by unchecking the shared option.
I am creating a Spotify web API library. The sensitive information is the client id and client secret that Spotify uses for authentication requests.
With all of that said, if their is a better method of injecting sensitive data at runtime, I'm all ears.
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.
Have two instances of same application(as Dev/PROD) running under Virtual Hosts in a Dedicated server with two different domain names using Plesk Panel for management. I know it doesn't make sense Dev/PROD on one instance but DEV is used hardly 5-10% of time and we can't afford to have one more server. But the issue is Application variables used in PROD domain are being overridden by the variable in DEV. Is there any way to config webserver or Zend framework to see the two instances as separate spaces?
Here is a good solution that might be at help in your case.
Keep application.ini in version control without conflicting
I work on an existing Seam 2.2.0 + JPA (Hibernate 3.3.1) application that needs to be converted to a 'single database per client' environment where each database schema is the same. The application runs on Glassfish, uses IceFaces, and has several pages that utilize Conversations. It also uses a single EJB for authentication. Unfortunately, the decision to split clients off into their own databases is outside of my control.
As a proof of concept, I have already made the application aware of multiple databases by moving the management of EntityManagerFactory(ies) and DataSource(s) into the application using Spring JPA abstractions, resource local transactions, and ThreadLocal for context information. For example, each time a user logs in a new EntityManagerFactory is initialized using a new DataSource that communicates with their database if it has not already been initialized. This is working well in a test environment with a handful of databases.
My question is, will this approach scale to hundreds of databases? I expect to add application servers to a load balancer to handle additional load, but will the overhead of the Hibernate/JPA first-level cache and/or Seam context management (a.k.a., memory consumption) require significantly more servers to scale compared to a typical load balanced application? If so, can this be mitigated by allocating servers with lots of RAM and/or a large distributed cache?
Any insight would be greatly appreciated.
I worked on an application with this approach and I what I can point out is:
Datasource and EntityManagerFactory management is the hard part. However it seems you did this already in the test environment. Double check if you did things right in respect of the Seam Managed Entity Manager.
Your application won't scale well on hundreds of databases because you have a linear increase of memory consumption for each database. In fact, for each database you are going to have different instances of EntityManagerFactory (Hibernate SessionFactory) each requiring a considerable amount of Ram.
Beware of possible issues if you configure Hibernate second level cache. Since all SessionFactories are created from the same data model the cache region names may collide. I used hibernate.cache.region_prefix configuration parameter to make these names uniques among the various instances using the database id as the cache prefix.
I have a three applications that I would like to keep separate for manageability purposes. They run as a Plack server as suggested here, proxied behind nginx.
I would like to have a separate application to manage logins, and have that login and its authentication process shared across all other apps, with authorization done via roles.
I would like to use Catalyst::Authentication::Store::DBIx::Class for storage.
I have tried managing authentication at the Plack level with Catalyst::Authentication::Credential::Remote doing it at the Catalyst level (which would be ideal), but can't seem to make the login seen by the Catalyst apps.
Thanks for your help.
Sharing the store is easy -- you can either just use the DBIC session store and duplicate the config in all of the apps, or you can create a subclass of the DBIC store with a __PACKAGE__->config line containing the stuff that all of the apps have in common, and then specify your subclass in the session config.
As for the state -- you can use State::Cookie if the apps share a domain in common -- you just need to set the cookie_domain and/or cookie_path options in your session config so that the cookie gets set in a way that it will be visible to all of the apps, and set the cookie_name config option to the same thing in all apps, because otherwise they would all get different cookie names based on their different application class names.