Advice about test implementation

Hi,

I am trying to expose several plain Java interfaces as web services, using
CXF / java2ws / wsdl2java.

My original plan was to...

(1)    use java2ws generate WSDL and XSD files from the existing POJO
classes

(2)    use wsdl2java to generate new Java sources containing JAX-WS and
JAX-B annotations

(3)    implement web services using these generated files

However, I found that there are many types missing from the generated XSD
files, because they are not included in the JAX-B mapping.
http://java.sun.com/javaee/5/docs/tut.../bnazq.html#bnazw

So I adjusted my plan...

(1)    use java2ws generate WSDL and XSD files from the existing POJO
classes

(2)    modify the generated XSD files by hand, to include XML
representations of the unsupported Java types

(3)    write a JAX-B binding extensions XML file, so that wsdl2java would
know how to handle the additional types

(4)    use wsdl2java to generate new Java sources containing JAX-WS and
JAX-B annotations

(5)    implement web services using these generated files

However, now I hear that the JAX-B mapping does not (yet) support any
representation of java.util.Map, which is one of the types in my original
POJO files.
http://stackoverflow.com/questions/18...o-a-java-util-map

So please tell me:

-          is there any way I can do this, which involves modifying the
output of java2ws, or extending the capabilities of java2ws and wsdl2java?

-          or... must I add JAX-B annotations to the original Java files?
is there any tool that might speed up this painstaking work?

-          or... can you suggest an alternative approach?

Thanks & Regards,
Paul

I see that the <info> and <dependency> elements have a "branch"
attribute, and I can see that it sorta-kinda

works the way I would naively expect... if I publish an artifact with
branch set to "foo" and then try to resolve

with a dependency of the same name, but with the branch set to "bar"
then it doesn't match and the resolve

fails.  So far, so good.  But my real question is how to best take
advantage of this? 

 

If I just change the branch and publish, winding up with different
revisions with different branches commingle together, things

don't seem to work so smoothly.  Is the idea that we are to make
"branch" part of the repository pattern, so that

artifacts are segregated on a per branch basis? Or something else?  

 

Any and all advice or pointers to documentation are much appreciated.

 

 

Thanks,

 

Phil

Hy guy's.

My model:
Users has
  Bookmarks and Posts

have idea keep Bookmarks and Posts in separate DB (for speed views).
But in view i want fetch Bookmarks and Posts with user name,

In what way i can do this?
keep copy of users in each DB?

or may be keep users in separate DB, fetch bookmarks or posts and then
fetch users and then merge?

Yes i know i can copy user name to doc, but have a trouble when user
name is changed (it's force me use stale=ok in request view
+background process to track changes and run rebuild index).

I think it's will be cool crazy stuff if i can update docs(cached
fields - not have effect to index) and say Couch you don't need
rebuild index relax ;).

Any advice?

I'm starting to get concerned about the 4MB document limit.
I'm building a social network app and so far I've stuffed everything
into one collection.
Logically, there is nothing wrong with this because each document is
just a combination
of data and caches for a single user.  The bulk of the data is a
cache. I could certainly
break the caches into a separate collections.

My app integrates with FaceBook and I see some FB members with
thousands of
friends.  For a hypothetical 100 friends my app seems to store about
85k of data.
Interpolating from that it looks like 4 M will handle users with a max
of 4500 friends.

Is there someway to tell precisely how many bytes (of the possible
4MB)
that a document is using?  I based my estimates off of ASCII dumps but
I would
like to do more in-depth analysis.

We have an existing product sitting on the hbase/hadoop ecosystem. We have
laid our object model on HBase: we have one table with a row per object,
and a separate table with composite index rows. Works great. We can
efficiently find our objects based on their type, relationships, etc. by
scanning the index table. We *never* scan the main table (except when
rebuilding the index).

 

A new requirement just came in: get a list of all objects that have been
modified since <timestamp>. This has to happen "quickly" (user
time).

 

If we scan the main table with a timestamp restriction, will that be
efficient? Or do we have to introduce a new composite index that has the
last modified timestamp as part of it and scan that? 

 

Thanks,

Mark

 

Hi,

I'm new to riak, and have been busily reading though the wiki, watching
the
videos, and catching up on the mail list, so I will have lots of questions
over the next few weeks - so sorry <grin>

