[QA of JBoss Portal] - Unit test framework
by julien＠jboss.com
I have imported in the SVN the initial source tree for the unit test framework.
The status is that it is usable but missing:
- more meta tests (i.e the tests that test the framework)
- an integration with Ant and Maven
- an integration with JUnit XML reporter
But I decided to import it in order to be helped on the previous items (and possibly others).
The module is imported in the trunk test module https://svn.jboss.org/repos/portal/modules/test under the "unit" name and use the package org.jboss.unit
It uses Java 5, so in order to use it with the current build, one need to edit the file local.properties that the build creates and add
| javac.source=1.5
| javac.target=1.5
|
The test of the framework are based on java (since the framework does not test itself) and it can be triggered using the "test" target.
The unit module is not built yet by the full build because the rest of the module still uses 1.4. It could uses Java 5 but would produce Java 5 jars for their next snapshot version and we have not yet started to migrate the modules snapshot to Java 5.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090058#4090058
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090058
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Need Notification when message is dropped due to max siz
by timfox
"jhowell(a)redhat.com" wrote : I have a customer that wants to put in an aspect to do some sort of notification if a message is dropped due to the maxsize. I can see in ChannelSupport that the max size is handed via
|
| protected Delivery handleInternal(DeliveryObserver sender, MessageReference ref,
| | Transaction tx, boolean persist)
| | {
| | if (ref == null)
| | {
| | return null;
| | }
| |
| | if (trace) { log.trace(this + " handles " + ref + (tx == null ? " non-transactionally" : " in transaction: " + tx)); }
| | if (maxSize != -1 && getMessageCount() >= maxSize)
| | {
| | //Have reached maximum size - will drop message
| | log.warn(this + " has reached maximum size, " + ref + " will be dropped");
| | return null;
| | }
| |
| and the Delivery gets returned as null. I don't see anything that I can use to figure out if the message is dropped.
|
| I do see later on that if the delivery is null that we generate a JMSException in ServerConnectionEndpoint this....
|
| if (del == null)
| | {
| | throw new JMSException("Failed to route " + ref + " to " + dest.getName());
| | }
| |
|
| My guess is that theres nothing that they can do except catch the exception. Because we throw a JMSException and not a MessagingJMSException, it makes it hard. Should we throw a typed exception, like MaxMessageReachedException or throw a MessagingJMSException with a specific error code in it. I notice that there are several cases that can return a null delivery. I would recommend that we throw a specific exception in ChannelSupport? That way we could write an aspect that would catch the specific exception. Don't know what the impact would be, but I'm guessing that there is a reason that we return null for the delivery in ChannelSupport.
One thing the user could do is catch the JMSException in his interceptor, then enquire on the queue how many messages are in it.
If number of messages in queue == maxSize, then you know queue is full.
For JBM 2.0 we can think about adding more fine grained return values / exceptions. If you like, you could add a feature request for that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090035#4090035
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090035
17 years, 2 months
[Design of JBossCache] - Removing classloader issues for PojoCache
by bstansberry＠jboss.com
Jason,
Would like to explore with you the possibility of eliminating the need for region-based marshalling with PojoCache.
We use region-based marshalling to handle replication of custom types. But, since PojoCache breaks down pojos into primitives, most of the need for replicating custom types is eliminated. AIUI, the remaining areas where custom types are replicated are:
1) The Class of the pojo, so the remote node knows what type to construct.
2) Any @Serializable field.
Could those cases be handled by storing some MarshalledValue variant in the cache (or perhaps just a String for the pojo Class)? Assume here a much more suitable MarshalledValue; i.e. it holds onto the wrapped object for local use; doesn't serialize until needed rather than at construction, etc. I plan to write one of those anyway.
I'm asking because besides FIELD repl all the other AS web session and SFSB usages of JBC handle things such that they don't need region-based marshalling. I'd like to have the ability to handle all these usages in one cache. If I could eliminate region-based marshalling as a config factor, that would simplify things.
Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4089966#4089966
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4089966
17 years, 2 months
[Design of JBoss Portal] - Re: Maven Migration Status
by anders3
pom file http://anonsvn.jboss.org/repos/portal/modules/pom.xml
discovery
This file contains
xml module=common/trunk/common
problems
This gives some problems. Consider you make a release then you would need to change the <module..> to common/release/yyyy-mm-dd/common
Further more it gives the root-pom problem Thomas writes about.
Suggestion
I belive it would be better to make a svn directory i.e.
/repos/portal/modules/trunks/pom.xml
and in the trunks directory you should use svn external link to link common to common/trunk.
and add an external for each module
inside the root pom.xml the module ... would be consistent
module common /module independent of your releases.
result
1) A release would be a copy of trunks/pom.xml to i.e. releases/yyyy-mm-dd/pom.xml
including changing the external list to common = common/release/xxx and so on.
2) the root pom would work nicely with mvn idea:idea .. mvn eclipse:eclipse (that I belive the current solution does not)
improvement
It seems you work with a two layer pom structure. It could be a good idea to make three layers root.pom --> module.pom --> artifact.poms
Doing this works good with svn externals
/Anders
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4089888#4089888
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4089888
17 years, 2 months
[Design of JBossCache] - Re: JBCACHE-1154 - Introduce ability to mark nodes as reside
by genman
"mircea.markus" wrote : anonymous wrote : and reduces node memory size (no need to add new boolean variables) - an boolean is hold on a bit. An RegularEnumSet aggregates an long (64 bit) + some caching arrays (other bits as well). From a memory POV it is optimal to aggregate booleans directly (than EnumSets wrapping enums).
|
| anonymous wrote : Reduces future changes of the Node interface (no need to add methods for a new feature) - code would be less readable; also I don't think this is an proper enum usage: i.e. define bounded types(the boolean variables are not logically related) -> enhance readability
I still don't know why my concept hasn't caught on.
I saw your latest patches, which add flags to the data map. Then, you wrote a bunch of code to clean up the data as seen by the client. Sure, the external interface is clean but:
1. The internal code looks like crap. I don't know why you didn't opt for a boolean flag like everything else, but so be it.
2. You added new methods to an interface that's potentially designed for clients to implement. Or, is this interface supposed to get 2 new methods every point release? Adrian Brock "yelled" at me for doing something like this on a fairly obscure internal interface, and I don't and didn't work for JBoss. Hasn't he knocked a few times wondering what's going on?
3. You add methods to a general interface that are specific to a non-general concern.
The point is, sure you can have "boolean get/set" methods. But why not add to the interface instead:
| void setProperty(Property p);
| boolean getProperty(Property p);
|
The properties themselves could be an enum or Object with an ordinal (so users could register their own). You could conceivably implement the internals as an integer or series of booleans or EnumSet, or what have you. Then, when a bug fix or something arises in the future, you minimize change scope.
I just get the sense things are going to continue to degenerate until maybe 3.0 when you guys get a clue and fix the APIs again.
The main point was never to "aggregate booleans", it would just have been a nice side-effect. Saving memory is certainly nice, but next time I won't bring it up since it seems to just confuse people.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4089852#4089852
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4089852
17 years, 2 months