Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. It seems so far that most are in agreement with this. I tried to do this briefly tonight, but apparently my Maven foo isn't high enough. If anyone wants to try it out, feel free. You can see a diff of what I tried at [1]. I tried several variations, but I think I have a core problem with the approach. Basically, I figured that I could make the wicket module a pom-only project that listed a dependency on -core. Later, a dependency on -html could exist if that were created. -core brings with it -util and -request. Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. They kept looking for wicket.jar, even though I wasn't building a jar. I tried several variations of making it a pom-only project, but perhaps this approach won't work at all. I haven't ever tried this sort of thing before with Maven. Feel free to give me a tip, or a working patch :) [1] - http://mysticpaste.com/view/4881/text (trying out Lombardi's paste tool you need a unified diff colorizer :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. you need to change the dependency type to 'pom' I'll check it later. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. It seems so far that most are in agreement with this. I tried to do this briefly tonight, but apparently my Maven foo isn't high enough. If anyone wants to try it out, feel free. You can see a diff of what I tried at [1]. I tried several variations, but I think I have a core problem with the approach. Basically, I figured that I could make the wicket module a pom-only project that listed a dependency on -core. Later, a dependency on -html could exist if that were created. -core brings with it -util and -request. Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. They kept looking for wicket.jar, even though I wasn't building a jar. I tried several variations of making it a pom-only project, but perhaps this approach won't work at all. I haven't ever tried this sort of thing before with Maven. Feel free to give me a tip, or a working patch :) [1] - http://mysticpaste.com/view/4881/text (trying out Lombardi's paste tool you need a unified diff colorizer :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
[x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. On Tue, Jan 25, 2011 at 9:27 AM, Guillaume Smet guillaume.s...@gmail.comwrote: Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. Guillaume, read the previous mails about the reason to depend on o.a.w:wicket:pom. Actually this kind of dependency is also recommended in Sonatype's Maven book - aggregation over inheritance. They have plans to make improvements in that area in Maven 3.1. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. I have it working here. Commit is coming. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? On Tue, Jan 25, 2011 at 7:17 AM, Martin Grigorov mgrigo...@apache.org wrote: [x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. On Tue, Jan 25, 2011 at 9:27 AM, Guillaume Smet guillaume.s...@gmail.comwrote: Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. Guillaume, read the previous mails about the reason to depend on o.a.w:wicket:pom. Actually this kind of dependency is also recommended in Sonatype's Maven book - aggregation over inheritance. They have plans to make improvements in that area in Maven 3.1. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. I have it working here. Commit is coming. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. signature.asc Description: OpenPGP digital signature
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max.
convertToString must override
Hello all,
just have set up a wicket dev environment and the wicket-util project
throwed one error.
convertToString must override
Works with deleting it - not sure if this was the intention :-)
Best
Christian
Index:
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
===
---
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(revision
1063222)
+++
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(working
copy)
@@ -46,7 +46,7 @@
* @see
org.apache.wicket.util.convert.converter.AbstractNumberConverter#convertToString(java.lang.Object,
* java.util.Locale)
*/
- @Override
+ // @Override
public String convertToString(final Integer value, final Locale locale)
{
String result = super.convertToString(value, locale);
Strange writeObjectMethodCache in SerializableChecker
Hi all,
At Topicus, we maintain a customized SerializableChecker with some additional
checks. I was trying to fix some generics-warnings and noticed a strange thing
about the writeObjectMethodCache. This variable is used in only 4 places, one
is a clear, one a get and 2 are puts. Both puts take a Boolean as value, but
the get checks if the value returned is a Method, which obviously can never
happen. I think the 'writeObjectMethod' should be put into the map after line
473:
writeObjectMethod = cls.getDeclaredMethod(writeObject,
new Class[] { java.io.ObjectOutputStream.class });
Best regards,
Emond
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: with the new split we have introduced iprovider interface which decouples the mess. a good example is that if now some part of request processing needs a configurable option it gets it via iprovider which in turn gets it from an application setting. this allows us to unit test that part of code without requiring the application to be set up and thus without requiring wicket tester. It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO.
Re: convertToString must override
On Tue, Jan 25, 2011 at 1:29 PM, Christian Grobmeier grobme...@gmail.comwrote:
Hello all,
just have set up a wicket dev environment and the wicket-util project
throwed one error.
convertToString must override
Works with deleting it - not sure if this was the intention :-)
Best
Christian
Index:
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
===
---
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(revision
1063222)
+++
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(working
copy)
@@ -46,7 +46,7 @@
* @see
org.apache.wicket.util.convert.converter.AbstractNumberConverter#convertToString(java.lang.Object,
* java.util.Locale)
*/
- @Override
+ // @Override
public String convertToString(final Integer value, final Locale
locale)
{
String result = super.convertToString(value, locale);
Which JDK do you use ?
With jdk1.5.0_22 this compiles without any problems.
convertToString() comes
from org.apache.wicket.util.convert.IConverter.convertToString(C, Locale)
which is interface and @Override is not allowed (in 1.6 it is allowed) in
the direct child.
ZeroPaddingIntegerConverter is not direct, it overrides
AbstractIntegerConverter, which overrides AbstractNumberConverter and using
@Override is ok.
Re: Strange writeObjectMethodCache in SerializableChecker
File a ticket + patch ;-)
What else do you have in this custom SerializableChecker ? Maybe it is
something that other users may benefit from and it can be included in the
standard SerializableChecker and you'll not have to maintain it.
On Tue, Jan 25, 2011 at 2:06 PM, Emond Papegaaij emond.papega...@topicus.nl
wrote:
Hi all,
At Topicus, we maintain a customized SerializableChecker with some
additional
checks. I was trying to fix some generics-warnings and noticed a strange
thing
about the writeObjectMethodCache. This variable is used in only 4 places,
one
is a clear, one a get and 2 are puts. Both puts take a Boolean as value,
but
the get checks if the value returned is a Method, which obviously can never
happen. I think the 'writeObjectMethod' should be put into the map after
line
473:
writeObjectMethod = cls.getDeclaredMethod(writeObject,
new Class[] { java.io.ObjectOutputStream.class });
Best regards,
Emond
Re: convertToString must override
Change your compiler compliance level?
On Tue, Jan 25, 2011 at 1:29 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Hello all,
just have set up a wicket dev environment and the wicket-util project
throwed one error.
convertToString must override
Works with deleting it - not sure if this was the intention :-)
Best
Christian
Index:
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
===
---
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(revision
1063222)
+++
src/main/java/org/apache/wicket/util/convert/converter/ZeroPaddingIntegerConverter.java
(working
copy)
@@ -46,7 +46,7 @@
* @see
org.apache.wicket.util.convert.converter.AbstractNumberConverter#convertToString(java.lang.Object,
* java.util.Locale)
*/
- @Override
+ // @Override
public String convertToString(final Integer value, final Locale locale)
{
String result = super.convertToString(value, locale);
Re: convertToString must override
Weird. I checked what you said and my JVM is complaining about overriding Number with Integer. Its Mac build SE-1.5 (OSX 10.6.6) Which JDK do you use ? With jdk1.5.0_22 this compiles without any problems. convertToString() comes from org.apache.wicket.util.convert.IConverter.convertToString(C, Locale) which is interface and @Override is not allowed (in 1.6 it is allowed) in the direct child. ZeroPaddingIntegerConverter is not direct, it overrides AbstractIntegerConverter, which overrides AbstractNumberConverter and using @Override is ok.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Spring distribution hasn't the spring.jar anymore: https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote: When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. -- Pedro Henrique Oliveira dos Santos
Re: Strange writeObjectMethodCache in SerializableChecker
Done: https://issues.apache.org/jira/browse/WICKET-3383
We extended the checker with checks for entities and attached LDMs, to prevent
Hibernate sessions to leak through to the next request. I've also stripped the
object paths to the bare minimum, which improves performace quite a bit. For
large pages (with 1000s of objects in lists), the checker spends most of its
time creating strings in statements like 'String arrayPos = [ + i + ];'. I
don't think these changes are very usefull for other people.
Emond
On Tuesday 25 January 2011 14:17:06 Martin Grigorov wrote:
File a ticket + patch ;-)
What else do you have in this custom SerializableChecker ? Maybe it is
something that other users may benefit from and it can be included in the
standard SerializableChecker and you'll not have to maintain it.
On Tue, Jan 25, 2011 at 2:06 PM, Emond Papegaaij
emond.papega...@topicus.nl
wrote:
Hi all,
At Topicus, we maintain a customized SerializableChecker with some
additional
checks. I was trying to fix some generics-warnings and noticed a strange
thing
about the writeObjectMethodCache. This variable is used in only 4 places,
one
is a clear, one a get and 2 are puts. Both puts take a Boolean as value,
but
the get checks if the value returned is a Method, which obviously can
never happen. I think the 'writeObjectMethod' should be put into the map
after line
473:
writeObjectMethod = cls.getDeclaredMethod(writeObject,
new Class[] { java.io.ObjectOutputStream.class });
Best regards,
Emond
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Spring stopped distributing aggregate jar since version 3.0. We could consider to keep distributing aggregate jar for a certain number of future versions but in the end i think we should fully embrace modules organization. When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsherm...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Which is kinda sad, since I still find too many Ant (and variants) -based projects out there (which is even more sad). Spring is becoming increasingly more difficult for beginners. Even the old MVC tutorial (which were a very good step-by-step script) isn't available anywhere anymore. It doesn't really affect me, since I use maven whenever I have the option, and already know how to do all these, but Well, the good side is that, beginners will have to learn maven from the start (since is the only bearable option), and hopefully Ant will become a forgotten artifact from ancient times... :) Tetsuo On Tue, Jan 25, 2011 at 11:27 AM, Pedro Santos pedros...@gmail.com wrote: Spring distribution hasn't the spring.jar anymore: https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote: When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. -- Pedro Henrique Oliveira dos Santos
Annotation for classes which should not be serialized
Hi, Someone just asked in ##wicket something like: for some reason my entity is serialized. it is wrapped in LDM, but still something went wrong and instead just the entity id, the whole entity is serialized https://gist.github.com/795052 Here are suggest introducing an annotation which serves like JSR-305's @NotNill - @WicketDontSerialize. I.e. if an object which class is annotated with this marker is sent to SerializableChecker#check() then throw an exception with the nice path to the object saying this class may be Serializable but it shouldn't be serialized. This way hopefully the user will see when there is a leak reference which ties the object in the serialization. Writing this email I realize that we can make it even better by extending the checker to use pluggable sub-checkers: checker for implements Serializable, checker based on an annotation, based on a black/white list, or some other logic. This way the user app can pass a checker that disallows classes coming from third party libs (i.e. cannot be annotated). In DEV mode it can be replaced with no-op checker. What do you think ? martin-g
Re: Annotation for classes which should not be serialized
Currently the serializable checker is only triggered when an NotSerializableException was thrown. Means that @WicketDontSerialize annotated beams will not get detected only by changing the SerializableChecker. Perhaps an IObjectStreamFactory that return an ObjectInputStream doing the check? Would work, and user can plug by Objects.setObjectStreamFactory(new ObjectInputStreamThatChecksFor WicketDontSerializeAnnotation()); On Tue, Jan 25, 2011 at 1:31 PM, Martin Grigorov martin.grigo...@gmail.comwrote: Hi, Someone just asked in ##wicket something like: for some reason my entity is serialized. it is wrapped in LDM, but still something went wrong and instead just the entity id, the whole entity is serialized https://gist.github.com/795052 Here are suggest introducing an annotation which serves like JSR-305's @NotNill - @WicketDontSerialize. I.e. if an object which class is annotated with this marker is sent to SerializableChecker#check() then throw an exception with the nice path to the object saying this class may be Serializable but it shouldn't be serialized. This way hopefully the user will see when there is a leak reference which ties the object in the serialization. Writing this email I realize that we can make it even better by extending the checker to use pluggable sub-checkers: checker for implements Serializable, checker based on an annotation, based on a black/white list, or some other logic. This way the user app can pass a checker that disallows classes coming from third party libs (i.e. cannot be annotated). In DEV mode it can be replaced with no-op checker. What do you think ? martin-g -- Pedro Henrique Oliveira dos Santos
Re: Annotation for classes which should not be serialized
On Tue, Jan 25, 2011 at 4:31 PM, Martin Grigorov martin.grigo...@gmail.comwrote: Hi, Someone just asked in ##wicket something like: for some reason my entity is serialized. it is wrapped in LDM, but still something went wrong and instead just the entity id, the whole entity is serialized https://gist.github.com/795052 Here are suggest introducing an annotation which serves like JSR-305's @NotNill - @WicketDontSerialize. I.e. if an object which class is annotated with this marker is sent to SerializableChecker#check() then throw an exception with the nice path to the object saying this class may be Serializable but it shouldn't be serialized. This way hopefully the user will see when there is a leak reference which ties the object in the serialization. Writing this email I realize that we can make it even better by extending the checker to use pluggable sub-checkers: checker for implements Serializable, checker based on an annotation, based on a black/white list, or some other logic. This way the user app can pass a checker that disallows classes coming from third party libs (i.e. cannot be annotated). In DEV mode it can be replaced with no-op checker. Here I meant PRODUCTION mode. What do you think ? martin-g
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 7:06 AM, James Carman ja...@carmanconsulting.comwrote: It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO. The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
RC1 parameter name style guide
While going through RC1 wicket-util I noted that in the org.apache.wicket.util.upload package there are a number of places where the parameter names to methods and constructors are of the form pName (e.g., pSizeMax. pIn, pHeaders. pContentLength. etc.). I think that this is the first time I've seen this Java coding style used in Wicket (though, I could be wrong). Does the Wicket coding style guidelines cover parameter names? While not wanting to be labeled by Emerson (not Emberson) concerning consistency, sometimes there is some merit to it. Richard -- Quis custodiet ipsos custodes
Re: RC1 parameter name style guide
that code was taking out of apache commons upload afair. -igor On Tue, Jan 25, 2011 at 9:16 AM, richard emberson richard.ember...@gmail.com wrote: While going through RC1 wicket-util I noted that in the org.apache.wicket.util.upload package there are a number of places where the parameter names to methods and constructors are of the form pName (e.g., pSizeMax. pIn, pHeaders. pContentLength. etc.). I think that this is the first time I've seen this Java coding style used in Wicket (though, I could be wrong). Does the Wicket coding style guidelines cover parameter names? While not wanting to be labeled by Emerson (not Emberson) concerning consistency, sometimes there is some merit to it. Richard -- Quis custodiet ipsos custodes
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
yes, people can still make mistakes, but at least when they are fixed its easy to see all places affected. even currently it offers a lot of advantages. for example when working on request module you cannot mistaking add a dependency on Application or Component or somethign else core-specific because it is not in that module. if someone would move Application or Component mistakingly into that module i think it would be easily noticed. -igor On Tue, Jan 25, 2011 at 11:36 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: RC1 parameter name style guide
Sure blame us commons people :) On Jan 25, 2011 12:21 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: that code was taking out of apache commons upload afair. -igor On Tue, Jan 25, 2011 at 9:16 AM, richard emberson richard.ember...@gmail.com wrote: While going through RC1 wicket-util I noted that in the org.apache.wicket.util.upload package there are a number of places where the parameter names to methods and constructors are of the form pName (e.g., pSizeMax. pIn, pHeaders. pContentLength. etc.). I think that this is the first time I've seen this Java coding style used in Wicket (though, I could be wrong). Does the Wicket coding style guidelines cover parameter names? While not wanting to be labeled by Emerson (not Emberson) concerning consistency, sometimes there is some merit to it. Richard -- Quis custodiet ipsos custodes
