[MAGNOLIA-3854] not imported class [mgnl.admininterface.Navigation] Created: 01/Apr/11 Updated: 03/Jul/14 Resolved: 02/Jul/14 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface |
| Affects Version/s: | 4.4.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | kristof vereecke | Assignee: | Daniel Lipp |
| Resolution: | Outdated | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
windows 7 64 bit, websphere 6.1 network deployment Fix pack 25 |
||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
installed the latest websphere war 4.4.2 into websphere network deployment into a separate server instance. when reaching the url: "not imported class [mgnl.admininterface.Navigation]" clicking ok on that popup shows me the admin central without navigation |
| Comments |
| Comment by Zdenek Skodik [ 01/Apr/11 ] |
|
Hi Kristof, last time I've tried to deploy Magnolia to Websphere was at 4.4.1 times, successfully. I don't see anything that would introduce such issue for 4.4.2. The mgnl.admininterface.Navigation refers to the Navigation.js of the AdminInterface module. If I recall properly there was some issue for WAS 6.1 branch related to javascripts loading. Maybe it would be enough to restart it or redeploy to let WAS load the javascript properly, but personally I would update to the latest fix pack - no. 35 - using this one I haven't run into any issue. Eventually I can put somewhere around the war file that works for me if you would like to give it a try, but there was really no special modification in it, the was module takes care of it by its own. |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
upgraded to WAS - FP35, still the same issue. I will redeploy everything again ... |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
I use magnoliaAuthor as context root. This is correct ? |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
There is no limitation for the context root path, as long as you provide appropriate configs in your war file. I used the default magnoliaAuthor.
Not that I know of. I use default settings for the latest fixpack. |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
i reinstalled everything: same result As such, i thinck this is something related to the latest release 4.4.2 ? |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
Well I took the default 4.4.2 EE war file for Websphere, extracted it to to point to MySQL (a Derby issue for Websphere), built the war file again, deployed into WAS 6.1_35 (contextRoot = magnoliaAuthor != applicationName = the name of the war file AND I put it into my own virtual server "localhost") and installed Magnolia CMS which works just fine, no errors. Hopefully your logs from the deployment/installation phase would shed more light. |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
No problem in retrying |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
I would expect related records still written into your logs' history, but if you prefer retrying |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
just reinstalled 4.4.2 with following results screenshot attached with some warning after magnolia update |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
websphere log files after fresh install of 4.4.2 of magnolia |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
log files of magnolia after install/update/first login |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
installed on websphere 6.1 network deployment fixpack 37 (on separate server instance) |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
directlry list of 4.4.2 deployment of web-inf/lib dir |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
4.4.2 file was installed as is, was not changed in any way. (just as the 4.4.1 file also was not changed) |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
btw: thanks for the help and very fast responses |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
will need to update the log files something happened with it as they are empty |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
You attached empty zips. Nevertheless I guess it has something to do with your websphere network deployment. What I run is IBM WebSphere Application Server, 6.1.0.35 Build Number: cf351044.07 Build Date: 11/5/10 and the war file is targeted to the real application server. I even don't know what the network deployment is, but if it means the same what its name suggests, the issue would simply be caused by communication delays of your network. It's really not an issue caused on our side. |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
log files of magnolia |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
websphere logs after install/update/first login of magnolia 4.4.2 |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
Also when you installed the 4.4.2 war file as it is, it can't work since it points to Derby DB. You need to update it to use a "real" DB due to an issue between Derby and JackRabbit on WebSphere. If 4.4.1 works for you without any changes related to DB, then it's another two cents to the fact that the issue is caused by your network deployment, which is not supported by Magnolia. |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
Sorry, but this is all I can do for you here since it was verified that Magnolia CMS 4.4.2 runs on WAS 6.1. Thus I'm closing this ticket. |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
Hi, I am evaluating this cms product for a big customer, if i am not sure that it works fine with websphere 6.1 network deployment i really can not introduce it. can you tell me which changes i have to make in the 4.4.2 release (derby DB stuff pointing to real DB)? |
| Comment by Jan Haderka [ 04/Apr/11 ] |
|
Dear Kristof, If you need extended help, please contact our sales personnel at evaluation at magnolia dash cms dot com and sign up for official evaluation. Once you do that you will be allowed access to the support and we will try to help you to configure everything to get it working properly. Regards, |
| Comment by kristof vereecke [ 04/Apr/11 ] |
|
ok, but the comment " caused by your network deployment, which is not supported by Magnolia." is quitte important. Is this an official comment ? btw: request for official evaluation has been sent |
| Comment by Zdenek Skodik [ 04/Apr/11 ] |
|
See a list of certified stack here. The Websphere network deployment is not currently on the officially supported stack because no customer requested the certification. Should you require support for that, it can be certified by Magnolia, but the certification process incurs a fee. Certification means that we will install Magnolia on it and perform complete test against this system. Once certified we will also maintain such installation up-to-date and re-test every new release on it as long as the Websphere network release is actively developed. If you are interested in sponsoring official certification, please request a quote for certification fee from your sales/evaluation contact. |
| Comment by Jan Haderka [ 10/Oct/11 ] |
|
Actually this issue exists. Just saw it for myself on Win7 w/ 32bit jvm on Tomcat. Doesn't seem to be App server specific, but rather OS or JVM specific. |
| Comment by Zdenek Skodik [ 10/Oct/11 ] |
|
Not really, I've never run into the issue. For me it doesn't appear to be OS or application server specific indeed, maybe java-1.5.x & 4.4.x release combination can be involved, with some specific setup since this works for me as well. Could you upload your instance and provide me with your JVM version? |
| Comment by Zdenek Skodik [ 24/Oct/11 ] |
|
I had a chance to get in touch with several PCs (Windows XP), all of them had exactly the same HW&SW settings (provided by an admin), except for the JVM - one instance with a sort of MS JVM support and other with various Sun's JDKs (1.6.x). This issue was reproduceable on the first PC, but not on the others and moving out of the MS JVM fixed this class loading. |
| Comment by Daniel Lipp [ 02/Jul/14 ] |
|
Fixing as outdated as it was only reported for 4.4.x which is no longer supported. Don't hesitate to reopen or create a new ticket in case you'll experience it again on 4.5.x. I can't imaging the 5 series being based on Vaadin could be affected at all. |