To begin, I'm curious about the characteristics of the seven backends for
riak [1]

   1. riak_kv_bitcask_backend - stores data to bitcask
   2. riak_kv_fs_backend - stores data directly to files in a nested
   directory structure on disk
   3. riak_kv_ets_backend - stores data in ETS tables (which makes it
   volatile storage, but great for debugging)
   4. riak_kv_dets_backend - stores data on-disk in DETS tables
   5. riak_kv_gb_trees_backend - stores data using Erlang gb_trees
   6. riak_kv_cache_backend - turns a bucket into a memcached-type memory
   cache, and ejects the least recently used objects either when the cache
   becomes full or the object's lease expires
   7. riak_kv_multi_backend - configure per-bucket backends

Unfortunately this amount of choice means I need to do my homework to make
an informed decision ;-) so I'd love any pointers or to hear any advice on
performance comparisons, best practices, backends for development vs
deployment etc

Kind Regards

Neville

[1]
http://wiki.basho.com/display/RIAK/Ho...ingsWork-Backends

I want to build a vBulletin type application (forums, threads, posts, user
management, etc).
Support multi-tenancy for a Saas type environment.

Would Cassandra be suitable for this type of application?



Thanks in advance.

I have 3 collections:  Products, Ratings, and Users

Ratings is essentially a M:N join between gifts and users.  I'm having
users go through the list of products in a random order, and rate
them.  To do this, I'm running the following commands

scope :unrated_by, lambda {|user_id, limit|
	# First, get a list of all of the products a user has already rated.
	ids_to_exclude = Rating.only(:rateable_id).where(:user_id =>
user_id).collect{|r| r.rateable_id}

	# I want to put the user in at a random point in the database to
start rating products,
	# to ensure that all products will have roughly the same number of
ratings.  Understanding the
	# formula below isn't critical to understanding my problem.
	total_idea_pool = GiftIdea.where(:sales_rank.lt => 1200).count -
ids_to_exclude.size - limit
	skip = total_idea_pool > 0 ? rand(total_idea_pool) : 0

	# now load the products
	GiftIdea:where => {:sales_rank.lt => 1200}.not_in(:_id =>
ids_to_exclude).skip(skip).limit(limit)
}

Near as I can tell, I have 2 problems with this code:

1. GiftIdea.where(:sales_rank.lt => 1200).count seems to be slow.
I've been caching it.
2. Some users have rated 3000 products.  So making 1 call to gather
that list, and then another to send it in as a filter, has got to be
getting slow too.

Is there a better way to do this using the ruby driver directly?

The test in question (test_parse_line) was nondeterministic because it
was relying on the sort order of a Hash whose keys were symbols.  When
the sort order caused a blank line to appear at the end of the file
under test, the blank line was elided by the crontab parser, causing a
failure.

Modified the test to execute in a deterministic order that doesn't
place the blank line at the end.

Signed-off-by: Paul Berry <pau### @puppetlabs.com>
---
 test/ral/providers/cron/crontab.rb |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/test/ral/providers/cron/crontab.rb
b/test/ral/providers/cron/crontab.rb
index 0c87a5b..be2af1e 100755
--- a/test/ral/providers/cron/crontab.rb
+++ b/test/ral/providers/cron/crontab.rb
@@ -97,7 +97,10 @@ class TestCronParsedProvider < Test::Unit::TestCase
     # Then do them all at once.
     records = []
     text = ""
-    sample_records.each do |name, options|
+    # Sort sample_records so that the :empty entry does not come last
+    # (if it does, the test will fail because the empty last line will
+    # be ignored)
+    sample_records.sort { |a, b| a.first.to_s <=> b.first.to_s
}.each do |name, options|
       records << options[:record]
       text += options[:text] + "\n"
     end

On 22 July 2010 21:15,  <mben### @apache.org> wrote:
 Author: mbenson
 Date: Thu Jul 22 20:15:25 2010
 New Revision: 966839

 URL: http://svn.apache.org/viewvc?rev=966839&view=rev
 Log:
 add new test module to exercise the defaultProxyFactory

 Added:
    commons/proper/proxy/branches/version-2.0-work/test/   (with
props)
    commons/proper/proxy/branches/version-2.0-work/test/pom.xml

Needs svn:eol-style native

    commons/proper/proxy/branches/version-2.0-work/test/src/
    commons/proper/proxy/branches/version-2.0-work/test/src/main/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/main/java/
    commons/proper/proxy/branches/version-2.0-work/test/src/test/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/org/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/org/apache/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/org/apache/commons/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/org/apache/commons/proxy/
  
 commons/proper/proxy/branches/version-2.0-work/test/src/test/java/org/apache/commons/proxy/DefaultProxyFactoryTest.java

