I am using orika-core-1.5.4.jar in my Liferay 7.3.5 CE GA6 Portlet in order to map some classes. Everything goes well if I test it in a main method or if it is the first time when the portlet is deployed, but goes awry if I redeploy it - eg. when I make some changes and then deploy them. The error is the following:
java.lang.ClassCastException: ma.glasnost.orika.generated.Orika_MedicForm_FormDTO_Mapper850365342121300$0 cannot be cast to ma.glasnost.orika.impl.GeneratedObjectBase
From what I have read (here is an interesting article and also this stack article), this is because the first time, the class was generated with a AppClassLoader and the second time with RestartClassLoader - the articles refers to Spring applications. But I am not clear how to manage this. Now, I have to restart the server each time in order to avoid this.
Any ideas would help, thanks !
Related
I have an WAR style application that has been converted from Liferay 6.2 to 7.1. it needs to have SPA turned off and has been tested successfully when turning off SPA at the portal level but would like to turn off at the portlet level.
have tried adding the false property to the object in liferay-portlet.xml but the app doesn't load into Liferay correctly after that and complains.
this appears to be the recommended approach from https://portal.liferay.dev/docs/7-0/tutorials/-/knowledge_base/t/automatic-single-page-applications. there may be some "order" necessary to these properties? I can't determine exactly what that might be from this DTD https://docs.liferay.com/ce/portal/7.1-latest/definitions/liferay-portlet-app_7_1_0.dtd.html#single-page-application.
a further inspection of the error message that occurs when the portlet is loading provides help that indicates the properties order that should appear in the liferay-portlet.xml. I'm able to deploy the portlet without error now.
unfortunately, the portlet still does not act properly. its an EXTJs front end and there are consistent "The schema can only be reconfigured once" and "duplicate object" errors reported in the browser console. reloading the entire page works fine.
how might one start to debug this issue?
I disabled SPA in a WAR application by setting <single-page-application> to false in liferay-portlet.xml
See: https://github.com/jorgediaz-lr/index-checker/blob/master/docroot/WEB-INF/liferay-portlet.xml#L18
<portlet>
<portlet-name>index_checker</portlet-name>
<icon>/icon.png</icon>
<configuration-action-class>com.liferay.portal.kernel.portlet.DefaultConfigurationAction</configuration-action-class>
<control-panel-entry-category>
apps
</control-panel-entry-category>
<control-panel-entry-weight>1.5</control-panel-entry-weight>
<control-panel-entry-class>
jorgediazest.indexchecker.portlet.IndexCheckerControlPanelEntry
</control-panel-entry-class>
<preferences-company-wide>true</preferences-company-wide>
<preferences-unique-per-layout>false</preferences-unique-per-layout>
<single-page-application>false</single-page-application>
<header-portlet-css>/css/main.css</header-portlet-css>
<footer-portlet-javascript>
/js/main.js
</footer-portlet-javascript>
<css-class-wrapper>index_checker-portlet</css-class-wrapper>
</portlet>
If that setting is not working to you and causes errors, please copy your log traces with the problems.
Following the steps mentioned at mybatis-ignite integration page # mybatis-ignite with Ignite 2.0, i see that the call to the mapper hangs & never returns. This is after working around several other issues like requiring ignite-cache configuration to be placed in IGNITE_HOME/config/default-config.xml which still doesn't get picked up unless i place it in a physical location in the project dir (otherwise i see the error in the log "Initializing the default cache. Consider properly configuring 'config/default-config.xml' instead.") which again also seems to have no effect.
Since the integration seems to have several issues i am not sure if it is still supported..any thoughts from any one who has successfully done this or from the mybatis-ignite team would be great.
Edit: If it helps, i have placed a small self contained project # https://github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC that can be used to reproduce the issues i have mentioned.
I missed mentioning in the repo..but only the Ports table & schema is used for the purposes of the demo the other tables are not used. What happens is that in the file (github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC/blob/master/domain/src/main/java/com/brocade/dcm/domain/xml/PostsMapper.xml) if i remove the line "cache type="org.mybatis.caches.ignite.IgniteCacheAdapter" />" then everything will work fine without ignite caching. But the moment i add that line as shown in the uploaded file the mapper method calls just hangs.
the problem is: my web application uses ZK, which automatically generates random UUID for each web element.
When I try to record some basic test-case with Selenium IDE, it automatically tries to use these randomly-generated ID's, without even giving me a good alternative.
Is there a way to forbid Selenium IDE to use IDs while locating elements?
Possible workaraounds:
Implement ID generator in ZK: I've thrown away this possibility, because the application GUI is too complex for this task, and ID should be unique for whole sesion, which make this workaraound really hard to implement, when you have same elements on different page.
Find another recording tool: I've only found XLT script developer, which does the work by writing DOM-path using classes (which zk gives plenty) - but sometimes the location strategy gives false path, which is then not reproducible. Any good alternatives here?
You can change locater builder by changing the order of the locater in options>locater builder.
For example if you want to give first preference to css: name drag it on the top so when you start recording it will first give the preference to css name
Hope this will help you
I'm using JBoss 4.2.3, EJB2, XDoclet and have deployed one EAR with the EJBs in it, and other EARs with various websites in them.
When trying to access an EJB from one of the websites, I get NoClassDefFoundError.
It seems that the lookup is successful. I can see, for example, that getContext().lookup(SecurityServiceRemoteHome.JNDI_NAME) returns something of class "$Proxy266". I also see in JBoss's JNDI View this binding:
remote (proxy: $Proxy266 implements interface com.icumed.ifactory.service.session.SecurityServiceRemoteHome,interface javax.ejb.Handle)
FYI, SecurityServiceRemoteHome.JNDI_NAME = "ejb/ifactory/SecurityService/remote"
Right after the lookup, I call this, which is where the error is thrown:
home = (SecurityServiceRemoteHome)PortableRemoteObject.narrow(obj,
SecurityServiceRemoteHome.class);
I've heard that this might be unnecessary and I can just do a straight type conversion here, but I don't think that's the problem. From what I've read on the web so far, it seems like maybe the SecurityServiceRemoteHome cannot be fully loaded. Perhaps some ancillary classes are missing? I don't see any errors indicating this, though. What's the best way to go about debugging this?
After even more digging around, I found the answer. It has to do with the jboss-app.xml file and the loader-repository element. The background is that I previously had one complete EAR file with all the WARs and EJBs in it. I have decided to break them apart, and when I did so, I modified the jboss-app.xml files so that the archive name was different for each one. That was wrong. They must be the same between the EAR for the EJBs and the EARs for the WARs (Yes, I don't really need an EAR file if it's just a WAR...except on OC4J). Furthermore, I must have the loader-repository element present with an archive name. Leaving that out causes other problems.
Symptoms:
PumaLocator is unusable, every findXXX-method returns empty results or throws an exception because nothing was found.
Analysis:
The problem seems that, due to the ICEfaces specific architecture, the method GenericPortlet.doView is invoked only for the first time the Portlet is loaded, and not for the following (AJAX) page updates, e.g. in case of a called ActionListener.
If I use PumaLocator inside the doView-method, everything works fine.
I tried the following attempts yet:
Get the PumaLocator in doView, put it into Session and use it later - didn't work
Get the RenderRequest in doView, put it into Session and use it later to get a PumaLocator by passing that request - didn't work
I would be very glad to have any hints. Thank you!
PUMA checks the authorization for results by using information found in the Context. You must add JavaEE security roles in the deployment descriptor for the AJAX backend servlets the ICEFaces uses. As a thumb of rule if request.getRemoteUser() and request.getUserPrincipal() return something besides null you know PUMA will work. Otherwise it will NOT work and that is intended behaviour.
Alternatively you can attempt to disable the security checks of PUMA like this.