I need to define some custom properties in an hook (e.g. myhookname.myproperty) and read them in my hook Java classes.
I know I can't create a custom property file (because it will be deploied in the hook's webapps dir, but hook will "live" in the ROOT context)... so the only idea seems to add new properties in portal-ext...
But, in this way, the hook deploy can't be consistent (because it needs for a modification of portal-ext).
What is the Liferay way to do this?
Do you have other idea to achieve my needs?
Thanks
See Extending and Overriding portal.properties in Liferay 6.2 Developer's Guide.
How to:
Create portal-hooked.properties file in the classpath root of your hook (ie. src/main/resources in case of Maven built project). Let's assume the file will contain my.custom.property = Aha definition.
Register the file in liferay-hook.xml:
<hook>
<portal-properties>portal-hooked.properties</portal-properties>
</hook>
Now you can read the property value in Java code using PropsUtil: com.liferay.portal.kernel.util.PropsUtil.get("my.custom.property").
Related
I'm trying to remove sample data (Welcome screen and everything else) from my Liferay server.
I tried to:
remove all directories from the webapps directory except ROOT directory
create new (blank) portal-ext.properties in ROOT/WEB-inf/classes (there was no portal-ext.properties file)
search via Google :)
Nothing of the above helped. Thank you for your advices.
You might have configured a database, or are using the built-in demo hsql database. This holds all the regular data. If you've configured Liferay to access another database either remove the tables from that database or point to another one. There's also the document library that holds documents and images (the binary content). By default they all live in the data directory, on the same level as your tomcat directory (assuming you use a bundle)
A new blank portal-ext.properties will not help you, as it overrides all the standard values defined in Liferay. If there's no content, you're using all the default. And the file should rather be in ${liferay-home}, e.g. the directory that also has the tomcat directory in a bundle.
As you've removed all content and bundled webapplications anyway, you can also just install a new bundle in another directory and use it, pointing it to a new database.
I have loaded a custom jar file into WSO2 by placing it into the /repository/components/lib directory, performing a restart. I then call that class from a script mediator using inline groovy. The groovy script recognizes the class, however the custom class is attempting to load a properties file that must be on the classpath. I have put that property file nearly everywhere but I keep getting an error that it cannot find the file on the classpath.
I am running the standalone WSO2 ESB 4.7.0. I have put the file as part of the jar, I have also attempted to place it in several directories within the WSO2 file structure as well. All to to avail.
you could try to register a resource in the carbon registry and add a Property to this Resource. Basically there are two ways (in java...):
Here is an example how to connect to the registry via a service with the PropertiesAdminServiceStub: http://www.massapi.com/class/org/wso2/carbon/registry/properties/stub/PropertiesAdminServiceStub.java.html
The most important here is that you authenticated your user, the result is a cookie which yoou have to add to the stub.
The other would be something like this (probably a duplicate of your question)
I am unable to get the list of services with in the applicaton i.e.; wso2 governance registry? I am working with binary code
The last one asumes that the carbon-context is available, means you are running the search inside the wso2 like a feature for example.
Unfortunately there is no place to put that properties file. Luckily this jar file, is an in house entity. It was written to search the classpath for the properties file and upon not finding one on the classpath to throw an exception. We ended up rewriting the code that loads the properties file to upon not finding the file on the classpath to search in a directory which we specified as a system environment variable in the wso2server.sh file. Not very elegant, but it is working perfectly.
When I try to generate a javadoc, using the menu command Project\Generate Javadoc, the following warnings and error are produced for my custom classes in XPages:
javadoc: warning - No source files for package net.focul.utilties
javadoc: warning - No source files for package net.focul.workflow
javadoc: error - No public or protected classes found to document.
The packages are in the WebContent/WEB-INF/src folder which is configured in the build path and are selectable in the Generate Javadoc wizard. The classes are public with public methods.
Javadocs are generated for all of the Xpage and Custom Control classes if I select these.
You're experiencing this behavior because javadoc doesn't understand the Designer VFS (Virtual File System). It assumes that your project consists of a bunch of separate files in some folder structure on your local hard drive, not self-contained inside a single NSF. On the whole, the Designer VFS successfully tricks Eclipse into believing it's interacting with local files by intercepting read/write requests for project resources and importing/exporting DXL or CD records, etc. But apparently they haven't applied this sleight of hand to javadoc as well.
The Java source files corresponding to each XPage and Custom Control are processed successfully because, ironically, they are never stored in the NSF. During every project build, Designer discards any of these it has already generated and re-creates them based on the current contents of the various .xsp files. It then compiles those Java files into .class files, which are stored as design notes inside the NSF. At runtime, it's these files that are extracted from the VFS and executed... the source code no longer matters at this point, so there's no reason to ever bother including the .java files in the NSF, so they're just kept on the hard drive. One indication of this behavior is that the folder is named "Local" when viewed in Package Explorer / Navigator.
If you're using the built in (as of 8.5.3) version control integration (see this article for a great explanation of how to use this feature), you can tweak the Build Path to include the copy of the src folder stored in the on-disk project as a "linked source folder". This causes javadoc to consider the duplicate copies valid source files, and therefore includes them in the generated documentation. On the downside, it also causes Designer to consider them valid source files, which causes compilation errors due to the duplication. So this approach is only viable if you only need to generate the documentation on an infrequent basis, and can therefore break the Build Path temporarily just to run javadoc, then revert to the usual settings.
An alternative is to actually maintain your custom Java code this way on an ongoing basis: instead of creating the folder in WEB-INF inside the NSF, just create a folder on your hard drive that stores the source, then include that location as a linked source folder indefinitely. That way Designer can still find the source, but so can javadoc. NOTE: if you go this route, then you definitely need to use SCM. Because your source code no longer lives inside the NSF, providing the convenient container we're used to for getting the source code to other developers and ensuring inclusion in whatever backup schedule you use, the only place your source code now lives is on your local hard drive. So make sure you're regularly committing those files to Git / Subversion / Mercurial, etc., or, at the very least, storing them on some file server that is backed up regularly and, if applicable, accessible to all other members of the project team.
When you expand the net.focul.utilties in Designer, you will see all the methods and properties. But when you click on on of the methods, you will see neo source code.
So this is where javadoc fails to generate the documentation. I guess that the author of the application has not provided you with the source code. If you have the source somewhere, you can attach this code and then javadoc will be able to generate the documentation.
I run into the same situation and I have found the most straightforward method is to export the source to an external folder and then use regular Eclipse to generate the JavaDoc. Not sure my process is any less of a hassle than Tim's suggestions but for me it just feels less risky than trying to deal with the VFS vagaries.
We ship a framework assembly for logging which internally uses nlog. We also ship an embedded nlog configuration as a resource in our assembly and read this on startup (a static constructor within our wrapper which wraps over the nlog wrapper using the XmlLoggingConfiguration class).
We would now like developers to be able to specify/override additional configuration via an external file for their own loggers (using the same nlog configuration file format).
Can we:
Refer include files in our embedded nlog configuration file? How is the path of the include file resolved? If we do this, does the content of the include file override the content of the embedded nlog configuration we read on startup?
Can developers use the nlog configuration section? Does the content of this section override the default configuration we have specified pro grammatically?
Any other options?
How is the path of the include file resolved?
You can use in the included file name:
layout renderers such as ${baseDir},
nlog variables.
If the resulting filename is not absolute, it is combined with the directory, where the original NLog configuration was located, but this may be null in your case, so you are limited to first 2 options.
does the content of the include file override the content of the embedded nlog configuration?
No, this content is added to the content of the embedded configuration.
Does the content of nlog configuration section override the default configuration we have specified programmatically?
When you set the configuration programatically, you override any configuration that was set before and also disable the automatic configuration discovery, including one from application configuration file or NLog.config.
But you can check whether the configuration is not null first time before you set the embedded value. This will trigger the automatic discovery, and in case if any logging configuration is found, the returned value would be non-null.
I am trying to use log4j logging framework in a java desktop application.
When I run the code I am getting a message
log4j: log4j:WARN No appenders could be found for logger
I googled for the above error and found that it occurs when the log4j.properties file is not found by the app.
I am creating the desktop app using Eclipse. Currently log4j.properties is within the same folder that contains the source (in 'src' folder). Where should I put this file to make it work properly?
log4j will use a Default Initialization Procedure to find your configuration file. The documentation notes:
The preferred way to specify the default initialization file is through the log4j.configuration system property
If this property is not set - log4j will look at the classpath. In your case you have to place the file in the src directory (assumed that the content will be put in the classes path while you build the system). If you use maven place the file to the src/main/resources directory.
As you placed your file to the src directory check, that the file get transferred to the top level directory of your compiled classes.
Keep the properties file in the classes folder i.e. the folder that contains the classes (specially the main class).
Another reason for getting this error may be the wrong appenders or an appender without setting.