Needs svn:eol-style native

 Modified:
    commons/proper/proxy/branches/version-2.0-work/pom.xml

 Modified: commons/proper/proxy/branches/version-2.0-work/pom.xml
 URL:
http://svn.apache.org/viewvc/commons/...839&view=diff
 

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Kiran Ayyagari closed DIRSERVER-1480.

Author: markt
Date: Wed Jun  2 11:45:11 2010
New Revision: 950507

URL: http://svn.apache.org/viewvc?rev=950507&view=rev
Log:
Fix Eclipse warnings in the o.a.c.tribes.test package

Modified:
   
tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestDataIntegrity.java
   
tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestMulticastPackages.java
   
tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestRemoteProcessException.java
   
tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestUdpPackages.java
   
tomcat/trunk/test/org/apache/catalina/tribes/test/io/TestSenderConnections.java
   
tomcat/trunk/test/org/apache/catalina/tribes/test/io/TestSerialization.java

Modified:
tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestDataIntegrity.java
URL:
http://svn.apache.org/viewvc/tomcat/t...507&view=diff

Add test cases for dependency injection for java 1.0 features into the
testsuite.

Hi Michelle,

should these changes go into the api subproject (instead of api2)?
I think having them in api2 does not hurt, so there is no need to 
rollback the checkin. But we need them in api, since api defines the JDO 
3 API classes and interfaces.

Regards Michael


 Author: mcaisse
 Date: Sun Jun 20 02:54:01 2010
 New Revision: 956317

 URL: http://svn.apache.org/viewvc?rev=956317&view=rev
 Log:
 JDO-557 - Tests for api's invocation of getPersistenceManager(Map)
and getPersistenceManager(Map, Map). Also fixed an issue in
JDOConfigTestClassLoader.java.


 Added:
     db/jdo/trunk/api2/test/java/javax/jdo/PMFMapMapTest.java
     db/jdo/trunk/api2/test/java/javax/jdo/PMFProxy.java
     db/jdo/trunk/api2/test/java/javax/jdo/PMFService.java
     db/jdo/trunk/api2/test/schema/jdoconfig/Pmfmapmap01/
     db/jdo/trunk/api2/test/schema/jdoconfig/Pmfmapmap01/META-INF/
    
db/jdo/trunk/api2/test/schema/jdoconfig/Pmfmapmap01/META-INF/jdoconfig.xml
     db/jdo/trunk/api2/test/schema/jdoconfig/Pmfmapmap02/
    
db/jdo/trunk/api2/test/schema/jdoconfig/Pmfmapmap02/propsfile.props
 Modified:
     db/jdo/trunk/api2/   (props changed)
    
db/jdo/trunk/api2/test/java/javax/jdo/JDOConfigTestClassLoader.java

 Propchange: db/jdo/trunk/api2/
 

I wonder why the very clear thing like "zero test failures" always ends up
with test architecture discussion. :-)






On Thu, May 27, 2010 at 5:22 AM, Nathan Beyer <ndbe### @apache.org>
wrote:

 On Wed, May 26, 2010 at 4:59 AM, Mark Hindess
 <mark.hi### @googlemail.com> wrote:
 >
 > In message
<201005250742.### @d06av01.portsmouth.uk.ibm.com>,
 > Mark Hindess writes:
 >>
 >> In message <
 AANLkTikh3nV56QB8HXSXfzLnI9jrtU-C2cRF1s### @mail.gmail.com>,
 >> Nathan Beyer writes:
 >> >
 >> > For future milestone votes, I'd like to propose that we
set the
 >> > expectation of zero test failures. Every time we do a
milestone and I
 >> > run the build and tests I find myself looking at the
test failures
 >> > (there are ALWAYS failures) and ask 'are these
expected'? If the
 >> > failures are expected, they should be excluded and the
tests should
 >> > just pass.
 >> >
 >> > If this proposal is workable, immediately after this
upcoming release,
 >> > all 'expected' failures will be pulled into the
exclusion lists.
 >>
 >> I was thinking this too.  The problem for me is that:
 >>
 >> 1) Our test coverage isn't brilliant so we need a way to
exclude
 >> individual tests not the tests for a whole class.  We have
too many
 >> excluded tests already[0].
 >>
 >> 2) The JDWP test framework seems to pass most of the time on
the 5.0
 >> code base but seems to fail quite often on the 6.0 branch. 
I normally
 >> resort to doing 10 test runs and comparing the results of
all runs. I
 >> typically see every test pass on at least one run.  This
leads me to
 >> believe that the improved jdwp in the 6.0 branch is merely
