[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: Text File dirlist.txt     Zip Archive magnolia-webspherelogs.zip     Zip Archive magnolia.zip     JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg     JPEG File screenshot-3.jpg     JPEG File screenshot-4.jpg    
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.
restarted and went to the main page to update. all this is ok.

when reaching the url:
http://localhost:9082/magnoliaAuthor/ i see the login page.
logging in with superuser/superuser i get the following popup:

"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 ?
Is there any special configuration needed for the classloader in websphere ?

Comment by Zdenek Skodik [ 04/Apr/11 ]

I use magnoliaAuthor as context root. This is correct ?

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.

Is there any special configuration needed for the classloader in websphere ?

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
i installed release 4.4.1: and now it works just fine.

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 . Can you tell me exactly which log file you need ? magnolia log files / websphere log files ?

Comment by Zdenek Skodik [ 04/Apr/11 ]

I would expect related records still written into your logs' history, but if you prefer retrying (by the way would you mind to try to update your 4.4.1 to 4.4.2?)
SystemOut(*).log should be enough (please extract from it just the messages in question). List of jars you have in the webapp would be also welcomed.

Comment by kristof vereecke [ 04/Apr/11 ]

just reinstalled 4.4.2 with following results

screenshot attached with some warning after magnolia update
screenshot added with problem after logging in
log files will be attached in a moment

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.
If you're an enterprise client, please open a support issue.

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,
as Zdenek pointed out above, we do not think the issue you are facing is with Magnolia, but rather with your configuration as we are not able to reproduce it in-house.

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,
Jan

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.
When the problem occurs it is visible in all browsers (Chrome, FF, IE).
Did you ever figured out what was causing it?

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.

Generated at Mon Feb 12 03:50:18 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.