On Apr 13, 2009, at 10:50 AM, Scott Hernandez wrote:

> To Caucho Devs,
> In an effort to get some of my problems diagnosed from the old
> snapshot  I was using(3/18) I delved into the svn trunk. It seems like
> the snapshots (although listed as 03/04/09 in the download page) are
> actually nightly snapshots. This leads me to believe that going
> straight to trunk might be the best idea. Well, maybe it wasn't.

Generally, the svn trunk is not a good idea, because we often make  
fairly large changes that take several days to clean the regressions.

> Is it a good idea to work from svn trunk? I know that depends on how
> close to the edge you want to be but what is your philosophy of the
> state of trunk on each checkin? Is it considered "working" at all
> times? Should I expect things to be broken most of the time until a
> blessed build comes out?

It's supposed to compile :)

> I noticed that the "Named" annotations no longer works in my queue
> def. against trunk. I'm not sure if this is a design decision (and
> will be updated with changes to come; including docs), or a bug.

That's a bug.  In the resin-web.xml and resin.xml, the Resin namespace  
(http://caucho.com/ns/resin) implicitly imports java:urn:ee, which  
contains javax.annotation.Named.  But there's a special bit of code to  
handle the Resin alias; it's not a general capability.

> I don't want to cause any more confusion, or problems but I'm excited
> about getting things working and I keep running into issue that may be
> within resin, or at least with my understanding. I want to work as
> close to the front-lines as I can while still being a little safe.

Snapshots are generally better.  Since we're getting closer to 4.0,  
they should be more frequently updated.

> I'm happy to make tests for all the things I need in my applications
> so that I can run automated tests and stop asking questions which
> might better be answered with source. Is there a test framework for
> resin that I can hook into?

Not a public one.  Our tests are essentially organized around .war  
files, so a war duplicating a problem is really the perfect test.   
Although, a short code snip showing the problem is even better if it's  

-- Scott

> Thanks in advance,
> Scott
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to