exposing race
 >> conditions in the test framework.  It would be great to fix
the test
 >> framework so that these are avoided.  If we tried to exclude
tests that
 >> fail regularly on java6 jdwp we would probably end up
removing most of
 >> the tests. ;-(
 >>
 >> I think solving 1 is really a pre-requisite to moving
forward with your
 >> (excellent) goal.  We should make that a priority after this
release.  I
 >> don't care if the solution is something fancy with junit 4
annotations
 >> or something simple like adding:
 >>
 >>   if (Support_Excludes.isExcluded()) {
 >>     return;
 >>   }
 >>
 >> to problematic tests where the support class just looks up
the
 >> class/method name of the caller in the exclude lists.  (I
actually
 >> quite like the idea of doing the exclude list processing
lazily at
 >> run time rather than generating the list with ant.)
 >
 > Last night I decided to try to implement this simple exclude
list
 > mechanism in my build-improvement branch.  I've checked in my
changes at
 >

https://svn.apache.org/repos/asf/harm...anches/mr### @948377

 I don't want to be rude, but ... I brought this up a few months back
 and the response I got was less than overwhelming. I stopped my work.
 How is this different?


http://harmony.markmail.org/message/4...=junit annotation

 >
 > I've automatically added isExcluded() checks to all the test
methods
 > in previously excluded tests (though this was automated and more
 > complicated than you might think, and definitely not 100%
accurate
 > but should be close enough).  The next job would be to
remove/move
 > the isExcluded() checks to be as fine-grained as possible so as
just
 > to exclude the failing tests (or individual asserts).  As I
commented
 > previously many of the excludes probably just need to be removed
 > completely.
 >
 > New excludes can be added as before by adding tests names to the
lists
 > but you also need to add an appropriate isExcluded()-if check to
the
 > test code as well.  Hopefully this will maximize coverage will
still
 > allowing us to have only passing tests running by default.
 >
 > If different exclude conditions apply to different platforms you
can
 > use:
 >
 >  package.class#methodname
 >  package.class+arbitrary_tag
 >  package.class#methodname+arbitrary_tag
 >  arbitrary_tag
 >
 > to exclude tests - though I'd avoid the final one unless it is
something
 > really broad like a VM not supporting concurrent (like the IBM
v4 VMEs).
 >
 > To see what is happening, you can run the tests with:
 >
 >  -Dhy.test.vmargs=-Dhy.excludes.verbose=true
 >
 > (though this is too verbose I might make the load method less
verbose
 > or use a hy.excludes.debug=true flag for that output).
 >
 > To ignore excludes and run all tests use:
 >
 >  -Dhy.test.vmargs=-Dhy.excludes.ignore=true
 >
 > Rather than using test-jre-vm-info in ant the vm name for the
exclude
 > file selection is a trivial guess based on system properties. If
you
 > are using a custom vm and exclude lists then you can use:
 >
 >  -Dhy.test.vmargs=-Dhy.excludes.vm=myvm
 >
 > to set it explicitly.
 >
 > I'm tempted to do away with the isExcluded() checks/lists are
replace
 > them with more readable:
 >
 >  if (Support_Excludes.isRI()) {
 >
 > or:
 >
 >  if (Support_Excludes.isLinux() &&
Support_Excludes.is64bit()) {
 >
 > etc.  To make the Excludes more self-contained but that requires
 > looking at the excluded tests in more detail to understand the
 > requirements better and as I said I wanted to make this a simple
 > step from what we had today.
 >
 > I'd like to merge this to trunk/java6 after the code freeze but
I'd
 > like some feedback first.  I don't necessarily see this as a
final
 > solution but I just wanted to do something since this topic has
been
 > discussed for far to long and I wanted something that we could
move to
 > from where we are today without to much effort.  On the other
hand,
 > I'm not convinced that annotations are a good solution either
since
 > they don't give you fine-grained control so every distinction
has to be
 > represented by a separate method.
 >
 > Comments very welcome.
 >
 > Regards,
 >  Mark.
 >
 >
 >

    [
https://issues.apache.org/jira/browse...2#action_12905782
] 

Myrna van Lunteren commented on DERBY-4463:

Hi All, 

I've got a class whose behavior changes based on a boolean property. This
property is read in the static block of the class. Is there a way to write
test JUnit testcase that can verify the behavior of the class for both the
values of this property? If I specify the value in build.xml, I can test
my
code for only one value of the property. 

How can I test on multiple value of a property ? 

 Thanks 
~Shailja 

https://issues.apache.org/jira/browse/BUILDR-468

Hi All,

I had posted this message as a comment for ZOOKEEPER-822. I thought it
might
be a good idea to give a wider attention so that it will be easier to
collect feedback.

I found few problems in the FLE implementation while debugging for:
https://issues.apache.org/jira/browse/ZOOKEEPER-822. Following the email
below might require some background. If necessary, please browse the JIRA.
I
have a patch for 1. a) and 2). I will send them out soon.

1. Blocking connects and accepts:

a) The first problem is in manager.toSend(). This invokes connectOne(),
which does a blocking connect. While testing, I changed the code so that
connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run()
does a socketChannel.connect(). After starting AsyncConnect, connectOne
starts a timer. connectOne continues with normal operations if the
connection is established before the timer expires, otherwise, when the
timer expires it interrupts AsyncConnect() thread and returns. In this way,
I can have an upper bound on the amount of time we need to wait for connect
to succeed. Of course, this was a quick fix for my testing. Ideally, we
should use Selector to do non-blocking connects/accepts. I am planning to
do
that later once we at least have a quick fix for the problem and consensus
from others for the real fix (this problem is big blocker for us). Note
that
it is OK to do blocking IO in SenderWorker and RecvWorker threads since
they
block IO to the respective peer.

