I am currently working on creating a web service using Spring -WS.
I want to make the request reach my own Message Dispatcher Class. So I made the necessary configuration changes to web.xml and also my sping-congfig.xml file.
I am seeing an error when spring loads beans for my Message Dispatcher,
it tries to look for a properties file in my package which has the Dispatcher Class. for Example if my class is AccountMessageDispatcher, it looks for AccountMessageDispatcher.properties file in the package where I have created the class, I can get it running by keeping the properties file there, but I want to keep the properties file under my resources directory which has other property files needed by my application.
Can any one help me or point me in the right direction as to what I am doing wrong?
If we take a look to the default MessageDispatcher infrastructure, we'll that it reads appropriate proerties file - org.springframework.ws.server.MessageDispatcher.properties.
As you see this file is located at the same package as the original MessageDispatcher class.
According to your concern, you are right: that file should be located at the resources dir for sources. But if you use normal build system like Maven or Gradle, all your resources are packaged to the target jar alongside with classes.
To achieve your requirements you just need to create the same dir tree in the resources as your original AccountMessageDispatcher.
Actually any Java package is a dir in the end jar.
Related
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
I have an EJB that plays the role of my web service class too. I use Oracle Weblogic 12.1.2 as JavaEE container.
Here is the code of that class:
#Stateless
#WebService(serviceName="MyService")
#Policy(uri = "Wssp1.2-2007-Https-UsernameToken-Plain.xml", attachToWsdl=true)
#XmlAccessorType(XmlAccessType.FIELD)
public class MyWebServiceBean{
// some web methods ...
}
The attached policy and its corresponding wsse tags is properly can be seen in generated WSDL file. However, there is a IncludeTimestamp tag in the generated file that forces clients to send Timestamp in their request. As in my environment clients may have different times, I perefer not to force them to send the time! Then I simply omit the IncludeTimestamp Tag from the server wsdl and everything goes well after that! But I do not want to handle it by hand. Is there any setting in weblogic 12.1.2 to configure existence of mentioned tag?
After a lot reading and searching for this matter i found that we should create Custom Policy. Firstly we should find the xml file of the desired policy. Flow this post to do so. Then we should edit it and copy the edited version in our classpath and for #Policy annotation we should use new address of our xml file! That's it.
I have installed the spring security core plugin. I need to modify the login page to look like my existing website. I have searched the entire project and cannot find it. I am running grails 2.4 and spring-security-core:2.0-RC5. Where can this pesky little file be? Can someone who is not a complete greenhorn help a fellow out?
As #Abs points out, the file is at target/work/plugins/spring-security-core-2.0-RC5/grails-app/views/login/auth.gsp but you shouldn't edit plugin files. Other developers on your team won't have access to the modified files and if you delete the target directory you'll lose your changes since the target directory is only a temporary work location.
Instead, copy the file to the same relative location in your application and make changes there. Create grails-app/views/login and copy the file there and make whatever changes you want.
This technique works for most plugin files, not just GSPs. The compilation order and classpath are configured such that application files and classes override plugin files if they're in the same location/package.
You can find the default login page here
targt->work->plugins->spring-security-core-2.0-RC5->grails-app->views->login>auth.gsp
I am building a Dart application. It needs to load code from a third-party package, which is only known at runtime. My application needs to:
auto-discover the dependency
load a library from that dependency
interact with the dependency
Ideally, I do not want to require that my users specify the third-party dependency. The application should auto-discover the dependency.
For example, a workflow could be something like this:
User installs my app (pub global activate my_app)
User installs a "plugin" (pub global activate plugin_for_my_app)
User runs my app (my_app)
The app auto-discovers that plugin_for_my_app exists.
The app loads the plugin (via spawnUri perhaps?)
The app calls into the plugin
Requirements:
Must run from the command-line.
Must work on Windows, Mac, Linux.
Should (but doesn't have to) run when compiled to JavaScript.
pub run support is optional (pub run makes it tricky, because it rewrites your import URIs, so it's not a requirement)
What's the best way to do this?
This package https://pub.dartlang.org/packages/plugins seems to do exactly what you want (haven't used it myself yet though) by loading plugins into isolates.
This is not directly answering the question (CL tools as requested), but I use plugins in the browser and wanted to share my "pattern".
My web application imports includes.dart which is a dynamically generated file that imports all .dart files found in a specified directory. The file gets (re-)generated at app startup by the backend, just before serving the files to the browser. The found .dart files implement a public api (eg. init() and run()) so that the main application can call their code. The plugin code are not loaded into separate isolates but are executed in the same isolate as the main app which gives the benefit of plugins sharing the same heap and you're able to access the plugin code directly. This solution also assumes the plugins resolve their own dependencies.
This setup works fairly well for my use case. However, as there's no real dynamic code reloading in Dart (yet, I hope. see https://code.google.com/p/dart/issues/detail?id=10530), there's always a refresh step needed to load the new code.
In the plugins package, currently, there is no way to resolve dependencies through pub. When I originally designed the API it was assumed that the dependencies were already retrieved through pub get. With that said, plugin discovery on the file system is simple.
As you can see in the example in the README, loading plugins was as simple as new PluginManager().loadAll(String directory) which would automatically discover all plugins inside the directory and load them. This solution is ideal if all plugins are to be in one folder.
It is possible to do individual plugin directory loading as well, provided it follows the plugin directory structure. Using a PluginLoader you can load in a directory that contains the necessary files for a plugin to run properly. It is not necessary to call load() since the PluginManager will take care of calling in load for you.
A simplified way of loading a plugin
Instantiate the PluginManager.
PluginManager pm = new PluginManager();
Determine the plugin you want loaded. The plugins library will automatically
determine the pub cache directory. As per the documentation of pub, the PUB_CACHE environment variable is also supported.
Load in the plugin. A Future is returned with a Plugin object that provides basic information about the plugin. The plugin requires a pubspec.yaml with a name, a packages directory, and a bin/main.dart source file. However we are loading from the pub cache, so we do not need to worry about the setup of the plugin, the only requirement is the package from the pub cache supports the plugins package.
pm.loadFromCache("test-1.0.0").then((Plugin plugin) {
print("Plugin loaded!");
handle();
});
After all the plugins you desire to be loaded are initialized, the manager can now listen for requests properly. Simply use the listener to 'see' the incoming data.
The plugin side
The plugin simply uses a receiver as provided by the plugins API.
void main(List<String> args, SendPort port) {
Receiver rec = new Receiver(port);
rec.listen((Map<dynamic, dynamic> data) {
print("Received data: $data");
});
}
I wrapped the plugins package with a bit of sugar to provide some extra things like declarative RPC. It's very flexible, and samrg472 (the author of plugins.dart) is a good friend, so I have asked him to comment as well.
https://github.com/PolymorphicBot/PolymorphicBot/blob/master/lib/src/core/plugins/handler.dart
I needed some templates to render some code for users to paste. I put these into
/project-dir/grails-app/resources/templates/quickInstallCode.html
Then I tried accessing them using their relative path (grails-app/resources/templates/quickInstallCode.html), and it worked great.
When we then deployed the application to a Tomcat Server, using a .war file, the paths began pointing to a wrong location.
ERROR call, Template file /var/lib/tomcat6/grails-app/resources/templates/quickInstallCode.html not found.
I assumed, that Grails, giving good defaults for everything would handle this mess for me, but it seems like it does not.
I also tried this call, and it seemed to work great, but when deployed, the BuildSettingsHolder did not contain build Settings, which resulted in a fatal error.
BuildSettingsHolder.settings.baseDir.toString()
http://grails.org/doc/latest/api/grails/util/BuildSettingsHolder.html
http://grails.org/doc/latest/api/grails/util/BuildSettings.html
I am pretty frustrated that I cannot get this easy task to work, but the reason that this is so complicated seems to be that all Files are encapsuled in a WAR and not unpacked on the Server.
So the Questions are:
Where in your Project would you put
Files like this?
How to get a
reliable and stable way to access
this files? I just need a stable path to a base directory, without having to hardcode something in the configuration ... This cannot be so hard.
I have 2 solution to propose for this situation:
Save the template in the database, in a setting table. This way guarantees that nothing can go wrong.
You can consider using the resource folder like Sachin & Nirmal has proposed. About security, I think you can configure SpringSecurity Plugin to protect the specific resources, so that it can only be accessed by the site user.
Take a look at this link and try to use the getResource that spring provides. Its way more flexible and configurable.
def filePath = "resources/file.txt"
def appHolder=ApplicationHolder.application.parentContext.getResource("classpath:$filePath")
By the way Conf is on the root of the classpath, you can stick the files in src/java or src/groovy.
I keep my static resources in web-app folder and access them like this
ApplicationHolder.application.parentContext.servletContext.getRealPath("quickInstallCode.html")
// quickInstallCode.html should be in web-app folder.