Any method I write in *LocalServiceImpl is not found in *LocalServiceUtil. I re-run service builder every time and nothing. The methods are recognized on local server but not found in production server. All old methods are working, just new written methods are not found. What could be the problem? Thanks. I am using Liferay 6.1.1 GA2 on both servers.
this is my service builder log
[echo] Loading jar:file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/system.properties
[echo] 28.11.2013 08:30:46 com.liferay.portal.kernel.log.Jdk14LogImpl info
[echo] INFO: Global shared lib directory /C:/sbl-workspace-1-plugins-sdk/liferay-plugins-sdk-6.1.1/lib/
[echo] 28.11.2013 08:30:46 com.liferay.portal.kernel.log.Jdk14LogImpl info
[echo] INFO: Global lib directory /C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/lib/ext/
[echo] 28.11.2013 08:30:46 com.liferay.portal.kernel.log.Jdk14LogImpl info
[echo] INFO: Portal lib directory /C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/
[echo] 28.11.2013 08:30:47 com.liferay.portal.kernel.log.Jdk14LogImpl info
[echo] INFO: Properties for portal loaded from [file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/classes/portal-ext.properties, jar:file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/com/liferay/portal/tools/dependencies/portal-tools.properties, jar:file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/portal.properties]
[echo] Loading jar:file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/portal.properties
[echo] Loading jar:file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/com/liferay/portal/tools/dependencies/portal-tools.properties
[echo] Loading file:/C:/sbl-workspace-1/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/classes/portal-ext.properties
[echo] Building Menus
[echo] Building MenusImages
[echo] Building Sections
[mkdir] Created dir: C:\sbl-workspace-1-plugins-sdk\liferay-plugins-sdk-6.1.1\portlets\AdminSBL-portlet\docroot\WEB-INF\service-classes
compile-java:
[copy] Copied 65 empty directories to 65 empty directories under C:\sbl-workspace-1-plugins-sdk\liferay-plugins-sdk-6.1.1\portlets\AdminSBL-portlet\docroot\WEB-INF\service-classes
[javac] Compiling 398 source files to C:\sbl-workspace-1-plugins-sdk\liferay-plugins-sdk-6.1.1\portlets\AdminSBL-portlet\docroot\WEB-INF\service-classes
[zip] Building zip: C:\sbl-workspace-1-plugins-sdk\liferay-plugins-sdk-6.1.1\portlets\AdminSBL-portlet\docroot\WEB-INF\lib\AdminSBL-portlet-service.jar
[delete] Deleting directory C:\sbl-workspace-1-plugins-sdk\liferay-plugins-sdk-6.1.1\portlets\AdminSBL-portlet\docroot\WEB-INF\service-classes
BUILD SUCCESSFUL
Total time: 37 seconds
SOLVED:It worked like yannicular and Pankaj Kathiriya said. Thanks.....
Most probably, your service-build is failing. You can still see the old methods, because you are still using the old .jar, the last one that was successfully built. My advice is to check the build-service log and find the error that's failing the service-build task
Edit: Sometimes, conflicts from the Portal Deployment mechanism, or dynamic Class loading could lead to load Classes from an old service jar. If you are sure that your webapp is legit but the deployment fails, a fail-safe procedure to make sure you are deploying your application is:
Shut down the Portal
Delete the app folder from portal webapps.
Delete the app folder from work/Catalina/localhost
Copy your fresh webapp into /deploy and start the portal.
Bonus hint: If you are deploying into a running remote Portal, it's nice to copy your .war into the remote system, and then move it to the /deploy Folder. Else, if your connection is slow the deployment could start before the .war transfer is complete, the delpoyment fails and your app stays black-listed until you restart your tomcat
Could you Check the visibility of your methods: are they public ?
Service builder only creates *LocalServiceUtil methods for the public methods of *LocalServiceImpl.
It would be useful to see the your *LocalServiceImpl method to try to understand what is happening.
Well you should delete the service.jar which gets created when you build service.
Now again build the service.xml and check your methods will be populated under util class.
Try putting that .jar file under your Tomcat_home\lib\ext if it is being shared by multiple portlets.
This is an old problem but still doesn't have an accepted answer. As this question mentioned this old problem it came to my attention. In case somebody else stumbles upon it, here's a late guess on what might have gone wrong (from my answer to the other question):
First of all: Check the sourcecode for your *LocalServiceUtil and make sure it really doesn't have the method's implementation. If the method is there, you'll have to look elsewhere. Here's where:
When you deploy a portlet, you can get the API on multiple ways: Someone might have deployed the plugin containing the services on tomcat's global class path. If you don't update that one, you probably won't see your updates.
Also, someone might have copied an older version of your plugin into their own plugin as well - naturally not seeing any updates unless they update their dependency. Check for changed names of the jar file as well. Also check for the classes: Some people like to add the compiled java classes to their source directories, ending up with two different implementations of the same code.
Related
I'm trying to run a portlet in a Liferay Container that runs Apache Tomcat 7.0.59. The portlet refers to Clojure code in one of several fashions:
1) :gen-class :impl-ns ( this namespace is aot compiled, the impl-ns namespace is not )
2) Clojure.var("clojure.core", "require").invoke(Clojure.read(ns)); then calling invoke on returned IFN ( ns is also a non aot compiled namespace )
3) ring uberwar ( this is not a portlet )
The one I am most concerned with is the first one, but in all cases, while the leiningen test all pass (and it's calling the code the portlet is calling) I get frequent but intermittent errors while either starting up tomcat with the portlet/servlet deployed or while doing a hot deploy. The errors are symbol resolution errors in code I've unit tested and the unit test are passing:
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at portal_aot_common.CljJobManager.<clinit>(Unknown Source)
... 238 more
Caused by: java.lang.RuntimeException: Unable to resolve symbol: map->obj in this context
at clojure.lang.Util.runtimeException(Util.java:221)
at clojure.lang.Compiler.resolveIn(Compiler.java:6940)
at clojure.lang.Compiler.resolve(Compiler.java:6884)
at clojure.lang.Compiler.analyzeSymbol(Compiler.java:6845)
at clojure.lang.Compiler.analyze(Compiler.java:6427)
... 285 more
The code is not in the WEB-INF/classes directory or a jar in the WEB-INF/lib directory; instead I opted to modify the catalina.properties file and include the src path in the common.loader property. I've also tried using tomcat 7's virtualwebapploader virtualClasspath attribute.
The problem is that when it works, it works completely. But there always seems to be a 50/50 chance that it doesn't work and i get the above error. The code is not in jar (I like being able to modify the code and restart the server without having to install or build anything).
For the ring uberwar, the problem seems to be that the servlet cannot find the handler class on tomcat startup, but seems to be ok when I build the war and do a hot deploy. lein ring server works fine, but actually deploying seems to have a 50/50 chance of success.
I'm using clojure 1.6.0 and java 8.
Any ideas on what might be happening would be appreciated.
I'm working on a plugin for a 3rd party software that is quite undocumented. For the plugin I'm using a external lib (.jar) managed by maven and is later on executed on a tomcat server. Everything was working great till I updated to the latest release of the library, which now is using java.util.serviceLoader in order to load a concrete implementation of a interface. When build, my project has this package structure on a tomcat server:
mypluginPackage.jar
|
---META-INF
---lib
|
--- theExternalLibUsingServiceLoader.jar
|
---META-INF
|
---services
|
--- full.path.to.TheFactoryInterface
---external.lib.path
|
--- TheFactoryInterface.class
--- TheConreteClass.class
--- mypluginCore.jar
|
---META-INF
--- my.plugin.path
|
--- MyClassUsingTheExternalLib.class
As you can see, the external library has the correct services entry which is necessary for the serviceLoader to find the concrete of a interface within META-INF. The content of the full.path.to.TheFactoryInterface file is full.path.to.TheConcreteClass, which seems legit.
My plugin (package as well as the core) however do not have any of those META-INF information.
What happens now is that every time my plugin is using a method that will trigger the serviceLoader of the external library, the serviceLoader is unable to find the concrete implementation.
What I already tried is adding the exact same services/full.path.to.TheFactoryInterface to all my META-INF directories, which is not working (I guess I would need to change the content of the full.path.to.TheFactoryInterface file but I'm not sure - because of the undocumented plugin structure for the 3rd party software - what the right (relative) path would look like).
Can anybody give me a shot what I'm doing wrong here and how to fix it so the concrete class is found by serviceLoader? What META-INF folder should the services folder with it's content be placed in and should I change the paths? Is that the error at all or am I missing something compleatly different?
I understand that this is a very special topic since the 3rd party software is unkown, but any information depending serviceLoader and it's behaviour when run across multiple jars with multiple META-INF folders and in different execution context / classpaths would be appreciated.
I was able to get it working by extending the external lib so I'm able to provide a custom ClassLoader. Turned out, the default ClassLoader was wrong.
Also I was able to get in touch with the 3rd party tool devs and get the information I needed - call it "social decompiling".
Everything working now.
I'm using fabric8-karaf-1.1.0.CR5 in a stand-alone installation and it works fine there.
Now I wanted to embedd it into Eclipse Kepler SR2.
I basically followed Integrating Felix with Eclipse. But, instead of just adding bin/felix.jar to the project's build path as in Figure 8 I added all jars of lib and its sub-directories bin and endorsed (after a lot of errors were thrown at me by just adding lib/karaf.jar).
There are still three issues:
The following is printed to System.err:
Jul 28, 2014 12:12:24 AM org.apache.karaf.main.SimpleFileLock lock
Information: locking
What does this error(?) message try to inform me of? That a file named lock is created in the project's root directory? Thank you, but why?
The following is printed to System.err:
Error in initialization script: \shell.init.script
(The system cannot find the file specified)
The parenthesized is the Windows version of a FileNotFoundException's detail message. There exists an etc\shell.init.script and for the sake of the directory not mentioned I copied it to the project's root folder, to no avail.
I had to comment the following bundles in etc\config.properties:
#org/apache/sshd/sshd-core/0.9.0/sshd-core-0.9.0.jar=30
#org/apache/karaf/shell/org.apache.karaf.shell.ssh/2.3.0.redhat-610379/org.apache.karaf.shell.ssh-2.3.0.redhat-610379.jar=30
#io/fabric8/fabric-zookeeper/1.1.0.CR5/fabric-zookeeper-1.1.0.CR5.jar=39
#io/fabric8/fabric-api/1.1.0.CR5/fabric-api-1.1.0.CR5.jar=40
#io/fabric8/fabric-agent/1.1.0.CR5/fabric-agent-1.1.0.CR5.jar=40
#io/fabric8/fabric-core/1.1.0.CR5/fabric-core-1.1.0.CR5.jar=45
#io/fabric8/fabric-boot-commands/1.1.0.CR5/fabric-boot-commands-1.1.0.CR5.jar=45
#io/fabric8/fabric-commands/1.1.0.CR5/fabric-commands-1.1.0.CR5.jar=50
#io/fabric8/fabric-configadmin/1.1.0.CR5/fabric-configadmin-1.1.0.CR5.jar=50
... to get rid off errors of the form:
ERROR: Bundle <Bundle-SymbolicName> [<ID>]
Error starting mvn:<bundle-path> (org.osgi.framework.BundleException:
Unresolved constraint in bundle <Bundle-SymbolicName>:
Unable to resolve <ID>.0: missing requirement [<ID>.0] osgi.wiring.package;
(&(osgi.wiring.package=<Other Bundle-SymbolicName>)(<versions>))))
... but with these bundles disabled Fabric8 shuts down immediately.
It's right, the few missing bundles I have checked aren't in my local .m2 repository. But Maven works well with all other projects, in and out of Eclipse. Go on Fabric8, download them!
What am I missing?
I want to replace the auto injected log object, which is of type org.apache.commons.logging.Log with an object of type org.slf4j.Logger, so that I can use it properly with Logback.
Therefore I need to create a ...Transformer class (written in Java) - that's what I got from Graeme Rocher over at the "grails-user" mailing list. I'm also aware that I have to pack this ...Transformer class within a plugin and make it a *.jar archive which I can load within the lib/ folder of the plugin. But I guess I'm doing something wrong here as I have the class, along with a META-INF folder which contains the MANIFEST.MF file as well as another folder services which holds the following file org.codehaus.groovy.transform.ASTTransformation which holds just one String: the canonical name of the ...Transformer class.
Now, if I try to do a grails clean everything is fine, BUT if I try to run grails package-plugin the console comes up with a java.lang.ClassNotFoundException.
Clipping from Stacktrace:
| Packaging Grails application...
| Error Fatal error during compilation org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Could not instantiate global transform class my.package.ast.LoggingTransformation specified at jar:file:/C:/Source/MyGrailsAST/lib/replace-logging-logback-ast.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception java.lang.ClassNotFoundException: my.package.ast.LoggingTransformation
1 error
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Could not instantiate global transform class my.package.ast.LoggingTransformation specified at jar:file:/C:/Source/MyGrailsAST/lib/replace-logging-logback-ast.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception java.lang.ClassNotFoundException: my.package.ast.LoggingTransformation
Does anybody have some experience with Grails plugins which handle with AstTransformer and could give me some advice on this? Is there a good tutorial out there which I haven't seen so far?
Please let me know ;)
so, after some research, browsing and finally asking at the Grails Mailing List (see the mailing list archives at: http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html I found a solution.
my goal was to create a Globals ASTTransformation, to inject a org.slf4j.Logger object instead of the usual org.apache.commons.logging.Log object into every Artefact class without annotation.
so, here are the steps:
I created Java class similar to https://github.com/grails/grails-core/blob/master/grails-logging/src/main/groovy/org/codehaus/groovy/grails/compiler/logging/LoggingTransformer.java but with my own implementation of the org.slf4j.Logger object. It is crucial that you place the Java.class under the following package: org.codehaus.groovy.grails.compiler as
Grails scans for classes that are annotated with #AstTransformer in this package. (Graeme Rocher)
and pack it into a JAR along with its MANIFEST.MF file within the META-INF/ folder. A META-INF/services directory with all its stuff is not needed as Graeme Rocher stated:
You do not need the META-INF/services stuff and I would remove it as it is probably complicating matters.
So, I guess this statement was more related to my specific problem as I only have one #AstTransformer class within my plugin, but that's just a guess. And I haven't searched for further informations on this topic. Maybe some other developer here who needs this could do some research and share his solution within this thread...
The JAR should be imported to the plugin and placed under the lib/ directory. After this you should be able to do grails clean, grails compile and grails package-plugin.
If you want to replace the log implementation, as I did, you should exclude the grails-logging and grails-plugin-log4j JARs from your designated project's classpath. This is done in the BuildConfig.groovy file:
inherits("global") {
excludes "grails-plugin-log4j", "grails-logging"
}
Now install your plugin grails install-plugin \path\to\plugin.zip and everthing should work as expected.
Hope this helps...
I was asked in a precedent question to be more precise about my compilation error message. Here's the fact : I know nothing about GWT and Java. Following the docs, I tried to compile Java files from a web project that had been precedently developed using GWT. So, to test and understand how all this work, I took the java folder (that had been precedently compiled with an appropriate tool)
into src folder of a web app project in my ide Eclipse
When running the compiler using the command GWT Compile, I had this message error :
Compiling module java.org.primagora
Validating newly compiled units
Ignored 5 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
Finding entry point classes
[ERROR] Unable to find type 'org.client.primagoraEntryPoint'
[ERROR] Hint: Check that the type name 'org.client.primagoraEntryPoint' is really what you meant
[ERROR] Hint: Check that your classpath includes all required source roots
When I look at the error on the file, for example java.org.client.primagoraEntryPoint, I find an error when it is declared "package org.client" at the very beginning of the file. There seem to be an error path. I thought the java folder I took would be correctly implemented in Eclipse.
Is that clearly a file path problem ? How should I debugg it ? (I reallly know nothing about gwt, java , eclipse)
Best,
Newben
Where is your GWT module file (i.e. a file that ends in .gwt.xml), and what are its contents? The package you list for your entrypoint is org.client, and the full name is org.client.primagoraEntryPoint, suggesting that there is a file in org/client/primagoraEntryPoint.java. By default, module files include the client package relative to them as source, so if the file is in the wrong location, this won't work correctly.
Based on this, your module file should be in the org package:
src/
org/
SampleModule.gwt.xml
client/
primagoraEntryPoint.java
From the very beginning of your error, you list java.org.primagora as the module:
Compiling module java.org.primagora
This suggests the following structure:
src/
org/
client/
primagoraEntryPoint.java
java/
org/
primagora.gwt.xml
This doesn't make sense, since GWT is now looking for a java.org.client package instead of a org.client package. Try using the package setup mentioned earlier here.
A better option might be to pick an existing working project, like what the GWT plugin for Eclipse will create, or one of the samples in the GWT download.