b) The blocking IO problem is not just restricted to connectOne(), but also
in receiveConnection(). The Listener thread calls receiveConnection() for
each incoming connection request. receiveConnection does blocking IO to get
peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the
peer that had sent the connection request. All of this is happening from
the
Listener. In short, if a peer fails after initiating a connection, the
Listener thread won't be able to accept connections from other peers,
because it would be stuck in read() or connetOne(). Also the code has an
inherent cycle. initiateConnection() and receiveConnection() will have to
be
very carefully synchronized otherwise, we could run into deadlocks. This
code is going to be difficult to maintain/modify.

2. Buggy senderWorkerMap handling:
The code that manages senderWorkerMap is very buggy. It is causing multiple
election rounds. While debugging I found that sometimes after FLE a node
will have its sendWorkerMap empty even if it has SenderWorker and
RecvWorker
threads for each peer.

a) The receiveConnection() method calls the finish() method, which removes
an entry from the map. Additionally, the thread itself calls finish() which
could remove the newly added entry from the map. In short,
receiveConnection
is causing the exact condition that you mentioned above.

b) Apart from the bug in finish(), receiveConnection is making an entry in
senderWorkerMap at the wrong place. Here's the buggy code:
SendWorker vsw = senderWorkerMap.get(sid);
senderWorkerMap.put(sid, sw);
if(vsw != null)
vsw.finish();
It makes an entry for the new thread and then calls finish, which causes
the
new thread to be removed from the Map. The old thread will also get
terminated since finish() will interrupt the thread.

3. Race condition in receiveConnection and initiateConnection:

*In theory*, two peers can keep disconnecting each other's connection.

Example:
T0: Peer 0 initiates a connection (request 1)
                                     T1: Peer 1 receives connection from
peer 0
                                     T2: Peer 1 calls receiveConnection()
T2: Peer 0 closes connection to Peer 1 because its ID is lower.
T3: Peer 0 re-initiates connection to Peer 1 from manger.toSend() (request
2)
                                     T3: Peer 1 terminates older connection
to peer 0
                                     T4: Peer 1 calls connectOne() which
starts new sendWorker threads for peer 0
                                     T5: Peer 1 kills connection created in
T3 because it receives another (request 2) connect request from 0

The problem here is that while Peer 0 is accepting a connection from Peer 1
it can also be initiating a connection to Peer 1. So if they hit the right
frequencies they could sit in a connect/disconnect loop and cause multiple
rounds of leader election.

I think the cause here is again blocking connects()/accepts(). A peer
starts
to take action (to kill existing threads and start new threads) as soon as
a
connection is established at the* *TCP level. That is, it does not give us
any control to synchronized connect and accepts. We could use non-blocking
connects and accepts. This will allow us to a) tell a thread to not
initiate
a connection because the listener is about to accept a connection from the
remote peer (use isAcceptable() and isConnectable()methods of SelectionKey)
and b) prevent a thread from initiating multiple connect request to the
same
peer. It will simplify synchronization.

Any thoughts?

-Vishal

Does the slavedelay option affect reading off the master oplog or
applying operations on the slave? Or are they one in the same
operation?

If the master goes down and the slave is set to a slavedelay of 90
(3m) does the slave lose those operations?