In which file or under which folder path (moodle folder) can I get the source code of the web service? THX
You can find a list of core web service definitions in lib/db/services.php
https://github.com/moodle/moodle/blob/master/lib/db/services.php
Each service will contain class name and method name, you can find the source of that particular service in mentioned class and method.
Other third-party plugin webservices will be defined in that plugins folder (plugin/db/services.php) file.
Related
The documentation states that I can configure the liferay server to use my own templates for the email messages. Specifically, if I add these properties to a portal-ext-env.properties in $CATALINA_BASE/conf/liferay:
blogs.email.entry.added.enabled=true
blogs.email.entry.added.subject=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_subject.tmpl}
blogs.email.entry.added.body=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl}
Liferay will supposedly use the templates in the specified paths (com/liferay/portlet/blogs/dependencies/email_entry_added_subject.tmpl and com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl). The thing is, it's not very clear what these paths are relative to. Are these files relative to $CATALINA_BASE? For example, would the above configuration result in Liferay looking up $CATALINA_BASE/com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl for creating the body of an email message? If this is not the case, where does Liferay lookup templates for Blog-related email messages?
After some digging, I've found that you place the templates in the $CATALINA_BASE/webapps/ROOT/WEB-INF/classes folder. Paths that you reference in the properties (e.g. blogs.email.entry.added.body=${resource:com/liferay/portlet/blogs/dependencies/email_entry_added_body.tmpl}) are relative to the aforementioned classes folder.
So, if I wanted Liferay to use a template file in the ff. relative path: org/foo/my_email_entry_added_body.tmpl, I would do two things:
Place the file in $CATALINA_BASE/webapps/ROOT/WEB-INF/classes/org/foo/my_email_entry_added_body.tmpl.
Add the following line to $CATALINA_BASE/portal-ext-env.properties: blogs.email.entry.added.body=${resource:org/foo/my_email_entry_added_body.tmpl}.
I consulted my co-worker and got a better understanding of why this is. The architecture of a Liferay application is such that it comes bundled with a Tomcat server. According to the documentation, WEB-INF/classes is a directory that a web app deployed to a Tomcat server looks up for classes and resources:
A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
Specifically, this folder is high in priorty in the web app's classpath.
When you see Liferay code similar to ${resource:path/to/foo}, it's looking up resources in its classpath. One of the paths in that classpath is WEB-INF/classes. Hence, if path/to/foo is placed in WEB-INF/classes, Liferay will find path/to/foo there.
I have an EAR installed in eclipse on WLP 8.5.5.3
This is the EAR entry with a classloader attached:
<enterpriseApplication id="App4EAR" location="App4EAR-4.1.5-SNAPSHOT.ear" name="App4EAR">
<classloader apiTypeVisibility="spec,ibm-api,api" delegation="parentFirst" commonLibraryRef="baseLibraries.app4">
</classloader>
</enterpriseApplication>
The server is starting without issues. The first jsp page in the application tries to read a properties file which is located in the WAR component. This is where it fails.
SRVE0777E: Exception thrown by application class 'java.util.ResourceBundle.throwMissingResourceException:1427'
java.util.MissingResourceException: Can't find bundle for base name prop.appadmin, locale nl_BE
The object that reads the properties is located in the web application together with the properties file. The utility class for reading the resource bundle is in a separate jar and is part of a shared library (baseLibraries.app4).
This is an entry from the App4EAR.ear.xml deployment definition that points to folder where the properties file is located:
<dir sourceOnDisk="C:\svn\app4\App4Web\target\classes" targetInArchive="/WEB-INF/classes"/>
When using java.util.ResourceBundle() directly in the application it successfully locates the properties file. But not so when we use the utility class from the shared library.
Why is a shared library not able to access properties resources in the main web application?
Your shared library is loaded in parent classloader, and the classes and also properties in your application are not visible to that classloader thats why they cannot be found. Add property files to the classpath of the library instead of web app.
Packaging the utility jar, that accesses the resource file, in the web application solves the problem.
This solution kind of negates the purpose of shared libraries. Also note that on WAS 8.5 this was not a problem, so something did change in the way shared libraries are exposed/loaded.
I am learning HTML5 integration with REST web services.
Using information mentioned at URL:
Redhat tutorial for HTML5 app
I created sample application in my eclipse workspace. Generated code structure is as shown below:
I do not understand why all web resources are stored are shown as a deployed resources? Does not it mean that, they are not part of my source code? I thought there would WEB-INF directory, under which my web resources will be stored. Please correct my understanding.
I found that it is just the way eclipse displays the structure of workspace. But in actual file system, web resources are stored under:
src/main/webapp
I have developed an eclipse plugin which references an external jar present in a external installation directory.
So I have added an entry to my bundle classpath as below:
Bundle-ClassPath: external:C:\mylib.jar
My class loads properly - and the plugin is able to detect a class MyClass present in this external lib.
However, the method a() - I am calling in the class MyClass is failing.
Method a() is as follows :
public void a()
{
URL url = this.class.getClassLoader().getResource("META-INF/startup-jar ");
...
}
so the URL which is returned is that of the eclipse plugin directory C:\eclipse3.4\test
and not of the physical location of the external jar which is C:\mylib.jar
This is causing method a() to fail. Now, my question is -
As I don't have the external jar copied to my plugin directory (it is only present on the plugin classpath)
how can I ensure the classloader gets the URL path of my external jar and not of my plugin directory?
Note : I cannot change the classloading mechanism in the external jar as it is a third party dependency and I have no control over the code. So please suggest a solution which would help me to load the external jar class correctly so I can get the correct URL.
Thanks a lot for your help - in advance
To explain a bit more on the problem I am facing ::
My external jar is present inside the installation directory of my server installation.
When the class in my external jar calls the URL url = this.class.getClassLoader().getResource("startup-jar")
it returns the URL relative to the eclipse bundle path -
Something like C:\eclipse3.4...
and this URL is used for getting the boot directory (installation directory of the server) .
So it should have returned a path which is relative to the server installation directory, but instead returns a path relative to the eclipse installation directory.
Because of this, I am not able to call any APIs on the server as the server installation directory which it tries to use is incorrect.
So I wanted to know what is the best way I can handle this, so that this method call returns the server installation dir and not eclipse bundle path.
Can't you wrap this 3rd party dependency with the correct OSGI metadata and install it as a plug-in/bundle? We did this for all 3rd-party dependencies, including problematic ones such as Hibernate and made them work.
If it's a popular open source library, you can probably find it with the OSGi metadata added at Spring's repository: www.springsource.com/repository/app
In general, I wouldn't recommend the pattern of referencing external JARs as you describe in your question.
Background:
I have a small problem with Eclipse. I'm working on a workbench plugin which has some classes that validate incoming XML data against a schema. The schema lives inside the plugin project in a "./schemas" folder.
Questions:
When I run the application, how can I read the schema without using a hardcoded path?
When the application is deployed the schema will need to live inside a plugin .jar. Will the solution from (1) be any different in this case?
You can use the FileLocator class from org.eclipse.core.runtime to get a URL to a resource in your bundle.
For example, something like
URL schema = FileLocator.find(myBundle, new Path("/schemas/data.xsd"), null);
You can get your Bundle object from the BundleContext passed into your Activator (if you have one). Or you could use Platform.getBundle.
You should not assume the url is a file on disk, for exactly the case when the plugin is a jar. You can use URL.openStream to get the contents, or FileLocator.toFileURL() to get a file on disk.