Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
See http://www.nabble.com/New-pom-structure-tf1870006.html I think Martijn tweaked it a bit after that, but he'd better explain that himself :) Btw, Frank made a nice search service for Wicket messages etc: http://woogle.billen.dk . Might make it easier to find stuff like this. Eelco On 7/26/06, Vincent Jenks [EMAIL PROTECTED] wrote: Also, I'm not able to build Wicket 1.2.1 w/ maven like I did w/ 1.2. In the top-level 'wicket' folder doing mvn install -Dmaven.test.skip=true gives me this: - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Try it again. Probably you were too fast for the sync to ibiblio to happen. The wicket-parent-1.2.1.pom file is now available on ibiblio. http://repo1.maven.org/maven2/wicket/ From now on, the maven repository is sync'd frequently with our repository so (final) releases will become available through maven much faster than previously. Martijn On 7/26/06, Vincent Jenks [EMAIL PROTECTED] wrote: Also, I'm not able to build Wicket 1.2.1 w/ maven like I did w/ 1.2. In the top-level 'wicket' folder doing mvn install -Dmaven.test.skip=true gives me this: [INFO] Scanning for projects... Downloading: http://maven.sateh.com/repository/wicket/wicket-parent/1.2.1/wicket -parent-1.2.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: wicket ArtifactId: wicket-parent Version: 1.2.1 Reason: Unable to download the artifact from any repository wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: wicket:wic ket-parent for project: null:wicket:jar:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent : wicket:wicket-parent for project: null:wicket:jar:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'wicket:wicket -parent' not found in repository: Unable to download the artifact from any repos itory wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1157) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:467) ... 18 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl oad the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def aultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:124) ... 20 more [INFO] [INFO] Total time: 1 second [INFO]
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
In your application's init method, call getDebugSettings.setSerializeSessionAttributes(false); Eelco On 7/26/06, Vincent Jenks [EMAIL PROTECTED] wrote: I just downloaded 1.2.1, how do I take advantage of this? I'm hoping I can use 1.2.1 on Glassfish w/o having to custom-build it like I did w/ 1.2. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I'd guess you need to checkout wicket-parent (http://svn.sourceforge.net/viewcvs.py/wicket/branches/WICKET_1_2/wicket-parent) and do a mvn install in there first. /Gwyn On 26/07/06, Vincent Jenks [EMAIL PROTECTED] wrote: Also, I'm not able to build Wicket 1.2.1 w/ maven like I did w/ 1.2. In the top-level 'wicket' folder doing mvn install -Dmaven.test.skip=true gives me this: [INFO] Scanning for projects... Downloading: http://maven.sateh.com/repository/wicket/wicket-parent/1.2.1/wicket -parent-1.2.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: wicket ArtifactId: wicket-parent Version: 1.2.1 Reason: Unable to download the artifact from any repository wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I just downloaded 1.2.1, how do I take advantage of this? I'm hoping I can use 1.2.1 on Glassfish w/o having to custom-build it like I did w/ 1.2. Thanks! On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: just added this, it will be in 1.2.1 action type=update dev=Igor VaynbergAdded IDebugSettings.serializeSessionAttributes instead of relying on logger set to debug mode for the session store/action -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: Beautiful, it all built and it works in the app. Thanks Igor! On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: mvn install -Dmaven.test.skip=true -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, that definitely helped...but Results : Tests run: 410, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Mon Jul 10 13:48:34 MDT 2006 [INFO] Final Memory: 7M/35M [INFO] On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: looks like their repo servers are overloaded -- too popular for their own good try this: http://www.nabble.com/new-maven-repo-available-with-snapshots-tf1851211.html#a5054042 -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: No such luck - that didn't work any better. when doing 'mvn install' in the top-level WICKET_1_2 directory I get this error: Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container- default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.codehaus.plexus:plexus-container-default Reason: Error getting POM for ' org.codehaus.plexus:plexus-container-default' fro m the repository: Error transferring file org.codehaus.plexus:plexus-container-default:pom:1.0-alpha-8 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository ), snapshots ( http://snapshots.maven.codehaus.org/maven2) So, just for the sake of completeness I cd'd into the lower 'wicket' directory and ran 'mvn install' and got this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.2 from the specified remote repositories: central ( http://repo1.maven.org/maven2 ) Caused by I/O exception: Server returned HTTP response code: 503 for URL: http:/ /repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.2/maven -surefire-plugin-2.2.jar.sha1 Sounds like it might be better in concept than Ant but you run the risk of not being able to download dependencies - not sure I like the idea of relying on an internet connection for them. Anyhow...no closer than I was before. Any ideas? On 7/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: thats what i understood from martijn. the problem is that there is a parent pom file that all other projects inherit from, so that means that parent pom has to be installed in the maven repo in order for other projects to find it when you try to build so what i would do is cd WICKET_1_2 mvn install (possibly optional if you have the whole thing checked out) cd wicket mvn install and you should be good to go -Igor On 7/7/06, V. Jenks [EMAIL PROTECTED] wrote: So, if I check out all projects at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Also, I'm not able to build Wicket 1.2.1 w/ maven like I did w/ 1.2. In the top-level 'wicket' folder doing mvn install -Dmaven.test.skip=true gives me this: [INFO] Scanning for projects... Downloading: http://maven.sateh.com/repository/wicket/wicket-parent/1.2.1/wicket -parent-1.2.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: wicket ArtifactId: wicket-parent Version: 1.2.1 Reason: Unable to download the artifact from any repository wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: wicket:wic ket-parent for project: null:wicket:jar:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent : wicket:wicket-parent for project: null:wicket:jar:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'wicket:wicket -parent' not found in repository: Unable to download the artifact from any repos itory wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1157) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository wicket:wicket-parent:pom:1.2.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:467) ... 18 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl oad the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def aultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:124) ... 20 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Jul 26 10:47:57 MDT 2006 [INFO] Final Memory: 1M/2M [INFO] On 7/26/06, Vincent Jenks [EMAIL PROTECTED] wrote: I just downloaded 1.2.1, how do I take advantage of this? I'm hoping I can use 1.2.1 on Glassfish w/o having to custom-build it like I did w/ 1.2. Thanks! On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: just added this, it will be in 1.2.1 action type=update dev=Igor VaynbergAdded
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
OK, that definitely helped...but Results : Tests run: 410, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Mon Jul 10 13:48:34 MDT 2006 [INFO] Final Memory: 7M/35M [INFO] On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: looks like their repo servers are overloaded -- too popular for their own good try this: http://www.nabble.com/new-maven-repo-available-with-snapshots-tf1851211.html#a5054042 -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: No such luck - that didn't work any better. when doing 'mvn install' in the top-level WICKET_1_2 directory I get this error: Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container- default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.codehaus.plexus:plexus-container-default Reason: Error getting POM for 'org.codehaus.plexus:plexus-container-default' fro m the repository: Error transferring file org.codehaus.plexus:plexus-container-default:pom:1.0-alpha-8 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository ), snapshots (http://snapshots.maven.codehaus.org/maven2) So, just for the sake of completeness I cd'd into the lower 'wicket' directory and ran 'mvn install' and got this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2 ) Caused by I/O exception: Server returned HTTP response code: 503 for URL: http:/ /repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.2/maven -surefire-plugin-2.2.jar.sha1 Sounds like it might be better in concept than Ant but you run the risk of not being able to download dependencies - not sure I like the idea of relying on an internet connection for them. Anyhow...no closer than I was before. Any ideas? On 7/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: thats what i understood from martijn. the problem is that there is a parent pom file that all other projects inherit from, so that means that parent pom has to be installed in the maven repo in order for other projects to find it when you try to build so what i would do is cd WICKET_1_2 mvn install (possibly optional if you have the whole thing checked out) cd wicket mvn install and you should be good to go -Igor On 7/7/06, V. Jenks [EMAIL PROTECTED] wrote: So, if I check out all projects at https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/ https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/wicket I should be able to build them w/ maven, as you described before? Igor Vaynberg wrote: svn co https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/wicket will give you the 1.2 release maven doesnt work out of the box because of the new build thing martijn is trying where you need to have a parent pom installed first so its a more tedious process unless you check out the entire folder that contains all the projects. -Igor On 7/7/06, *Vincent Jenks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ha! It ran w/o the exception! It would have been nice to get around the logging another way but I guess I'll take what I can get at this point. My last concern is - is 1.2.1.rc1 fit for production - because this site is *already* in production and I'm hesitant to throw a relatively unstable version of wicket into it. Could someone help me figure out how to build the 1.2 final branch w/o errors? Thanks! On 7/7/06, Vincent Jenks [EMAIL PROTECTED] mailto:[EMAIL
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Beautiful, it all built and it works in the app. Thanks Igor! On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: mvn install -Dmaven.test.skip=true -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, that definitely helped...but Results : Tests run: 410, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Mon Jul 10 13:48:34 MDT 2006 [INFO] Final Memory: 7M/35M [INFO] On 7/10/06, Igor Vaynberg [EMAIL PROTECTED] wrote: looks like their repo servers are overloaded -- too popular for their own good try this: http://www.nabble.com/new-maven-repo-available-with-snapshots-tf1851211.html#a5054042 -Igor On 7/10/06, Vincent Jenks [EMAIL PROTECTED] wrote: No such luck - that didn't work any better. when doing 'mvn install' in the top-level WICKET_1_2 directory I get this error: Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container- default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.codehaus.plexus:plexus-container-default Reason: Error getting POM for 'org.codehaus.plexus:plexus-container-default' fro m the repository: Error transferring file org.codehaus.plexus:plexus-container-default:pom:1.0-alpha-8 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository ), snapshots (http://snapshots.maven.codehaus.org/maven2) So, just for the sake of completeness I cd'd into the lower 'wicket' directory and ran 'mvn install' and got this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2 ) Caused by I/O exception: Server returned HTTP response code: 503 for URL: http:/ /repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.2/maven -surefire-plugin-2.2.jar.sha1 Sounds like it might be better in concept than Ant but you run the risk of not being able to download dependencies - not sure I like the idea of relying on an internet connection for them. Anyhow...no closer than I was before. Any ideas? On 7/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: thats what i understood from martijn. the problem is that there is a parent pom file that all other projects inherit from, so that means that parent pom has to be installed in the maven repo in order for other projects to find it when you try to build so what i would do is cd WICKET_1_2 mvn install (possibly optional if you have the whole thing checked out) cd wicket mvn install and you should be good to go -Igor On 7/7/06, V. Jenks [EMAIL PROTECTED] wrote: So, if I check out all projects at https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/ https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/wicket I should be able to build them w/ maven, as you described before? Igor Vaynberg wrote: svn co https://svn.sourceforge.net/svnroot/wicket/tags/WICKET_1_2/wicket will give you the 1.2 release maven doesnt work out of the box because of the new build thing martijn is trying where you need to have a parent pom installed first so its a more tedious process unless you check out the entire folder that contains all the projects. -Igor On 7/7/06, *Vincent Jenks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ha! It ran w/o the exception! It would
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Then you probably don't have done the steps to setup ant... ant
requires you to install the junit jar into the ant/lib folder iirc.
It's been a while since I've setup ant to work like this...
Martijn
On 7/7/06, V. Jenks [EMAIL PROTECTED] wrote:
I did steps 1-5...it immediately fails because there is no build
file...so I went back up to the root where the build.xml file was and
ran 'ant jar'...I eventually get this:
BUILD FAILED
/home/vjenks/Projects/java/wicket-1.2.1-rc1/build.xml:85: Could not
create task or type of type: junit.
Ant could not find the task or a class this task relies upon.
Martijn Dashorst wrote:
Instead of building from SVN, you might download the distribution
(1.2.1-rc1 is the newest), and use ant to build the jar.
the distribution contains all dependencies you need, and contains a
build.xml for ant lovers.
There is no need to learn yet another tool if you don't want to.
So the steps:
1. download wicket-1.2.1-rc1-bin.zip
2. unzip
3. cd into directory
4. do your changes in the src/java folder
5. start 'ant jar'
6. find the jar in the target directory (without version number
unfortunately)
Martijn
On 7/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
the entire point of maven is that it downloads dependencies for you and
does
the rest of that crap so you dont have to :)
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I've heard of it but am not familiar...I'll look into it.
I was going to make a lib project in eclipse or netbeans and build it
that way but realized there's probably a pile of dependencies I don't
have...won't that be an issue even w/ maven?
All the lib folders only contain clover
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
naaah use maven2
make the change in the src folder
type mvn package and you will have a .jar ready in the target dir
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, checked it out and I made my changebut bare w/ me...I'm almost
completely unfamiliar w/ Ant and I figured that'd be the easiest way
to build it?
So, how do I build this sucker?
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, if it comes down to it just check out wicket, remove that
portion
of
code, and deploy it that way
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
At 8:30 this morning...it's now 2:30pm here and I was the *last*
person to post to this forum at all...which is weird...it's
normally
pretty busy.
http://forums.java.net/jive/thread.jspa?threadID=16673tstart=0
This is the first time I haven't gotten an answer to my problem on
the
same day...they're *almost* as good as you guys! :)
On 7/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Did you try asking around on the glassfish list/ IRC channel (if
they
have one)?
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because
it
is a
requirement for using Hibernate as the persistence engine. I
put
the
log4j.properties in there w/ the suggested entries and
restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get
the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish
doesn't
have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED]
wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p
-
%-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED]
wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED]
wrote:
That's where I put it - nothing changed so you're
obviously
right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I
have
no
idea how
to use a spring like proxy and am not at all familiar
w/
Springand in effect I'd have
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Again, I did this at home on my Gentoo box in a separate project...and got the same result. My log4j.properties: logger.wicket.protocol.http=INFO The exception stack: wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.zambizzi.finances.ui.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287) at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75) Caused by: java.io.NotSerializableException: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:56) ... 33 more If I make a reference to the SFSB and do *not* place it into Wicket's session state - there are no problems (but of course this is useless)... What else can I do? This is a real jam for me as my boss has expressed interest in replacing JBoss w/ Glassfish and the one EJB3 app we've written so far makes heavy use of a single SFSB. Thanks again! Igor Vaynberg wrote: i dont know, but if the stack trace is exactly the same then log4j still thinks debug level is enabled on that package. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: Alright, I stuck a log4j.properties into my src folder, rebuilt, redeployed - still get the same exception...here's my properties file (copied from wicket-examples):
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
My problem w/ that is; the application is done and I can't go back through and re-work it to get something working that already works on another container. This application runs well on JBoss's EJB3 implemenation w/o that kind of tweaking. However, going forward, JBoss probably isn't an option for us. I suppose I can post @ the Glassfish forums to see what they think. Meanwhile, how can I get debug logging disabled in order to eliminate that possibility? On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote: This discussion is completely about getting the debug logging disabled. But even if that is done. Then you still could have a problem because for example in 2.0 we store the pages to disk. this will fail then. It is much better for you to look why it is not serializeable or of you can wrap something around it like a serializeable proxy (just like our spring intergration) johan On 7/6/06, V. Jenks [EMAIL PROTECTED] wrote: Again, I did this at home on my Gentoo box in a separate project...and got the same result. My log4j.properties: logger.wicket.protocol.http=INFO The exception stack: wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.zambizzi.finances.ui.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update (Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked (ProcessorTask.java:574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java :287) at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run (WorkerThread.java:75) Caused by: java.io.NotSerializableException: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject (ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java :574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287) at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run (WorkerThread.java:75) Caused by: java.io.NotSerializableException:
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
On Thursday, 06 July 2006 09:16 am, Vincent Jenks escreveu: My problem w/ that is; the application is done and I can't go back through and re-work it to get something working that already works on another container. This application runs well on JBoss's EJB3 implemenation w/o that kind of tweaking. However, going forward, JBoss probably isn't an option for us. I suppose I can post @ the Glassfish forums to see what they think. Meanwhile, how can I get debug logging disabled in order to eliminate that possibility? I don't know if this will help, but you might try something like this: Logger logger = Logger.getLogger( org.springframework ); logger.setLevel( Level.ERROR ); but replace org.springframework with your class's FQN. Do this in your Application. Then you might be able to see that with this manually set to error you do or don't get this issue. Then you can at least be assured of that. Or... you can print out the logging level. Once you know for sure what level it is getting set to, you can then investigate further. If it's not getting set to the level you want to, you might have to set some breakpoints in the log4j code. On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote: This discussion is completely about getting the debug logging disabled. But even if that is done. Then you still could have a problem because for example in 2.0 we store the pages to disk. this will fail then. It is much better for you to look why it is not serializeable or of you can wrap something around it like a serializeable proxy (just like our spring intergration) johan On 7/6/06, V. Jenks [EMAIL PROTECTED] wrote: Again, I did this at home on my Gentoo box in a separate project...and got the same result. My log4j.properties: logger.wicket.protocol.http=INFO The exception stack: wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.zambizzi.finances.ui.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java: 62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update (Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService(Applicatio nFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java: 566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:53 6) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCont extValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve .java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java: 566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java: 566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline .java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j ava:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:53 6) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(Proc essorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked (ProcessorTask.java:574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorT ask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(Re
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later. This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
OK, I've created a small test-app in Netbeans where I'm using a Wicket page and have overridden ISessionFactory in the app class to create a session. I have a page where I call the stateful bean, create it and store it in session if it's non-existent, and supply a link to clear the bean from session. When first calling the page - when the stub is first stored in session, the page fails. If I re-visit the page the values have actually been stored...amazingly enough...and the page does not fail but displays the values in session. I can click the link, clear it, and start the whole process over again and it is consistent. So that begs the question - would I be safe supressing the exception in the custom session class where I'm storing the bean stub? Or, is it possible that I'm not getting the correct reference to the bean due to the serialization failure? If someone wants a copy of my little test app - I'd be happy to send it along. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later. This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
that it just works is logical. It is just a test we try to serialize it sothat you get a warning if that is not possible because of a non serializeable object.On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, I've created a small test-app in Netbeans where I'm using a Wicketpage and have overridden ISessionFactory in the app class to create asession.I have a page where I call the stateful bean, create it andstore it in session if it's non-existent, and supply a link to clear the bean from session.When first calling the page - when the stub is first stored insession, the page fails.If I re-visit the page the values haveactually been stored...amazingly enough...and the page does not fail but displays the values in session.I can click the link, clear it,and start the whole process over again and it is consistent.So that begs the question - would I be safe supressing the exceptionin the custom session class where I'm storing the bean stub?Or, is it possible that I'm not getting the correct reference to the bean dueto the serialization failure?If someone wants a copy of my little test app - I'd be happy to send it along.On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later.This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session.Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach (RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService ( ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Excellent, I'll move forward then and see how it goes...thanks! On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote: that it just works is logical. It is just a test we try to serialize it so that you get a warning if that is not possible because of a non serializeable object. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, I've created a small test-app in Netbeans where I'm using a Wicket page and have overridden ISessionFactory in the app class to create a session. I have a page where I call the stateful bean, create it and store it in session if it's non-existent, and supply a link to clear the bean from session. When first calling the page - when the stub is first stored in session, the page fails. If I re-visit the page the values have actually been stored...amazingly enough...and the page does not fail but displays the values in session. I can click the link, clear it, and start the whole process over again and it is consistent. So that begs the question - would I be safe supressing the exception in the custom session class where I'm storing the bean stub? Or, is it possible that I'm not getting the correct reference to the bean due to the serialization failure? If someone wants a copy of my little test app - I'd be happy to send it along. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later. This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach (RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
For whatever reason, I'm unable to supress this exception in the storefront application (where I really need it.) I've tried wrapping a try/catch around the assignment and retrieval of the SFSB stub in the custom Session class...I can't pull the bean data up w/o the exception occuring, it would seem. So again, is there a way to turn logging debugging off so the test doesn't happen at all...so I can quit trying to find work-arounds? Even if my error supression did work, it's not a very elegant solution - it might be better if the serialization wasn't being tested at all. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Excellent, I'll move forward then and see how it goes...thanks! On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote: that it just works is logical. It is just a test we try to serialize it so that you get a warning if that is not possible because of a non serializeable object. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, I've created a small test-app in Netbeans where I'm using a Wicket page and have overridden ISessionFactory in the app class to create a session. I have a page where I call the stateful bean, create it and store it in session if it's non-existent, and supply a link to clear the bean from session. When first calling the page - when the stub is first stored in session, the page fails. If I re-visit the page the values have actually been stored...amazingly enough...and the page does not fail but displays the values in session. I can click the link, clear it, and start the whole process over again and it is consistent. So that begs the question - would I be safe supressing the exception in the custom session class where I'm storing the bean stub? Or, is it possible that I'm not getting the correct reference to the bean due to the serialization failure? If someone wants a copy of my little test app - I'd be happy to send it along. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later. This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class:
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
That's where I put it - nothing changed so you're obviously right...it won't make a difference anyways. Hmm...this is bad...this puts me in a rough spot as I have no idea how to use a spring like proxy and am not at all familiar w/ Springand in effect I'd have no idea how to do this in Wicket or what it would involve. It's obviously going to involve me reworking a bunch of my existing code just to move to another container...which shouldn't have been the case. On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote: you are doing it fine, you just have to find a location for log4j.properties where glassfish will pick it up. usually it is in war/web-inf/classes -Igor On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: For whatever reason, I'm unable to supress this exception in the storefront application (where I really need it.) I've tried wrapping a try/catch around the assignment and retrieval of the SFSB stub in the custom Session class...I can't pull the bean data up w/o the exception occuring, it would seem. So again, is there a way to turn logging debugging off so the test doesn't happen at all...so I can quit trying to find work-arounds? Even if my error supression did work, it's not a very elegant solution - it might be better if the serialization wasn't being tested at all. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Excellent, I'll move forward then and see how it goes...thanks! On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote: that it just works is logical. It is just a test we try to serialize it so that you get a warning if that is not possible because of a non serializeable object. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: OK, I've created a small test-app in Netbeans where I'm using a Wicket page and have overridden ISessionFactory in the app class to create a session. I have a page where I call the stateful bean, create it and store it in session if it's non-existent, and supply a link to clear the bean from session. When first calling the page - when the stub is first stored in session, the page fails. If I re-visit the page the values have actually been stored...amazingly enough...and the page does not fail but displays the values in session. I can click the link, clear it, and start the whole process over again and it is consistent. So that begs the question - would I be safe supressing the exception in the custom session class where I'm storing the bean stub? Or, is it possible that I'm not getting the correct reference to the bean due to the serialization failure? If someone wants a copy of my little test app - I'd be happy to send it along. On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote: Well, this was the first app I've ever built w/ EJB technology of *any* version...it's sort of a pilot app for future in-house effortsso far it's worked out great. So, correct me if I'm wrong but it's my understanding that if I do not store the stub to the interface of the stateful bean in an HTTP session - I may lose the reference to that bean the next time I call it. So, I'm calling the stateful bean and storing a reference to it in http session so I can recall that exact instance back from the server later. This is how it was done in the app that is currently running in production on JBoss. On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote: Anyway, I don't really understand, why is the ejb object actually being serialized. Do you store your service objects in session? -Matej Igor Vaynberg wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1075)
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
HTTP
session - I may lose the reference to that bean the next time
I
call
it.
So, I'm calling the stateful bean and storing a reference to
it in
http session so I can recall that exact instance back from the
server
later. This is how it was done in the app that is currently
running
in production on JBoss.
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Anyway, I don't really understand, why is the ejb object
actually
being
serialized. Do you store your service objects in session?
-Matej
Igor Vaynberg wrote:
well, the problem might be that it is serialized by wicket
itself.
this is done because you have the logger set to debug to
help
identify
things you put into session that might not be
serializable.
maybe
the
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
It must be in the wrong place somehow, if glassfish doesn't pick it
up. You should try to figure out how Glassfish works with commons
logging. Typically there is logging configuration for the whole
application server, and then for specific web applications. Not all
containers behave the same unfortunately (had to write a JBoss plugin
to let it pick up application specific logging for a project some two
years ago)
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
HTTP
session - I may lose the reference to that bean the next time
I
call
it.
So, I'm calling the stateful bean and storing a reference to
it in
http session so I can recall that exact instance back from the
server
later. This is how it was done in the app that is
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
HTTP
session - I may lose the reference to that bean the next time
I
call
it.
So, I'm calling the stateful bean and storing a reference to
it in
http session so I can recall that exact instance back from the
server
later. This is how it was done in the app that is currently
running
in production on JBoss.
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Anyway, I don't really understand, why is the ejb object
actually
being
serialized. Do you store your service objects in session?
-Matej
Igor Vaynberg wrote:
well,
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Wicket uses commons-logging. I wonder whether glassfish doesn't have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
HTTP
session - I may lose the reference to that bean the next time
I
call
it.
So, I'm calling the stateful bean and storing a reference to
it in
http session so I can recall that exact instance back from the
server
later. This is how it was done in the app that is currently
running
in production on JBoss.
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Anyway, I don't really understand, why is the ejb object
actually
being
serialized. Do you store your service objects in session?
-Matej
Igor Vaynberg wrote:
well, the problem might be that it is serialized by wicket
itself.
this is done because you have the logger set to debug to
help
identify
things you put into session that might not be
serializable.
maybe
the
container doesnt serialize the same way so when the
container
does
it
its not a problem, but when wicket does it it is a
problem.
-Igor
On 7/5/06, Vincent Jenks [EMAIL
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because it is a
requirement for using Hibernate as the persistence engine. I put the
log4j.properties in there w/ the suggested entries and restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish doesn't have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
HTTP
session - I may lose the reference to that bean the next time
I
call
it.
So, I'm calling the stateful bean and storing a reference to
it in
http session so I can recall that exact instance back from the
server
later. This is how it was done in the app that is
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Did you try asking around on the glassfish list/ IRC channel (if they have one)?
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because it is a
requirement for using Hibernate as the persistence engine. I put the
log4j.properties in there w/ the suggested entries and restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish doesn't have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant
solution
- it might be better if the serialization wasn't being tested at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not getting the correct reference to the
bean
due
to the serialization failure?
If someone wants a copy of my little test app - I'd be happy to
send
it
along.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Well, this was the first app I've ever built w/ EJB technology
of
*any* version...it's sort of a pilot app for future in-house
effortsso far it's worked out great.
So, correct me if I'm wrong but it's my understanding that if
I do
not
store the stub to the interface of the stateful bean in an
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
At 8:30 this morning...it's now 2:30pm here and I was the *last*
person to post to this forum at all...which is weird...it's normally
pretty busy.
http://forums.java.net/jive/thread.jspa?threadID=16673tstart=0
This is the first time I haven't gotten an answer to my problem on the
same day...they're *almost* as good as you guys! :)
On 7/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Did you try asking around on the glassfish list/ IRC channel (if they have
one)?
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because it is a
requirement for using Hibernate as the persistence engine. I put the
log4j.properties in there w/ the suggested entries and restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish doesn't have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} -
%m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously
right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no idea
how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in Wicket or
what it would involve. It's obviously going to involve me reworking
a
bunch of my existing code just to move to another container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in
war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in the
storefront application (where I really need it.) I've tried
wrapping
a try/catch around the assignment and retrieval of the SFSB stub in
the custom Session class...I can't pull the bean data up w/o the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the test
doesn't happen at all...so I can quit trying to find work-arounds?
Even if my error supression did work, it's not a very elegant
solution
- it might be better if the serialization wasn't being tested at
all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm using a
Wicket
page and have overridden ISessionFactory in the app class to
create
a
session. I have a page where I call the stateful bean, create
it
and
store it in session if it's non-existent, and supply a link to
clear
the bean from session.
When first calling the page - when the stub is first stored in
session, the page fails. If I re-visit the page the values have
actually been stored...amazingly enough...and the page does not
fail
but displays the values in session. I can click the link, clear
it,
and start the whole process over again and it is consistent.
So that begs the question - would I be safe supressing the
exception
in the custom session class where I'm storing the bean stub?
Or, is
it possible that I'm not
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
OK, checked it out and I made my changebut bare w/ me...I'm almost
completely unfamiliar w/ Ant and I figured that'd be the easiest way
to build it?
So, how do I build this sucker?
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, if it comes down to it just check out wicket, remove that portion of
code, and deploy it that way
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
At 8:30 this morning...it's now 2:30pm here and I was the *last*
person to post to this forum at all...which is weird...it's normally
pretty busy.
http://forums.java.net/jive/thread.jspa?threadID=16673tstart=0
This is the first time I haven't gotten an answer to my problem on the
same day...they're *almost* as good as you guys! :)
On 7/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Did you try asking around on the glassfish list/ IRC channel (if they
have one)?
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because it is a
requirement for using Hibernate as the persistence engine. I put the
log4j.properties in there w/ the suggested entries and restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish doesn't have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p -
%-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously
right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have no
idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in
Wicket or
what it would involve. It's obviously going to involve me
reworking a
bunch of my existing code just to move to another
container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location for
log4j.properties
where glassfish will pick it up. usually it is in
war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
For whatever reason, I'm unable to supress this exception in
the
storefront application (where I really need it.) I've tried
wrapping
a try/catch around the assignment and retrieval of the SFSB
stub in
the custom Session class...I can't pull the bean data up w/o
the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so the
test
doesn't happen at all...so I can quit trying to find
work-arounds?
Even if my error supression did work, it's not a very elegant
solution
- it might be better if the serialization wasn't being tested
at all.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Excellent, I'll move forward then and see how it
goes...thanks!
On 7/6/06, Johan Compagner [EMAIL PROTECTED] wrote:
that it just works is logical. It is just a test we try to
serialize
it so
that you get a warning if that is not possible because of a
non
serializeable object.
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, I've created a small test-app in Netbeans where I'm
using a
Wicket
page and have overridden ISessionFactory in the app class
to
create
a
session. I have a page where I call the stateful bean,
create
it
and
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I've heard of it but am not familiar...I'll look into it.
I was going to make a lib project in eclipse or netbeans and build it
that way but realized there's probably a pile of dependencies I don't
have...won't that be an issue even w/ maven?
All the lib folders only contain clover
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
naaah use maven2
make the change in the src folder
type mvn package and you will have a .jar ready in the target dir
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
OK, checked it out and I made my changebut bare w/ me...I'm almost
completely unfamiliar w/ Ant and I figured that'd be the easiest way
to build it?
So, how do I build this sucker?
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, if it comes down to it just check out wicket, remove that portion
of
code, and deploy it that way
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
At 8:30 this morning...it's now 2:30pm here and I was the *last*
person to post to this forum at all...which is weird...it's normally
pretty busy.
http://forums.java.net/jive/thread.jspa?threadID=16673tstart=0
This is the first time I haven't gotten an answer to my problem on the
same day...they're *almost* as good as you guys! :)
On 7/6/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Did you try asking around on the glassfish list/ IRC channel (if
they
have one)?
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I have no idea...but I'm lost at this point. I have both
commons-logging and log4j in the glassfish/lib folder because it
is a
requirement for using Hibernate as the persistence engine. I put
the
log4j.properties in there w/ the suggested entries and
restarted...the
error is the same - didn't work.
I tried deploying log4j in my war's /lib folder and packaging
log4j.properties in there...made no difference...I can't get the
exception message to change.
ugh :(
On 7/6/06, Matej Knopp [EMAIL PROTECTED] wrote:
Wicket uses commons-logging. I wonder whether glassfish doesn't
have
it's own weird logger factory, just like jetty does.
-Matej
Eelco Hillenius wrote:
In fact log4j.logger.wicket=INFO should be enough.
Eelco
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p -
%-26.26c{1} - %m\n
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
paste your complete log4j.properties file
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's where I put it - nothing changed so you're obviously
right...it
won't make a difference anyways.
Hmm...this is bad...this puts me in a rough spot as I have
no
idea how
to use a spring like proxy and am not at all familiar w/
Springand in effect I'd have no idea how to do this in
Wicket or
what it would involve. It's obviously going to involve me
reworking a
bunch of my existing code just to move to another
container...which
shouldn't have been the case.
On 7/6/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
you are doing it fine, you just have to find a location
for
log4j.properties
where glassfish will pick it up. usually it is in
war/web-inf/classes
-Igor
On 7/6/06, Vincent Jenks [EMAIL PROTECTED]
wrote:
For whatever reason, I'm unable to supress this exception
in
the
storefront application (where I really need it.) I've
tried
wrapping
a try/catch around the assignment and retrieval of the
SFSB
stub in
the custom Session class...I can't pull the bean data up
w/o
the
exception occuring, it would seem.
So again, is there a way to turn logging debugging off so
the
test
doesn't happen at all...so I can quit trying to find
work-arounds?
Even if my error supression did work, it's not a very
elegant
solution
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
On 06/07/06, Igor Vaynberg [EMAIL PROTECTED] wrote: so there are people out there not using log4j? :) I'm quite taken with Simple Log, myself! [https://simple-log.dev.java.net/] (It includes an CommonsLoggingAdapter for use with clogging.) /Gwyn Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Why would you want to make logging easy? :) If SUN had just adopted Log4J instead of IBM's kit like the whole world besides IBM asked them to do, we wouldn't have been in this mess. Eelco On 7/6/06, Gwyn Evans [EMAIL PROTECTED] wrote: On 06/07/06, Igor Vaynberg [EMAIL PROTECTED] wrote: so there are people out there not using log4j? :) I'm quite taken with Simple Log, myself! [https://simple-log.dev.java.net/] (It includes an CommonsLoggingAdapter for use with clogging.) /Gwyn Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Caused by: java.io.NotSerializableException:com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegateat java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
looks like a bug in sun's impl of ejbs?-IgorOn 7/5/06, Vincent Jenks [EMAIL PROTECTED]
wrote:I'm testing an app I just finished and is currently running on JBoss
on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's aviable option going forward w/ our enterprise efforts.I seem to be having an issue w/ storing objects in session.Wicketruns fine until I utilize the overridden ISessionFactory to store
objects - then I start getting exceptions like this:**StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servletProductCatalogApp threw exception
wicket.WicketRuntimeException: Internal error cloning object. Makesure all dependent objects implement Serializable. Class:com.myapp.ui.admin.UserSessionat wicket.protocol.http.HttpSessionStore.setAttribute
(HttpSessionStore.java:62)at wicket.Session.setAttribute(Session.java:914)at wicket.Session.update(Session.java:938)at wicket.protocol.http.WebSession.update(WebSession.java:116)at
wicket.RequestCycle.detach(RequestCycle.java:818)at wicket.RequestCycle.steps(RequestCycle.java:1052)at wicket.RequestCycle.request(RequestCycle.java:453)at wicket.protocol.http.WicketServlet.doGet
(WicketServlet.java:215)at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)at org.apache.catalina.core.ApplicationFilterChain.servletService
(ApplicationFilterChain.java:397)at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:179)at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:182)at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)at org.apache.catalina.core.StandardPipeline.doInvoke
(StandardPipeline.java:566)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)at org.apache.coyote.tomcat5.CoyoteAdapter.service
(CoyoteAdapter.java:231)at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java
:574)at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)at
com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)at com.sun.enterprise.web.connector.grizzly.WorkerThread.run
(WorkerThread.java:75)Caused by: java.io.NotSerializableException:com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegateat java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)at java.io.ObjectOutputStream.writeOrdinaryObject
(ObjectOutputStream.java:1284)at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)at java.io.ObjectOutputStream.writeSerialData
(ObjectOutputStream.java:1341)at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:291)at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:56)... 33 more**
The ProductCatalogApp (my wicket application class) looks like this:public class ProductCatalogApp extends WebApplication{public void init(){//create external images resource
getSharedResources().add(imageResource, new ImageResource());//start timer servicesTimerProxy.init();}public Class getHomePage()
{return ProductCatalog.class;}public ISessionFactory getSessionFactory(){return new ISessionFactory(){public Session
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java :574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287) at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run (WorkerThread.java:75) Caused by: java.io.NotSerializableException: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject (ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java :574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287) at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run (WorkerThread.java:75) Caused by: java.io.NotSerializableException: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
That's kind of what I was thinking...and afraid of myself - that Glassfish isn't playing nicely w/ Wicket when attempting to serialize - otherwise the error doesn't make much sense. I'm building a little test-app to demonstrate right now. If this is the case, what can be done to work around it, if anything? On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java :574) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
the stuff in session is only serialized because you have the logger set to debug, if you turn that off it should be fine. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: That's kind of what I was thinking...and afraid of myself - that Glassfish isn't playing nicely w/ Wicket when attempting to serialize - otherwise the error doesn't make much sense. I'm building a little test-app to demonstrate right now. If this is the case, what can be done to work around it, if anything? On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:231) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
I'm not entirely sure what you meant by having the logger set to debug...but I'll assume that you meant I was missing this from web.xml?... init-param param-nameconfiguration/param-name param-valueDEPLOYMENT/param-value /init-param I added it, rebuilt, redeployed, same exception when using a SFSB. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: the stuff in session is only serialized because you have the logger set to debug, if you turn that off it should be fine. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: That's kind of what I was thinking...and afraid of myself - that Glassfish isn't playing nicely w/ Wicket when attempting to serialize - otherwise the error doesn't make much sense. I'm building a little test-app to demonstrate right now. If this is the case, what can be done to work around it, if anything? On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:179) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:182) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
well, serialization error happens here: at wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:62) if you go there you will see: // Do some extra profiling/ debugging. This can be a great help // just for testing whether your webbapp will behave when using // session replication if (log.isDebugEnabled()) so if the logger.wicket.protocol.http is not set to DEBUG level in log4j config that code wont run as it is there mainly to help you find serialization errors, but in this case its hitting a spot that shouldnt usually be a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm not entirely sure what you meant by having the logger set to debug...but I'll assume that you meant I was missing this from web.xml?... init-param param-nameconfiguration/param-name param-valueDEPLOYMENT/param-value /init-param I added it, rebuilt, redeployed, same exception when using a SFSB. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: the stuff in session is only serialized because you have the logger set to debug, if you turn that off it should be fine. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: That's kind of what I was thinking...and afraid of myself - that Glassfish isn't playing nicely w/ Wicket when attempting to serialize - otherwise the error doesn't make much sense. I'm building a little test-app to demonstrate right now. If this is the case, what can be done to work around it, if anything? On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: well, the problem might be that it is serialized by wicket itself. this is done because you have the logger set to debug to help identify things you put into session that might not be serializable. maybe the container doesnt serialize the same way so when the container does it its not a problem, but when wicket does it it is a problem. -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I don't know, I would believe that if I weren't able to make a Stateful bean and use it exactly how I did in Wicket, outside of this project. I setup a test project and their stateful/stateless beans work flawlessly when tested against JSP/Servletsthe problem arises w/ Wicket + SFSB on Glassfish. On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote: Caused by: java.io.NotSerializableExcepti on: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) looks like a bug in sun's impl of ejbs? -Igor On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote: I'm testing an app I just finished and is currently running on JBoss on Sun's Glassfish (SJAS 9.0) to test compatibility and see if it's a viable option going forward w/ our enterprise efforts. I seem to be having an issue w/ storing objects in session. Wicket runs fine until I utilize the overridden ISessionFactory to store objects - then I start getting exceptions like this: ** StandardWrapperValve[ProductCatalogApp]: Servlet.service() for servlet ProductCatalogApp threw exception wicket.WicketRuntimeException: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.myapp.ui.admin.UserSession at wicket.protocol.http.HttpSessionStore.setAttribute (HttpSessionStore.java:62) at wicket.Session.setAttribute(Session.java:914) at wicket.Session.update(Session.java:938) at wicket.protocol.http.WebSession.update(WebSession.java:116) at wicket.RequestCycle.detach(RequestCycle.java:818) at wicket.RequestCycle.steps(RequestCycle.java:1052) at wicket.RequestCycle.request(RequestCycle.java:453) at wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:397) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240) at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
Alright, I stuck a log4j.properties into my src folder, rebuilt,
redeployed - still get the same exception...here's my properties file
(copied from wicket-examples):
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
What am I doing wrong?
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, serialization error happens here:
at
wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:62)
if you go there you will see:
// Do some extra profiling/ debugging. This can be a great help
// just for testing whether your webbapp will behave when using
// session replication
if (log.isDebugEnabled())
so if the logger.wicket.protocol.http is not set to DEBUG level in
log4j config that code wont run as it is there mainly to help you find
serialization errors, but in this case its hitting a spot that
shouldnt usually be a problem.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I'm not entirely sure what you meant by having the logger set to
debug...but I'll assume that you meant I was missing this from
web.xml?...
init-param
param-nameconfiguration/param-name
param-valueDEPLOYMENT/param-value
/init-param
I added it, rebuilt, redeployed, same exception when using a SFSB.
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
the stuff in session is only serialized because you have the logger
set to debug, if you turn that off it should be fine.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's kind of what I was thinking...and afraid of myself - that
Glassfish isn't playing nicely w/ Wicket when attempting to serialize
- otherwise the error doesn't make much sense.
I'm building a little test-app to demonstrate right now.
If this is the case, what can be done to work around it, if anything?
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, the problem might be that it is serialized by wicket itself.
this is done because you have the logger set to debug to help identify
things you put into session that might not be serializable. maybe the
container doesnt serialize the same way so when the container does it
its not a problem, but when wicket does it it is a problem.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I don't know, I would believe that if I weren't able to make a
Stateful bean and use it exactly how I did in Wicket, outside of
this
project.
I setup a test project and their stateful/stateless beans work
flawlessly when tested against JSP/Servletsthe problem arises w/
Wicket + SFSB on Glassfish.
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
Caused by: java.io.NotSerializableExcepti
on:
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
looks like a bug in sun's impl of ejbs?
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I'm testing an app I just finished and is currently running on
JBoss
on Sun's Glassfish (SJAS 9.0) to test compatibility and see if
it's a
viable option going forward w/ our enterprise efforts.
I seem to be having an issue w/ storing objects in session.
Wicket
runs fine until I utilize the overridden ISessionFactory to store
objects - then I start getting exceptions like this:
**
StandardWrapperValve[ProductCatalogApp]: Servlet.service()
for servlet
ProductCatalogApp threw exception
wicket.WicketRuntimeException: Internal error cloning object. Make
sure all dependent objects implement Serializable. Class:
com.myapp.ui.admin.UserSession
at
wicket.protocol.http.HttpSessionStore.setAttribute
(HttpSessionStore.java:62)
at wicket.Session.setAttribute(Session.java:914)
at wicket.Session.update(Session.java:938)
at
wicket.protocol.http.WebSession.update(WebSession.java:116)
at wicket.RequestCycle.detach(RequestCycle.java:818)
at
Re: [Wicket-user] Testing Wicket 1.2 on Glassfish b48
i dont know, but if the stack trace is exactly the same then log4j
still thinks debug level is enabled on that package.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
Alright, I stuck a log4j.properties into my src folder, rebuilt,
redeployed - still get the same exception...here's my properties file
(copied from wicket-examples):
log4j.debug=false
log4j.rootLogger=INFO
log4j.logger.org=INFO
log4j.logger.com=INFO
log4j.logger.net=INFO
log4j.logger.nl=INFO
log4j.logger.wicket=INFO
log4j.logger.wicket.protocol.http.HttpSessionStore=INFO
log4j.logger.org.apache.catalina.cluster=INFO
log4j.logger.wicket.version=INFO
log4j.logger.wicket.RequestCycle=INFO
logger.wicket.protocol.http=INFO
log4j.appender.Stdout=org.apache.log4j.ConsoleAppender
log4j.appender.Stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %m\n
What am I doing wrong?
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, serialization error happens here:
at
wicket.protocol.http.HttpSessionStore.setAttribute(HttpSessionStore.java:62)
if you go there you will see:
// Do some extra profiling/ debugging. This can be a great help
// just for testing whether your webbapp will behave when using
// session replication
if (log.isDebugEnabled())
so if the logger.wicket.protocol.http is not set to DEBUG level in
log4j config that code wont run as it is there mainly to help you find
serialization errors, but in this case its hitting a spot that
shouldnt usually be a problem.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I'm not entirely sure what you meant by having the logger set to
debug...but I'll assume that you meant I was missing this from
web.xml?...
init-param
param-nameconfiguration/param-name
param-valueDEPLOYMENT/param-value
/init-param
I added it, rebuilt, redeployed, same exception when using a SFSB.
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
the stuff in session is only serialized because you have the logger
set to debug, if you turn that off it should be fine.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
That's kind of what I was thinking...and afraid of myself - that
Glassfish isn't playing nicely w/ Wicket when attempting to serialize
- otherwise the error doesn't make much sense.
I'm building a little test-app to demonstrate right now.
If this is the case, what can be done to work around it, if anything?
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
well, the problem might be that it is serialized by wicket itself.
this is done because you have the logger set to debug to help
identify
things you put into session that might not be serializable. maybe
the
container doesnt serialize the same way so when the container does
it
its not a problem, but when wicket does it it is a problem.
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I don't know, I would believe that if I weren't able to make a
Stateful bean and use it exactly how I did in Wicket, outside of
this
project.
I setup a test project and their stateful/stateless beans work
flawlessly when tested against JSP/Servletsthe problem arises
w/
Wicket + SFSB on Glassfish.
On 7/5/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
Caused by: java.io.NotSerializableExcepti
on:
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
looks like a bug in sun's impl of ejbs?
-Igor
On 7/5/06, Vincent Jenks [EMAIL PROTECTED] wrote:
I'm testing an app I just finished and is currently running on
JBoss
on Sun's Glassfish (SJAS 9.0) to test compatibility and see if
it's a
viable option going forward w/ our enterprise efforts.
I seem to be having an issue w/ storing objects in session.
Wicket
runs fine until I utilize the overridden ISessionFactory to
store
objects - then I start getting exceptions like this:
**
StandardWrapperValve[ProductCatalogApp]: Servlet.service()
for servlet
ProductCatalogApp threw exception
wicket.WicketRuntimeException: Internal error cloning object.
Make
sure all dependent objects implement Serializable. Class:
com.myapp.ui.admin.UserSession
at
wicket.protocol.http.HttpSessionStore.setAttribute
