date:20060919

This won't quite work.  There's no guarantee that a JCA 1.5 adapter  
with a ResourceAdapter is going to have any outbound connectors at  
all, nor will this pick up any jca 1.0 adapters without a  
ResourceAdapter.


What you want is to use ConnectionFactorySource as the interface in  
your query.


ConnectionFactorySource isn't the connection factory itself, you have  
to call the oddly named method $getResource().  This could be a  
datasource, a jms ConnectionFactory, or just about anything else, so  
you have to test the results to see if its something you want.



Kernel kernel = KernelRegistry.getSingleKernel();
Collection cfss = kernel.listGBeans(new AbstractNameQuery 
(ConnectionFactorySource.class.getName()));

Collection datasources = new ArrayList();
for (Iterator i = cfss.iterator(); i.hasNext(); ) {
Object cf = kernel.invoke((AbstractName)i.next(),  
"$getResource", new Object[] {}, new String[]{});  //this might not  
be the right signature for the invoke method-- this is from memory

   if (cf instanceof DataSource) {
  datasources.add(cf);
   }
}

Hope this helps
david jencks



On Sep 19, 2006, at 10:51 PM, Lasantha Ranaweera wrote:


Hi Aaron,

I want to test the existing db connections in the Geronimo with the  
help of a web application. Following code  helped me to list the  
resource adapters in the server. Now my problem is how to identify  
which are the  db connection adapters and convert them in to  
javax.sql.DataSource.


Kernel kernel = KernelRegistry.getSingleKernel();
 Set list = kernel.listGBeans(new AbstractNameQuery 
(ResourceAdapter.class.getName()));

   for(Iterator iterator = list.iterator();iterator.hasNext();){
   AbstractName name = (AbstractName)iterator.next();
 ResourceAdapter ra = (ResourceAdapter) 
(kernel.getProxyManager().createProxy(name, ResourceAdapter.class));
 //How to indentify is this ra is DataSource or  
not

 }

Any help would be appreciated. If this is can be done better way  
than this please let me know too.

Thanks,
Lasantha Ranaweera

Aaron Mulder wrote:

In Geronimo 1.1, you can use a gbean-ref to map the J2EEServer into
the web application's JNDI space.  From the J2EEServer, you can
navigate to a list of resource adapters (J2EE Connectors), and I  
think

there's a way to check which connection factory interface they
implement (you'd want javax.sql.DataSource).  There's probably a
method in KernelManagementHelper that more or less does that (given a
server get database connection pools) if you want something to refer
to.

Please write back if you need help with the details.

Thanks,
Aaron

On 9/18/06, Lasantha Ranaweera <[EMAIL PROTECTED]> wrote:

Hi All,

I want get the list of database connections deployed in the Geronimo
from a web application. Any help would be appreciated.

Thanks,
Lasantha Ranaweera

Re: How to Access Geronimo Resources from a Web Application?

2006-09-19 Thread Lasantha Ranaweera


Hi Aaron,

I want to test the existing db connections in the Geronimo with the help 
of a web application. Following code  helped me to list the resource 
adapters in the server. Now my problem is how to identify which are the  
db connection adapters and convert them in to javax.sql.DataSource.


Kernel kernel = KernelRegistry.getSingleKernel();
  
   Set list = kernel.listGBeans(new 
AbstractNameQuery(ResourceAdapter.class.getName()));

   for(Iterator iterator = list.iterator();iterator.hasNext();){
   AbstractName name = (AbstractName)iterator.next();
  
   ResourceAdapter ra = 
(ResourceAdapter)(kernel.getProxyManager().createProxy(name, 
ResourceAdapter.class));
  
   //How to indentify is this ra is DataSource or not
  
   }


Any help would be appreciated. If this is can be done better way than 
this please let me know too.

Thanks,
Lasantha Ranaweera

Aaron Mulder wrote:

In Geronimo 1.1, you can use a gbean-ref to map the J2EEServer into
the web application's JNDI space.  From the J2EEServer, you can
navigate to a list of resource adapters (J2EE Connectors), and I think
there's a way to check which connection factory interface they
implement (you'd want javax.sql.DataSource).  There's probably a
method in KernelManagementHelper that more or less does that (given a
server get database connection pools) if you want something to refer
to.

Please write back if you need help with the details.

Thanks,
Aaron

On 9/18/06, Lasantha Ranaweera <[EMAIL PROTECTED]> wrote:

Hi All,

I want get the list of database connections deployed in the Geronimo
from a web application. Any help would be appreciated.

Thanks,
Lasantha Ranaweera

Re: Geronimo site POC using Confluence & Autoexport

2006-09-19 Thread Jeff Turner

On Tue, Sep 19, 2006 at 03:41:58AM -0700, Jason Dillon wrote:
> Did http://people.apache.org/~jefft/confluence/ get moved somewhere  
> else?

The script broke and I disabled it, thinking no-one used it. I take it
this is being used somehow?

Anyway, I've fixed the script and it's running again.


--Jeff

> --jason
> 
> 
> On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:
> 
> >On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
> >>Okay, I think that the sync that Jeff has setup will allow me to move
> >>further on setting up the proof of concept, taking GMOxSITE and
> >>GMOxKB and making them into something suitable to be used for http://
> >>geronimo.apache.org
> >
> >FWIW, http://cwiki.apache.org/ is now being mirrored to
> >http://people.apache.org/~jefft/confluence/ on every autoexport.  
> >There's
> >a 'lastupdated' file that can be polled to check for updates.
> >
> >I installed the Composition plugin. See test at
> >http://cwiki.apache.org/confluence/display/test/Index.  
> >Unfortunately tabs
> >('cards') don't work on the autoexported HTML at
> >http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
> >I'm not
> >sure why - needs some investigation.
> >
> >Discussions are proceeding on infrastructure@ as to how to get  
> >generated
> >HTML into SVN and thus to the live site. It's painful doing  
> >trailblazing
> >but the end goal seems worthwhile. I imagine many other projects  
> >will be
> >interested in this kind of system.
> >
> >
> >--Jeff
> >
> >>--jason
> >>
> >>
> >>On Aug 24, 2006, at 3:02 PM, David Blevins wrote:
> >>
> >>>
> >>>On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
> Sounds like Jeff Turner may be willing to help us solve this
> problem... pending more details.
> >>>
> >>>Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
> >>>open sources a stream editing library with the intention of
> >>>confluence munging, just Peir beat me to it :)  But doing things
> >>>like "munging" urls is a piece of cake:
> >>>
> >>>http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
> >>>test/java/org/codehaus/swizzle/stream/
> >>>ResolveUrlInputStreamTest.java?r=23
> >>>
> >>>I could crank something out in short order if you give me an idea
> >>>of what things need to be updated.
> >>>
> >>>-David
> >>>
> --jason
> 
> 
> On Aug 23, 2006, at 10:17 PM, David Blevins wrote:
> 
> >Assuming you did have access to the box, what steps would be
> >required to get things setup?  I know I'm asking an unnatural
> >question as I typically start my thinking while staring at the
> >command prompt and type commands iteratively till things work.
> >But I'm just thinking if we could maybe figure that out, we could
> >work with someone who does have access.
> >
> >I'd also like to use this for GBuild and OpenEJB, so I'm keen on
> >seeing it solved.
> >
> >-David
> >
> >On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:
> >
> >>So, it looks like there is going to need some convincing to get
> >>access to the exported content, so that we can post process and
> >>massage these spaces into our main website.
> >>
> >>I'm not even sure that it is going to be worth the effort to try
> >>and convince Apache infra that we need the access.  Seems like
> >>they are only willing to give accounts on systems to Apache
> >>members.
> >>
> >>So, I wonder if we could just run our own Confluence instance on
> >>our zone, only use it to author, then export the content,
> >>massage and then svn ci.  I guess we could also do the same by
> >>moving the spaces to goopen.org too, which will provide us the
> >>required access to implement the site that we all want to
> >>implement.
> >>
> >>I'm frustrated... we now have a Confluence instance on ASF, but
> >>we can't really use it to produce the results we want... unless
> >>you want to see http://geronimo.apache.org become a set of
> >>http://cwiki.apache.org* URs... which I find very distasteful.
> >>
> >>There might be some way to configure httpd to rewrite urls so
> >>that http://cwiki.apache.org/GMOxSITE looks like http://
> >>geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
> >>looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
> >>if that is really worth all of the effort.
> >>
> >>I guess we could use wget to grab the entire http://
> >>cwiki.apache.org/GMOxSITE and then massage and check in... but
> >>that is terribly inefficient and add more unwanted time lapse
> >>between updating content to making the content live.
> >>
> >>So, in short... I can't do anything related to making GMOxSITE
> >>the official website until there is a way to get access to the
> >>exported content, or get the httpd configuration changed for our
> >>vhost.
> >>
> >>I feel like we have a spiffy

Re: veryverbose (-vv)

Hey Tim you may want to check out this wiki page for coding standards
and best practices.  It also has some tips on logging:
http://cwiki.apache.org/GMOxDEV/coding-standards.html

Best wishes,
Paul

On 9/19/06, Tim McConnell <[EMAIL PROTECTED]> wrote:

Thanks for the info David and Jason, I already assigned myself the
G-1404 jira related to some logging problems, so I'll use that to try to
clean this up. I've noticed also a lot of inconsistencies in how logging
is and isn't used.  I also hope that there are coding standards and/or
best practices that should be adhered to. Thanks.

Jason Dillon wrote:
> On Sep 19, 2006, at 12:04 PM, David Jencks wrote:
>> I think there is something strange going on with log4j
>> configuration.  To get a reasonable level of coverage in any log
>> (console or file) I have to remove/comment out the line
>>
>> log4j.logger.org.apache.geronimo.gbean.runtime.GBeanSingleReference=DEBUG
>>
>
> Um, this seems very fishy...
>
>
>> In my limited experimentation that line prevents logging just about
>> anything else at debug (and possibly info) no matter what the
>> "global" settings are.
>
> But, the logging config in G is a bit temperamental as I found when I
> was trying to get logging for tests to work as it should when using
> log4j configuration.
>
> There is some code in geronimo-kernel which will insert Log4j
> configuration, which negates some of the configuration that should be
> picked up from log4j.properties.  It may be worth spending a bit of
> time to clean that up, maybe removing the custom injection of logging
> objects, and using a separate log4j-debug.properties or something
> along those lines to allow -v or -vv to install the desired logging
> config.
>
> --jason
>

Re: [Poll] Next release?

2006-09-19 Thread David Blevins



On Sep 19, 2006, at 5:07 PM, David Jencks wrote:


Oops, I missed replying.

For me,

1- cert
2- release date
3- feature set
4- name

I could probably be talked out of the release date priority if we  
are producing weekly certifiable builds and our build/tck process  
is working really smoothly.


I'm really really really worried about the amount of development on  
trunk that has not had the tck run against it.


That pretty much echos my thoughts exactly.

-David



thanks
david jencks

On Sep 19, 2006, at 4:58 PM, Dain Sundstrom wrote:


I only got a few responses, but we the results were almost unanimous
so I'm going to take this as a sign that most people agree with what
was already posted.  If you do disagree with the poll results, please
speak up.

RESULTS:

[1] Certification
[2] Feature Set
[3] Release Date
[4] Release Name

Certification is a requirement and timeline will be pushed to achieve
a desired feature set and no one seems to care what the release are
named :)


Based on this feed back, I will start another thread where we can
discuss the feature requirements for the next release.  Again if you
disagree, please jump in now.

Thanks for the feed back,

-dain

On 9/8/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
In an attempt to quantify our expectation about the next release  
from

trunk, please rank the following items in importance to you:

[ ] Release Date
[ ] Feature Set
[ ] Release Name
[ ] Certification

Re: veryverbose (-vv)

2006-09-19 Thread Tim McConnell

Thanks for the info David and Jason, I already assigned myself the 
G-1404 jira related to some logging problems, so I'll use that to try to 
clean this up. I've noticed also a lot of inconsistencies in how logging 
is and isn't used.  I also hope that there are coding standards and/or 
best practices that should be adhered to. Thanks.


Jason Dillon wrote:

On Sep 19, 2006, at 12:04 PM, David Jencks wrote:
I think there is something strange going on with log4j 
configuration.  To get a reasonable level of coverage in any log 
(console or file) I have to remove/comment out the line


log4j.logger.org.apache.geronimo.gbean.runtime.GBeanSingleReference=DEBUG 



Um, this seems very fishy...


In my limited experimentation that line prevents logging just about 
anything else at debug (and possibly info) no matter what the 
"global" settings are.


But, the logging config in G is a bit temperamental as I found when I 
was trying to get logging for tests to work as it should when using 
log4j configuration.


There is some code in geronimo-kernel which will insert Log4j 
configuration, which negates some of the configuration that should be 
picked up from log4j.properties.  It may be worth spending a bit of 
time to clean that up, maybe removing the custom injection of logging 
objects, and using a separate log4j-debug.properties or something 
along those lines to allow -v or -vv to install the desired logging 
config.


--jason

Getting releases out


I have been poking around at the release stuff for a few days and feel
I have an understanding of the necessary steps to get a release out.
Unfortunately, there seem to be loads of items on the check list.  In
order to keep myself sane, I have divided them into three areas:
schedule, mechanics and certification... a description of each
follows.  I greatly appreciate any comments and questions.

Thanks,

-dain



Schedule

Based on the feedback from the poll, we are going to feature-box our
releases.  This means we need come to an agreement on what is in the
1.2 release.  I will start another email thread to discuss the 1.2
feature set and priorities.  Once we know the required feature set we
will be able to track the progress of the release based on the
completed features.


Mechanics

The maven configuration, shell scripts, review process and voting
procedure for a release are all quite complex and can have a big
impact on the release.   I think this area will benefit greatly from
practicing and iterative improvement.  I'd like to start by posting a
binary each Wednesday to
http://people.apache.org/dist/geronimo/unstable/ and every week add at
least one improvement to the process.   Starting with tomorrow here is
what I'd like to improve for the next few weeklies:

9/20 - Simply get the first binary posted with a change log swizzled from JIRA
9/27 - Add a script or maven config to change the version number of G
to 1.2-${svn rev}
10/4 - Practice the review and voting process by pushing a voted upon
monthly snapshot (just an idea)

Hopefully, I'll be able to con a few of you in to help tune some parts
of the release process.  If you have some free cycles, and want to
help with build/release stuff, please jump in and help.


Certification

This has always been a big chore for us and the amount of time we
spend on it seems to be exponentially proportional to the length of
time that has passed since our last certification.  In the case of
1.2, I fear we are going to have to spend a lot of time on this.   In
the future, I'd like to move us to a continuous TCK testing mode where
we get a report every morning indicating whether or not the previous
day's commits broke anything.  For now, I'd love to have our weekly
binaries tested and get results within a few days.

Re: [Poll] Next release?


Oops, I missed replying.

For me,

1- cert
2- release date
3- feature set
4- name

I could probably be talked out of the release date priority if we are  
producing weekly certifiable builds and our build/tck process is  
working really smoothly.


I'm really really really worried about the amount of development on  
trunk that has not had the tck run against it.


thanks
david jencks

On Sep 19, 2006, at 4:58 PM, Dain Sundstrom wrote:


I only got a few responses, but we the results were almost unanimous
so I'm going to take this as a sign that most people agree with what
was already posted.  If you do disagree with the poll results, please
speak up.

RESULTS:

[1] Certification
[2] Feature Set
[3] Release Date
[4] Release Name

Certification is a requirement and timeline will be pushed to achieve
a desired feature set and no one seems to care what the release are
named :)


Based on this feed back, I will start another thread where we can
discuss the feature requirements for the next release.  Again if you
disagree, please jump in now.

Thanks for the feed back,

-dain

On 9/8/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

In an attempt to quantify our expectation about the next release from
trunk, please rank the following items in importance to you:

[ ] Release Date
[ ] Feature Set
[ ] Release Name
[ ] Certification

Re: [Poll] Next release?


I only got a few responses, but we the results were almost unanimous
so I'm going to take this as a sign that most people agree with what
was already posted.  If you do disagree with the poll results, please
speak up.

RESULTS:

[1] Certification
[2] Feature Set
[3] Release Date
[4] Release Name

Certification is a requirement and timeline will be pushed to achieve
a desired feature set and no one seems to care what the release are
named :)


Based on this feed back, I will start another thread where we can
discuss the feature requirements for the next release.  Again if you
disagree, please jump in now.

Thanks for the feed back,

-dain

On 9/8/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

In an attempt to quantify our expectation about the next release from
trunk, please rank the following items in importance to you:

[ ] Release Date
[ ] Feature Set
[ ] Release Name
[ ] Certification

Re: [stomp-dev] Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)

2006-09-19 Thread Hiram Chirino


I think that the client should only be allowed to change the default
mapping if he optionally specifies a 'protocol-mapping' header when he
connects.  Something like

CONNECT
login:
passcode:
protocol-mapping: foo

Where foo is mapped to a implementation of ProtocolMapper/Converter.
Then the client will be expected to send messages in that mapping
format and all messages sent to it will also conform to that format.

On 9/19/06, Dejan Bosanac <[EMAIL PROTECTED]> wrote:

And one copy for this list as I assume that we will continue discussion here :)

On 9/19/06, Dejan Bosanac <[EMAIL PROTECTED]> wrote:
> I think that in order to make this framework usable, it has to be
> simple. It could be a simple interface such as
>
> public interface ProtocolTransformer {
>  public StompFrame convertMessage(ActiveMQMessage message)
> throws IOException, JMSException;
>
>  public  ActiveMQMessage convertMessage(StompFrame command)
> throws IOException, JMSException;
> }
>
> this two methods would be called at appropriate places (probably at
> the begging) of the methods in the ProtocolConverter class. In this
> way we would allow developers to change message type and/or set
> appropriate headers, which seems to me would be more than enough.
>
> The one thing that I'm not sure of is how the ProtocolConverter will
> decide which transformers it should call. For incoming Stomp messages
> someone mentioned a solution which seems fine: to put an extra header
> in the stomp message (such as amq-msg-type or activemq-transformation
> or whatever) which would have a full class name of the transformer to
> be applied. Then the ProtocolConverter would try to load this
> transformer and if it succeed it would apply the transformation.
>
> But this solution is not working for messages that are sent from the
> broker to the stomp clients. We need some mechanism which will say,
> apply this transformation to the ByteMessages so we need a mechanism
> that will be able to register all transformers to the
> ProtocolConverter and then every transformer would be responsible to
> detect whether it should or not change the message.
>
> For configuring purposes we could use Service Provider JAR
> functionality 
(http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider)
> since it is the only way I can think of that not requires external
> configuration.
>
> Two questions that we need to address:
>
> 1. do we want to enable more than one transformation to be applied?
> 2. how this framework will affect overall performances?
>
> What do you think?
>
> Regards,
> Dejan
>
> On 9/19/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
> > (Replying at top as it is a long message :-)
> >
> > The mapping be configured by naming a "converter" of some kind in the
> > activemq.xml
> >
> > This is a bit tricksier than it might be because the activemq.xml is
> > just a specialized spring config which reads a lot of stuff from a
> > URL syntax, and adding Java classnames in a URL is the ick.
> >
> > I've started poking around and my current plan is to pull the AMQ
> > message creating and Stomp message creation bits out of the protocol
> > converter and use an implementation of some mapping interface to do
> > the conversion.
> >
> > Exactly what the interface needs to look like I am not sure yet. In
> > order to handle largish messages, it should probably deal with
> > DataInput (AMQ's stream/buffer+channel hiding thing) instances, but
> > we'll have had to already parse the type to get this far, so it may
> > be a case of doing some parsing of the headers, and passing the data
> > input in to be munged, or it may fall out that something else is more
> > useful.
> >
> > For encoding AMQ to stomp, we are faced with something similar -- we
> > pass in the JMS message, which might be a stream message with a large
> > body, we probably want to be able to "chunk" it out, that means
> > either making a stomp frame abstraction which can read from a stream
> > and is returned by the converter, or having the converter actually
> > "send" the message on the wire. Not sure which I like more.
> >
> > Thoughts?
> >
> > -Brian
> >
> > On Sep 18, 2006, at 7:45 AM, Dejan Bosanac wrote:
> >
> > > Thanks James.
> > >
> > >
> > >>
> > >> We've a Stomp transport for ActiveMQ which is here...
> > >> http://incubator.apache.org/activemq/maven/activemq-core/xref/org/
> > >> apache/activemq/transport/stomp/package-summary.html
> > >>
> > >> which can currently deal with all the stomp messages nicely. Maybe
> > >> you
> > >> mean to extend that? Or did you have something else in mind?
> > >>
> > >
> > >
> > > In one of his comments Brian said that he plans to create pluggable
> > > handling framework for stomp messages for ActiveMQ 4.1.
> > >
> > > Following that idea, I have even found a discussion on this topic
> > >
> > > http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/
> > > 200606.mbox/%
> > > [EMAIL PROTECTED]
> > >
> > > which is

Re: Deadlock on BounderLinkedQueue

2006-09-19 Thread robin.byrne


Done. See SM-585.

Thanks.


gnodet wrote:
> 
> Sounds like a big problem.
> Could you please raise a JIRA and attach the necessary files and
> instructions to reproduce the problem ?
> 
> Thanks,
> 
> On 9/19/06, robin.byrne <[EMAIL PROTECTED]> wrote:
>>
>> We've encountered a problem with slow endpoints leading to a deadlock
>> situation around the BoundedLinkedQueue. We've reproduce the problem with
>> Seda, JMS and JCA flows.
>> The situation is similar to that described for SM-512/SM-521 in the Jira,
>> athough we don't think sendSync is necessarily involved.
>>
>> Our servicemix configuration started with a JMS endpoint receiving
>> messages
>> from a topic.  The messages were sent to a pipeline which invoked an XSL
>> transform and forwarded the result to an HTTPComponent. The HTTPComponent
>> sent the transformed messages to a SOAP service.
>>
>> We noticed that rapidly sending a large number of messages to the JMS
>> topic
>> would lock up ServiceMix. That is,
>>
>> 1)  no more messages were sent to the SOAP service
>> 2)  more messages would simply create more blocked threads
>> 3)  ServiceMix never recovered.
>>
>> We suspected that the slowness of the HTTP interaction was triggering the
>> problem.  To confirm this we replaced the HTTPComponent with a
>> TraceComponent - modified to wait a configurable number of millis before
>> sending the done message.
>>
>> We were able to reliably recreate the problem.  We found that, in the
>> blocked state, all of the worker threads were waiting to put ME's into
>> the
>> BoundedLinkedQueue.  Many of the threads were blocked trying to put
>> 'done'
>> messages into the queue.
>>
>> We found that, as long as the Queue for the TraceComponent remained below
>> capacity, that system continued to work. However, when the queue for that
>> component hit capacity (100 MEs) the Trace output stopped.  Even if the
>> inbound flow of messages stopped at that point, and all of the other
>> queue's
>> were empty, the queue for the TraceComponent retained those 100 MEs
>>
>> After that, the next 100 inbound messages simply filled up the prior
>> Queue
>> (for the XSLT) until it hit capacity.  And so it went until all of Queues
>> were full. Once all of the Queue's were full each new message created a
>> thread that blocked trying to put the new ME into the first Queue.
>>
>> There seems to be a problem here beyond something that can be handled by
>> throttling configuration. The ESB should never lock up like this - or
>> even
>> be at risk of locking up like this the throttling doesn't prevent a
>> message
>> backlog.
>>
>> Thanks,
>> Robin Byrne
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Deadlock-on-BounderLinkedQueue-tf2300852.html#a6394549
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Deadlock-on-BounderLinkedQueue-tf2300852.html#a6397501
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

[jira] Created: (SM-585) Deadlock on BoundedLinkedQueue

2006-09-19 Thread Robin Byrne (JIRA)

Deadlock on BoundedLinkedQueue
--

 Key: SM-585
 URL: https://issues.apache.org/activemq/browse/SM-585
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-jbi
Affects Versions: 3.0
 Environment: Windows XP, Java 5
Reporter: Robin Byrne
Priority: Critical
 Attachments: deadlock.zip

We've encountered a problem with slow endpoints leading to a deadlock situation 
around the BoundedLinkedQueue. We've reproduce the problem with Seda, JMS and 
JCA flows.
The situation is similar to that described for SM-512/SM-521 in the Jira, 
although we don't think sendSync is necessarily involved.

Our servicemix configuration started with a JMS endpoint receiving messages 
from a topic.  The messages were sent to a pipeline which invoked an XSL 
transform and forwarded the result to an HTTPComponent. The HTTPComponent sent 
the transformed messages to a SOAP service.

We noticed that rapidly sending a large number of messages to the JMS topic 
would lock up ServiceMix. That is,  

1) no more messages were sent to the SOAP service
2) more messages would simply create more blocked threads
3) ServiceMix never recovered.

We suspected that the slowness of the HTTP interaction was triggering the 
problem.  To confirm this we replaced the HTTPComponent with a TraceComponent - 
modified to wait a configurable number of millis before sending the done 
message.

We were able to reliably recreate the problem.  We found that, in the blocked 
state, all of the worker threads were waiting to put ME's into the 
BoundedLinkedQueue.  Many of the threads were blocked trying to put 'done' 
messages into the queue.

We found that, as long as the Queue for the TraceComponent remained below 
capacity, that system continued to work. However, when the queue for that 
component hit capacity (100 MEs) the Trace output stopped.  Even if the inbound 
flow of messages stopped at that point, and all of the other queue's were 
empty, the queue for the TraceComponent retained those 100 MEs

After that, the next 100 inbound messages simply filled up the prior Queue (for 
the XSLT) until it hit capacity.  And so it went until all of Queues were full. 
Once all of the Queue's were full each new message created a thread that 
blocked trying to put the new ME into the first Queue.

The attached zip file contains the servicemix config file, xslt, and modified 
TraceComponent.java necessary to recreate the problem. You will also need a 
test harness capable of pushing a lot of messages into the JMS topic.  A burst 
of 250 messages onto the JMS topic should do it.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: veryverbose (-vv)


On Sep 19, 2006, at 12:04 PM, David Jencks wrote:
I think there is something strange going on with log4j  
configuration.  To get a reasonable level of coverage in any log  
(console or file) I have to remove/comment out the line


log4j.logger.org.apache.geronimo.gbean.runtime.GBeanSingleReference=DE 
BUG


Um, this seems very fishy...


In my limited experimentation that line prevents logging just about  
anything else at debug (and possibly info) no matter what the  
"global" settings are.


But, the logging config in G is a bit temperamental as I found when I  
was trying to get logging for tests to work as it should when using  
log4j configuration.


There is some code in geronimo-kernel which will insert Log4j  
configuration, which negates some of the configuration that should be  
picked up from log4j.properties.  It may be worth spending a bit of  
time to clean that up, maybe removing the custom injection of logging  
objects, and using a separate log4j-debug.properties or something  
along those lines to allow -v or -vv to install the desired logging  
config.


--jason

Re: Let us please use a JIRA for every code change we make


On Sep 19, 2006, at 7:57 AM, Prasad Kashyap wrote:

I am more concerned about having a ready link between a change and
it's relevant discussion. How do we maintain it ? Would people have to
take the trouble of googling the  archives to search for the relevant
discussion ? This is kinda tangential to the discussion on the other
thread about having javadocs.

Going thro' subversion history doesn't necessarily provide this link.
Not all changes have the required, appropriate comments.


I would be more inclined to put the relevant comments into the  
subversion commit, as IMO that is the definitive location for the  
projects data.  JIRA provides a view on top of subversion to better  
organize tasks and bugs, and rolls that up into versions nicly... but  
when something breaks, I want to be able to look at the history of  
svn to see what is going on... and bouncing back and forth from svn  
to JIRA because all of the details are in the JIRA would be a PITA.


Anyways, I have seen companies "force" JIRA's for every commit... in  
fact I implemented that at my last gig... and it blew up because  
people would just create lame JIRA issues... which just trashes up  
JIRA making is overall less useful.


However, I do think that for controlled branches that it is a good  
idea... but not as a general policy.  General policy that dictates  
forced JIRA creation for everything is a very, very, very bad idea.   
This is open source... not IBM :-P




Next,  are there any guidelines about when to create JIRAs and when
one can get by without ?


Well... if you contribute by patches, then you need to create an  
issue, which is obvious.  If you are making a non-trivial change that  
should be noted in the release material then you should make an issue  
(like if you are adding, changing or removing a dependency).  New  
features should obviously get issues, same with bugs.  And I guess if  
you can't decide if it needs an issue or not... then I would learn  
towards creating an issue.


But more generally, JIRA issues should be used to track tasks and  
bugs... not individual changes to code.  The changes augment the JIRA  
data, so that when looking at the issue one can get a complete (more  
or less, hopefully more) picture about what was done to implement/fix  
the feature/bug.


IMO, if there is a relevant JIRA, then the svn commit should include  
the JIRA id (exact case, so that the JIRA svn plugin can link it  
properly).  The comment in svn should also include the relevant  
change details, and should never (ever) just include the JIRA id...  
in fact this is probably one of the only hard and fast rule that I  
think is worth enforcing... that and maybe don't but in garbage into  
the commit msg... I have seen it before (not here) where people just  
type in random garbage (mostly with p4, since it requires a non-empty  
description).


--jason

Re: Re: Dojo Toolkit inclusion to Geronimo


The unzipped distribution contains some unnecessary files that I
weeded out of the webapp -- demos, tests, etc.  But the deployed
webapp (which just contains the library files) still weighs in at
4.3mb, so you can start to see the savings when multiple apps in the
same server share the same copy.  I've also read about clustered
applications sharing a single copy of Dojo using its experimental new
cross domain feature.

It might be possible to make the shared copy smaller by using Dojo's
custom build feature which allows you to create a streamlined library
that only contains the stuff you need, and all bundled into a single
file.  Cameron Braid provided some input to that effect earlier in
this thread.  As people start to use the webapp I hope we can collect
some feedback that will help determine where to take that idea.

Best wishes,
Paul

On 9/19/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

BTW how big are the DOJO files?

-dain

Re: Let us please use a JIRA for every code change we make

2006-09-19 Thread Jacek Laskowski


On 9/19/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

There are always small changes that are not directly tied to a
specific JIRA issue.  My point is that by making it a requirement to
have a JIRA issue that people will end up creating more issues than
we really nee (or want).

I have made a lot of small changes to the build which fit into this
category.  Some clean up also fits into that category.  Say, adding
or fixing javadocs, or adding TODO comments, etc... all things which
probably don't have a JIRA issue and it would be a PITA to force
folks to go an make one.  That is way to artificial and pointless.


Thanks Jason. That's really helped.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

[jira] Commented: (GERONIMO-2415) TestSupport should support xmlbeans tests

[ 
http://issues.apache.org/jira/browse/GERONIMO-2415?page=comments#action_12435988
 ] 

David Jencks commented on GERONIMO-2415:


oops, committed in rev 447942

> TestSupport should support xmlbeans tests
> -
>
> Key: GERONIMO-2415
> URL: http://issues.apache.org/jira/browse/GERONIMO-2415
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 1.2
>
> Attachments: GERONIMO-2415.patch
>
>
> There are a bunch of tests of xmlbeans functionality scattered through the 
> code that all have copies of a compare method.  I'd like to move this to a 
> testsupport-common class.  This involves dragging xmlbeans into all modules 
> test dependencies.  Would it be better to create another module for this 
> class?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-2415) TestSupport should support xmlbeans tests

 [ http://issues.apache.org/jira/browse/GERONIMO-2415?page=all ]

David Jencks closed GERONIMO-2415.
--

Resolution: Fixed
  Assignee: David Jencks  (was: Jason Dillon)

Discussed with jdillon on irc, we couldn't find any problems with this.  IIUC 
xmlbeans will be added to the surefire classpath but never the compile cp 
through using testsupport-common.

> TestSupport should support xmlbeans tests
> -
>
> Key: GERONIMO-2415
> URL: http://issues.apache.org/jira/browse/GERONIMO-2415
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 1.2
>
> Attachments: GERONIMO-2415.patch
>
>
> There are a bunch of tests of xmlbeans functionality scattered through the 
> code that all have copies of a compare method.  I'd like to move this to a 
> testsupport-common class.  This involves dragging xmlbeans into all modules 
> test dependencies.  Would it be better to create another module for this 
> class?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Re: Dojo Toolkit inclusion to Geronimo

BTW how big are the DOJO files?

-dain

On 9/19/06, Paul McMahan <[EMAIL PROTECTED]> wrote:

OK based on discussion here on the dev list and in GERONIMO-2333 I
just committed the code for GERONIMO-2406 into trunk rev 447903.  This
introduces the Dojo files as a new webapp into the server and creates
a dependency from the console onto this app so that Chris can
reference it from the JMX Debug portlet at /dojo instead of checking
in a private copy for the console.  When an application is deployed
into Geronimo and the console is already deployed it can use the
shared copy.  Otherwise it can install the Dojo webapp as a plugin --
AFAIK all the files are in place to generate the plugin I just have to
make sure that it gets out to a plugin repository, etc.

I will add a wiki page to describe all this.

This is my first commit while Geronimo has just gone back to CTR so I
hope I have not botched something up.  If I made any rookie mistakes
then please be gentle and I promise to fix it :-)

Best wishes,
Paul

On 9/13/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> Gianny,  I agree that the JMX Viewer portlet Chris has contributed is
> fantastic and more people should take a look at it!  I also agree that
> we should think about how the Dojo files are checked in -- directly in
> the console vs. as a separate module.  I was thinking about creating a
> separate web app containing the Dojo files that could be shared across
> all web apps in Geronimo and managed separately from them.  The thread
> Chris referenced above discusses the idea in more detail:
> http://www.mail-archive.com/dev@geronimo.apache.org/msg29777.html
>
> Maybe the time is right to move forward on that idea (or some variant)
> and let the JMX viewer portlet be the first exploiter.  Or if Chris'
> current implementation is integrated as-is then we discussed
> retrofitting it to work this way later -- see the comments in
> GERONIMO-2333.
>
> Best wishes,
> Paul
>
> On 9/13/06, Gianny Damour <[EMAIL PROTECTED]> wrote:
> > Hi Chris,
> >
> > The JMX Viewer portlet is finally working for me. Actually, it seems
> > that due to a Dojo known issue, this portlet does not work with
> > Safari :(; having said that, it works really nicely, and I really
> > mean really nicely, with IE.
> >
> > Regarding your patch, I believe that this is a large piece of work;
> > unfortunately, I cannot appreciate it as this is the first time that
> > I am seeing dojo in action. Also, I think that instead of checking in
> > the dojo files directly at the right location, we should check in a
> > tar.ball of these files and expand it upon build of the module. I
> > think that this is better because this way we do know which files are
> > dojo specifics (this is a minor detail). What do you think?
> >
> > It would be cool if other people could have a look to this patch; for
> > sure, it really deserves it!
> >
> > Thanks,
> > Gianny
> >
>

Re: Goals for 1.2 - Thoughts


I'm cool with this, but I'd like to release what we have in trunk
right now as 1.2 before implementing this plan.  That way we know we
are starting with a solid certified base, and we have a maintenance
location for the current users.

-dain

On 9/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

All,

I'm not sure I've seen this question asked directly so if I'm
repeating please forgive me.

What if we focus 1.2 not on a release (certified release) but go to
milestones, switch to J2SE 1.5 and focus on JEE 5.  This means that
we make 1.1.1 our last 1.4 certified release.

I'd prefer this as we can focus on the next big goal and not try to
boil the ocean.  Sacrilege ?


Matt Hogstrom
[EMAIL PROTECTED]

[jira] Created: (AMQ-929) Invalid XSD (according to XML Spy)

2006-09-19 Thread Stephen Cresswell (JIRA)

Invalid XSD (according to XML Spy)
--

 Key: AMQ-929
 URL: https://issues.apache.org/activemq/browse/AMQ-929
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.1
 Environment: N/A
Reporter: Stephen Cresswell
Priority: Minor


XmlSpy reports 
http://people.apache.org/repository/org.apache.activemq/xsds/activemq-core-4.1-incubator-SNAPSHOT.xsd
 is invalid with the following message:

 makes the content model non-deterministic. 
Possible causes: name equality, overlapping occurance or substitution groups.

It's complaining because it has no way to validate whether it should validate 
against tns:topic/tns:queue or the xs:any for the following element


   
  
 
 
 
  
   


Possible fix adapted from 
http://www.thescripts.com/forum/threadedpost1605613.html:






   








But I suspect difficult to fix as the XSD is autogenerated + you'll lose 
backwards compatability with previous documents. The problem occurs repeatedly 
throughout the schema.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (AMQ-930) Session 'consumers' hashtable susceptible to invalid operation exception

2006-09-19 Thread Bryan Schmidt (JIRA)

Session 'consumers' hashtable susceptible to invalid operation exception


 Key: AMQ-930
 URL: https://issues.apache.org/activemq/browse/AMQ-930
 Project: ActiveMQ
  Issue Type: Bug
  Components: NMS (C# client)
Affects Versions: incubation
 Environment: Windows XP, NMS API running against a AMQ 4.0.2 provider
Reporter: Bryan Schmidt


In a multithreaded environment that reuses the Session object, the following 
exception is thrown:

Invalid operation exception with the text: "Collection was modified; 
enumeration operation may not execute."

The exception is thrown when iterating through Session's consumers.Values 
collection.  It appears that the lock is being ignored.  Spinning up a new 
thread fixes the problem:

--- Session.cs, DispatchAsyncMessages method ---

public void DispatchAsyncMessages(object state)
{
// lets iterate through each consumer created by this session
// ensuring that they have all pending messages dispatched
lock (this)
{
// lets ensure that only 1 thread dispatches messages in a 
consumer at once

foreach (MessageConsumer consumer in consumers.Values)
{
ThreadPool.QueueUserWorkItem(new 
WaitCallback(consumer.DispatchAsyncMessages));
}
}
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Deadlock on BounderLinkedQueue

2006-09-19 Thread Guillaume Nodet


Sounds like a big problem.
Could you please raise a JIRA and attach the necessary files and
instructions to reproduce the problem ?

Thanks,

On 9/19/06, robin.byrne <[EMAIL PROTECTED]> wrote:


We've encountered a problem with slow endpoints leading to a deadlock
situation around the BoundedLinkedQueue. We've reproduce the problem with
Seda, JMS and JCA flows.
The situation is similar to that described for SM-512/SM-521 in the Jira,
athough we don't think sendSync is necessarily involved.

Our servicemix configuration started with a JMS endpoint receiving messages
from a topic.  The messages were sent to a pipeline which invoked an XSL
transform and forwarded the result to an HTTPComponent. The HTTPComponent
sent the transformed messages to a SOAP service.

We noticed that rapidly sending a large number of messages to the JMS topic
would lock up ServiceMix. That is,

1)  no more messages were sent to the SOAP service
2)  more messages would simply create more blocked threads
3)  ServiceMix never recovered.

We suspected that the slowness of the HTTP interaction was triggering the
problem.  To confirm this we replaced the HTTPComponent with a
TraceComponent - modified to wait a configurable number of millis before
sending the done message.

We were able to reliably recreate the problem.  We found that, in the
blocked state, all of the worker threads were waiting to put ME's into the
BoundedLinkedQueue.  Many of the threads were blocked trying to put 'done'
messages into the queue.

We found that, as long as the Queue for the TraceComponent remained below
capacity, that system continued to work. However, when the queue for that
component hit capacity (100 MEs) the Trace output stopped.  Even if the
inbound flow of messages stopped at that point, and all of the other queue's
were empty, the queue for the TraceComponent retained those 100 MEs

After that, the next 100 inbound messages simply filled up the prior Queue
(for the XSLT) until it hit capacity.  And so it went until all of Queues
were full. Once all of the Queue's were full each new message created a
thread that blocked trying to put the new ME into the first Queue.

There seems to be a problem here beyond something that can be handled by
throttling configuration. The ESB should never lock up like this - or even
be at risk of locking up like this the throttling doesn't prevent a message
backlog.

Thanks,
Robin Byrne

--
View this message in context: 
http://www.nabble.com/Deadlock-on-BounderLinkedQueue-tf2300852.html#a6394549
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.





--
Cheers,
Guillaume Nodet

Web site - quick update

2006-09-19 Thread Hernan Cunico


Hi all,
I just updated the web site to include v1.1.1 download links. I also did some 
housekeeping with the news and events.
These changes should be available within the next hour.

Cheers!
Hernan

Re: veryverbose (-vv)

I think there is something strange going on with log4j  
configuration.  To get a reasonable level of coverage in any log  
(console or file) I have to remove/comment out the line


log4j.logger.org.apache.geronimo.gbean.runtime.GBeanSingleReference=DEBU 
G


In my limited experimentation that line prevents logging just about  
anything else at debug (and possibly info) no matter what the  
"global" settings are.


thanks
david jencks


On Sep 19, 2006, at 11:53 AM, Tim McConnell wrote:

I'm trying to debug some of my changes for G-1526 but am not  
getting the level of trace information I would expect. Is the  
VERYVERBOSE startup option (-vv) still the best option to use to  
get the most trace/debug output ?? Thanks.

Re: Let us please use a JIRA for every code change we make

2006-09-19 Thread Sachin Patel

I am not in favor of overloading JIRA with JIRAs and putting a JIRA policy in place until the existing defects are scrubbed and so we can accurately rely on JIRA for project/release status.On Sep 19, 2006, at 10:57 AM, Prasad Kashyap wrote:Kevan, Jason, Blevins, et al,Thanks for your constructive feedback and comments. You are right. Theissue is not about the type of changes Jason mentioned. Those don'twarrant a JIRA. Jason recently strenghtened the protection and privacyon some methods. It would be ridiculous to expect him to file a JIRAfor it. Moreover, I come from a work culture where EVERY single changehad to go thro' a JIRA and I have bitched, moaned and complainedabout it. So this to me is manna.I am more concerned about having a ready link between a change andit's relevant discussion. How do we maintain it ? Would people have totake the trouble of googling the archives to search for the relevantdiscussion ? This is kinda tangential to the discussion on the otherthread about having javadocs.Going thro' subversion history doesn't necessarily provide this link.Not all changes have the required, appropriate comments.Next, are there any guidelines about when to create JIRAs and whenone can get by without ?ThanxPrasadOn 9/19/06, Kevan Miller <[EMAIL PROTECTED]> wrote: On Sep 19, 2006, at 6:57 AM, Jason Dillon wrote:> There are always small changes that are not directly tied to a> specific JIRA issue. My point is that by making it a requirement> to have a JIRA issue that people will end up creating more issues> than we really nee (or want).>> I have made a lot of small changes to the build which fit into this> category. Some clean up also fits into that category. Say, adding> or fixing javadocs, or adding TODO comments, etc... all things> which probably don't have a JIRA issue and it would be a PITA to> force folks to go an make one. That is way to artificial and> pointless.I agree with Jason. There are instances (and Jason's mentioned a few)where generating a Jira ends up producing noise to the community andextra work for the developer, without delivering any additionalbenefit to the community.Prasad,Perhaps you can be a little more explicit about the problem and wecan work our way to a solution?I doubt that the types of changes referenced by Jason are the typesof changes that you're seeing a problem with... Perhaps you candiscuss the problem a bit more specifically? Are you seeing instanceswhere larger functional enhancements/commits aren't referencing Jira/discussion?I'm guessing that you are seeing commits for significant functionalenhancements for which a Jira was not created (and thus notreferenced in the commit message). If this is your issue, then Ithink we can find a reasonable solution which the community willagree with...--kevan -sachin

Re: Goals for 1.2 - Thoughts



On Sep 19, 2006, at 10:56 AM, Matt Hogstrom wrote:


All,

I'm not sure I've seen this question asked directly so if I'm  
repeating please forgive me.


What if we focus 1.2 not on a release (certified release) but go to  
milestones, switch to J2SE 1.5 and focus on JEE 5.  This means that  
we make 1.1.1 our last 1.4 certified release.


I'd prefer this as we can focus on the next big goal and not try to  
boil the ocean.  Sacrilege ?


I don't think this is a good idea.

I think we need to make sure our stuff still is j2ee 1.4 compliant as  
we integrate jee5 bits.  In particular openejb2 has never been run  
past the tck.  I'm very much afraid that if we try to make our next  
release jee5 it will be at least a year before we can release anything.


With our release/branch numbering principles we cannot migrate any  
changes from trunk into the 1.1 branch and release a 1.1.x with e.g.  
the current openejb2 trunk.


I also think that the exercise of making the j2ee1.4/jee5 support  
pluggable will have very good consequences for the micro-architecture  
and independence of the components and will greatly encourage  
appropriate separation of concerns and pluggability.


I'm still waiting to find out from Geir/Sun about whether we can ship  
a j2ee 1.4 certified server that includes j2ee5 interfaces.  If we  
can this will simplify migration considerably.


thanks
david jencks




Matt Hogstrom
[EMAIL PROTECTED]

Re: build failure


I am hitting the same problem as Manu when trying to build rev 447926
from scratch.  This is strange because I can't find where
tranql-parent is referenced.

[INFO] Scanning for projects...
[INFO] 

[INFO] Building Geronimo :: Connector
[INFO]task-segment: [install]
[INFO] 

[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: 
http://dist.codehaus.org/org.tranql/poms/tranql-parent-1.0-SNAPSHOT.pom
[WARNING] Unable to get resource from repository codehaus-m1
(http://dist.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/tranql/tranql-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading: 
http://snapshots.repository.codehaus.org/org/tranql/tranql-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
[WARNING] Unable to get resource from repository codehaus-snapshots
(http://snapshots.repository.codehaus.org)
Downloading: 
http://people.apache.org/maven-snapshot-repository/org/tranql/tranql-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots
(http://people.apache.org/maven-snapshot-repository)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.tranql
ArtifactId: tranql-parent
Version: 1.0-SNAPSHOT

Reason: Unable to download the artifact from any repository

 org.tranql:tranql-parent:pom:1.0-SNAPSHOT

 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   codehaus-m1 (http://dist.codehaus.org),
   apache.snapshots (http://people.apache.org/maven-snapshot-repository),
   codehaus (http://repository.codehaus.org),
   apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
   codehaus-snapshots (http://snapshots.repository.codehaus.org)

Deadlock on BounderLinkedQueue

2006-09-19 Thread robin.byrne


We’ve encountered a problem with slow endpoints leading to a deadlock
situation around the BoundedLinkedQueue. We’ve reproduce the problem with
Seda, JMS and JCA flows.
The situation is similar to that described for SM-512/SM-521 in the Jira,
athough we don’t think sendSync is necessarily involved.

Our servicemix configuration started with a JMS endpoint receiving messages
from a topic.  The messages were sent to a pipeline which invoked an XSL
transform and forwarded the result to an HTTPComponent. The HTTPComponent
sent the transformed messages to a SOAP service.

We noticed that rapidly sending a large number of messages to the JMS topic
would lock up ServiceMix. That is,  

1)  no more messages were sent to the SOAP service 
2)  more messages would simply create more blocked threads
3)  ServiceMix never recovered.

We suspected that the slowness of the HTTP interaction was triggering the
problem.  To confirm this we replaced the HTTPComponent with a
TraceComponent - modified to wait a configurable number of millis before
sending the done message. 

We were able to reliably recreate the problem.  We found that, in the
blocked state, all of the worker threads were waiting to put ME’s into the
BoundedLinkedQueue.  Many of the threads were blocked trying to put ‘done’
messages into the queue.

We found that, as long as the Queue for the TraceComponent remained below
capacity, that system continued to work. However, when the queue for that
component hit capacity (100 MEs) the Trace output stopped.  Even if the
inbound flow of messages stopped at that point, and all of the other queue’s
were empty, the queue for the TraceComponent retained those 100 MEs

After that, the next 100 inbound messages simply filled up the prior Queue
(for the XSLT) until it hit capacity.  And so it went until all of Queues
were full. Once all of the Queue’s were full each new message created a
thread that blocked trying to put the new ME into the first Queue.

There seems to be a problem here beyond something that can be handled by
throttling configuration. The ESB should never lock up like this - or even
be at risk of locking up like this the throttling doesn’t prevent a message
backlog.

Thanks, 
Robin Byrne

-- 
View this message in context: 
http://www.nabble.com/Deadlock-on-BounderLinkedQueue-tf2300852.html#a6394549
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

veryverbose (-vv)

2006-09-19 Thread Tim McConnell

I'm trying to debug some of my changes for G-1526 but am not getting the 
level of trace information I would expect. Is the VERYVERBOSE startup 
option (-vv) still the best option to use to get the most trace/debug 
output ?? Thanks.

[jira] Assigned: (GERONIMO-1404) Can't set server startup verbosity to INFO

2006-09-19 Thread Tim McConnell (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1404?page=all ]

Tim McConnell reassigned GERONIMO-1404:
---

Assignee: Tim McConnell

> Can't set server startup verbosity to INFO
> --
>
> Key: GERONIMO-1404
> URL: http://issues.apache.org/jira/browse/GERONIMO-1404
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 1.0
>Reporter: Sachin Patel
> Assigned To: Tim McConnell
>
> Starting the server with the verbosity option dones't work correctly.  
> Regardless of the value specified (-v or -vv), the verbosity is always DEBUG.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Goals for 1.2 - Thoughts

2006-09-19 Thread Bill Dudney


Hey Matt,

I'm all for this, we can do 1.1.2 if need be to fix outstanding bugs  
etc but leave the 1.1.x branch to be our 1.4 certified releases and  
trunk/1.2 can move towards the JEE 5 mark (which might be boiling the  
ocean :-)


TTFN,

-bd-

On Sep 19, 2006, at 11:56 AM, Matt Hogstrom wrote:


All,

I'm not sure I've seen this question asked directly so if I'm  
repeating please forgive me.


What if we focus 1.2 not on a release (certified release) but go to  
milestones, switch to J2SE 1.5 and focus on JEE 5.  This means that  
we make 1.1.1 our last 1.4 certified release.


I'd prefer this as we can focus on the next big goal and not try to  
boil the ocean.  Sacrilege ?



Matt Hogstrom
[EMAIL PROTECTED]

[jira] Commented: (GERONIMO-2406) Provide Dojo AJAX library as a native webapp

2006-09-19 Thread Paul McMahan (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2406?page=comments#action_12435952
 ] 

Paul McMahan commented on GERONIMO-2406:


Committed in rev 447903.  I created a dependency from the console 
configurations onto the new dojo-jetty and dojo-tomcat configurations so the 
console can reference Dojo at /dojo instead of introducing a private copy.

I'll keep this JIRA open for now for any followup work.

> Provide Dojo AJAX library as a native webapp
> 
>
> Key: GERONIMO-2406
> URL: http://issues.apache.org/jira/browse/GERONIMO-2406
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 1.2
>Reporter: Paul McMahan
> Assigned To: Paul McMahan
>
> Providing the dojo library as a native webapp in Geronimo has the following 
> benefits:
> -  allows applications to use the native library instead of making a copy in 
> each webapp
> -  makes browser caching better when multiple applications in the same server 
> use Dojo
> -  allows the Dojo library to be upgraded and managed separately from the 
> webapps that depend on it
> The proposal discussed on the dev list was to host the Dojo kitchen sink 
> build at the /dojo context.  See:
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200608.mbox/[EMAIL 
> PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Goals for 1.2 - Thoughts

2006-09-19 Thread Matt Hogstrom


All,

I'm not sure I've seen this question asked directly so if I'm  
repeating please forgive me.


What if we focus 1.2 not on a release (certified release) but go to  
milestones, switch to J2SE 1.5 and focus on JEE 5.  This means that  
we make 1.1.1 our last 1.4 certified release.


I'd prefer this as we can focus on the next big goal and not try to  
boil the ocean.  Sacrilege ?



Matt Hogstrom
[EMAIL PROTECTED]

Re: Dojo Toolkit inclusion to Geronimo

Paul,

It looks like you might be having the same problem that I initially had 
where my commits didn't show up on the geronimo-scm list (at least I 
haven't seen your referenced commit appear on the list yet).

You need to get somebody to add your apache id to the -allow list for 
[EMAIL PROTECTED]  Brett Porter helped me :-)

Joe

Paul McMahan wrote:

OK based on discussion here on the dev list and in GERONIMO-2333 I
just committed the code for GERONIMO-2406 into trunk rev 447903.  This
introduces the Dojo files as a new webapp into the server and creates
a dependency from the console onto this app so that Chris can
reference it from the JMX Debug portlet at /dojo instead of checking
in a private copy for the console.  When an application is deployed
into Geronimo and the console is already deployed it can use the
shared copy.  Otherwise it can install the Dojo webapp as a plugin --
AFAIK all the files are in place to generate the plugin I just have to
make sure that it gets out to a plugin repository, etc.

I will add a wiki page to describe all this.

This is my first commit while Geronimo has just gone back to CTR so I
hope I have not botched something up.  If I made any rookie mistakes
then please be gentle and I promise to fix it :-)

Best wishes,
Paul

On 9/13/06, Paul McMahan <[EMAIL PROTECTED]> wrote:

Gianny,  I agree that the JMX Viewer portlet Chris has contributed is
fantastic and more people should take a look at it!  I also agree that
we should think about how the Dojo files are checked in -- directly in
the console vs. as a separate module.  I was thinking about creating a
separate web app containing the Dojo files that could be shared across
all web apps in Geronimo and managed separately from them.  The thread
Chris referenced above discusses the idea in more detail:
http://www.mail-archive.com/dev@geronimo.apache.org/msg29777.html

Maybe the time is right to move forward on that idea (or some variant)
and let the JMX viewer portlet be the first exploiter.  Or if Chris'
current implementation is integrated as-is then we discussed
retrofitting it to work this way later -- see the comments in
GERONIMO-2333.

Best wishes,
Paul

On 9/13/06, Gianny Damour <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> The JMX Viewer portlet is finally working for me. Actually, it seems
> that due to a Dojo known issue, this portlet does not work with
> Safari :(; having said that, it works really nicely, and I really
> mean really nicely, with IE.
>
> Regarding your patch, I believe that this is a large piece of work;
> unfortunately, I cannot appreciate it as this is the first time that
> I am seeing dojo in action. Also, I think that instead of checking in
> the dojo files directly at the right location, we should check in a
> tar.ball of these files and expand it upon build of the module. I
> think that this is better because this way we do know which files are
> dojo specifics (this is a minor detail). What do you think?
>
> It would be cool if other people could have a look to this patch; for
> sure, it really deserves it!
>
> Thanks,
> Gianny
>

Re: Swing console?

2006-09-19 Thread Heinz Drews

Another aspect of the current approach is related to security.
The console in the default configuration runs on the standard http
port and uses just basic authentication. That's as reliable as the
promise of a politician.  It's a risk to expose G directly to a public
network but I don't like to run an apache server in front of it just
to protect console from external access.  Therefore either an non
webapp as admin function or an own special http server.

Heinz

On 9/19/06, Paul McMahan <[EMAIL PROTECTED]> wrote:

You raise an excellent point, which is that all that functionality in
the console doesn't do much good if the server won't start.  I also
really like your idea that the console should be able to run in a
server with a minimalistic configuration.  To me this is analogous to
booting an operating system in recovery mode so you can make repairs
using the console before rebooting in normal mode.  I think this could
be accomplished by providing a specialized config, say
var/config/minimal-config.xml, that would get loaded if you passed a
special flag to geronimo.sh.

The console is not currently implemented in such a way that would
allow this because it uses Geronimo's dependency system to gain the
level of access it needs to administer a module.  e.g. its deployment
plan has a dependency against geronimo-activemq-gbean so that it can
manage ActiveMQ.  As a result ActiveMQ needs to be running before the
console can start  But with all the excitement around Little G and
modularizing the server via plugins we've been talking about changing
this so that the console can manage incremental bits of function.  As
part of that effort I think that we definitely need to support the use
case you have brought to our attention -- recovery mode.

Best wishes,
Paul

On 9/19/06, Heinz Drews <[EMAIL PROTECTED]> wrote:
> Chris,
>
> I agree that with Ajax sufficient functionality can be provided in a webapp.
> My primary argument for a rich client would be as I have said before
> that a webapp requires a running server.  And what should be done if
> there are problems in the configuration which prevents that the server
> starts?
>
> The console webapp should at least run in a seperate server with
> minimalistic configuration.
> Something which I would prefer anyhow instead of the current situation in G.
>
> Heinz
>
> On 9/19/06, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:
> > I think this idea can be explored but we should give the current
> > initiative to include Ajax functionality to the console a shot first.
> > There's no doubt that rich clients have their advantages over web apps
> > (performance and sophisticated widgets to name a few) but I think we
> > have a potential in Ajax to close this gap. It would be nice to get more
> > comments on this. What do others think?
> >
> >
> > Jason Dillon wrote:
> > > Anyone have any thoughts on using Swing for the console... instead of
> > > a webapp (which are kinda evil IMO)... and then using webstart to
> > > serve it? Maybe using Netbeans (or that license not ASL friendly)?
> > > I've done some work with NB before at it would be very easy to create
> > > a rich user experience... and its easy to drop in new modules to
> > > support different aspects of administration and monitoring.
> > >
> > > I dunno.. just a thought...
> > >
> > > --jason
> > >
> >
> >
>

[jira] Commented: (GERONIMO-2409) Provide config/module aliasing ability

[ 
http://issues.apache.org/jira/browse/GERONIMO-2409?page=comments#action_12435942
 ] 

David Jencks commented on GERONIMO-2409:


I've committed in rev 447920 enough to get my experimental jee5 servers to 
start, by changing only the artifact resolution code.  I don't really see why 
it works yet: I expected we'd need similar code in Configuration and Kernel 
gbean lookup methods.  I'm leaving this open until we find out if more work is 
needed.



> Provide config/module aliasing ability
> --
>
> Key: GERONIMO-2409
> URL: http://issues.apache.org/jira/browse/GERONIMO-2409
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: core
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 1.2
>
> Attachments: GERONIMO-2409-v1.patch
>
>
> It's sort of impossible to swap a basic configuration such as transaction 
> with a substitute such as transaction-jta11: there are too many modules that 
> depend on it that all have to be rebuilt just because you changed one name.
> To fix this we need some way to substitute one module (configuration) for 
> another.  We might aim for a function-based registry rather than a name based 
> one, but that is more that I want to think about right now.
> I've done some simple experiments and it looks like some trivial changes in 
> DefaultArtifactResolver, the car maven plugin, and an additional properties 
> file in the server at least let you swap modules and get the server started.  
> I expected that changes in the kernel gbean lookups and Configuration gbean 
> lookups would be necessary as well, but I haven't needed them yet.
> I think the changes so far should be applied since they clarify the explicit 
> version resolution code and enable at least some module swapping.  I suspect 
> we'll find out soon if more work is needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Dojo Toolkit inclusion to Geronimo

OK based on discussion here on the dev list and in GERONIMO-2333 I
just committed the code for GERONIMO-2406 into trunk rev 447903.  This
introduces the Dojo files as a new webapp into the server and creates
a dependency from the console onto this app so that Chris can
reference it from the JMX Debug portlet at /dojo instead of checking
in a private copy for the console.  When an application is deployed
into Geronimo and the console is already deployed it can use the
shared copy.  Otherwise it can install the Dojo webapp as a plugin --
AFAIK all the files are in place to generate the plugin I just have to
make sure that it gets out to a plugin repository, etc.

I will add a wiki page to describe all this.

This is my first commit while Geronimo has just gone back to CTR so I
hope I have not botched something up.  If I made any rookie mistakes
then please be gentle and I promise to fix it :-)

Best wishes,
Paul

On 9/13/06, Paul McMahan <[EMAIL PROTECTED]> wrote:

Gianny,  I agree that the JMX Viewer portlet Chris has contributed is
fantastic and more people should take a look at it!  I also agree that
we should think about how the Dojo files are checked in -- directly in
the console vs. as a separate module.  I was thinking about creating a
separate web app containing the Dojo files that could be shared across
all web apps in Geronimo and managed separately from them.  The thread
Chris referenced above discusses the idea in more detail:
http://www.mail-archive.com/dev@geronimo.apache.org/msg29777.html

Maybe the time is right to move forward on that idea (or some variant)
and let the JMX viewer portlet be the first exploiter.  Or if Chris'
current implementation is integrated as-is then we discussed
retrofitting it to work this way later -- see the comments in
GERONIMO-2333.

Best wishes,
Paul

On 9/13/06, Gianny Damour <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> The JMX Viewer portlet is finally working for me. Actually, it seems
> that due to a Dojo known issue, this portlet does not work with
> Safari :(; having said that, it works really nicely, and I really
> mean really nicely, with IE.
>
> Regarding your patch, I believe that this is a large piece of work;
> unfortunately, I cannot appreciate it as this is the first time that
> I am seeing dojo in action. Also, I think that instead of checking in
> the dojo files directly at the right location, we should check in a
> tar.ball of these files and expand it upon build of the module. I
> think that this is better because this way we do know which files are
> dojo specifics (this is a minor detail). What do you think?
>
> It would be cool if other people could have a look to this patch; for
> sure, it really deserves it!
>
> Thanks,
> Gianny
>

[jira] Created: (GERONIMO-2417) Create a new framework assembly to be used as a fundamental Geronimo assembly building block

2006-09-19 Thread Joe Bohn (JIRA)

Create a new framework assembly to be used as a fundamental Geronimo assembly 
building block


 Key: GERONIMO-2417
 URL: http://issues.apache.org/jira/browse/GERONIMO-2417
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: general
Affects Versions: 1.2
Reporter: Joe Bohn
 Assigned To: Joe Bohn


It seems clear that the direction of Geronimo is to use the the modular 
framework and plugin capability to facilitate the creation of custom assemblies 
by users, third party solution distributors, etc... There are also issue 
with a proliferation of geronimo assemblies due to the dependence on either the 
tomcat or jetty based assemblies.  In order to address these issues we need a 
new, core assembly that can be the foundation of any other custom built 
assembly.   The minimal assemblies are a good start but the fact that there are 
two and they include the web containers makes not quite what we need for a 
strating point.   We need an assembly that includes just the fundamental 
infrastructure and enough capability to be used as a base for deploying plugins 
to create any of the existing assemblies or some entirely new custom assembly 
by a user of Geronimo.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-2416) ProxyMethodInterceptor should work with classes that have start,stop methods

ProxyMethodInterceptor should work with classes that have start,stop methods


 Key: GERONIMO-2416
 URL: http://issues.apache.org/jira/browse/GERONIMO-2416
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: kernel
Affects Versions: 1.2
Reporter: David Jencks
 Assigned To: Dain Sundstrom
Priority: Critical
 Fix For: 1.2


jetty6 components usually have lifecycle methods start,stop, and possibly 
others.  If we write a gbean extending these objects ProxyMethodInterceptor 
blows up with an ArrayIndexOutOfBoundsException (-1).  I don't understand why 
this happens, and there might be a different cause, but the gbeans that have 
this problem all extend jetty objects with start methods.

A really bad workaround that lets the server start is this patch:

Index: 
modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
===
--- 
modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
  (revision 447903)
+++ 
modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
  (working copy)
@@ -110,14 +110,29 @@
 invokers[getSuperIndex(proxyType, proxyType.getMethod("equals", 
new Class[]{Object.class}))] = new EqualsInvoke(kernel);
 invokers[getSuperIndex(proxyType, proxyType.getMethod("hashCode", 
null))] = new HashCodeInvoke();
 invokers[getSuperIndex(proxyType, proxyType.getMethod("toString", 
null))] = new ToStringInvoke(proxyType.getName());
-if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
-invokers[getSuperIndex(proxyType, 
proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
-invokers[getSuperIndex(proxyType, 
proxyType.getMethod("getStateInstance", null))] = new 
GetStateInstanceInvoke(kernel);
-invokers[getSuperIndex(proxyType, proxyType.getMethod("start", 
null))] = new StartInvoke(kernel);
-invokers[getSuperIndex(proxyType, 
proxyType.getMethod("startRecursive", null))] = new 
StartRecursiveInvoke(kernel);
-invokers[getSuperIndex(proxyType, proxyType.getMethod("stop", 
null))] = new StopInvoke(kernel);
-invokers[getSuperIndex(proxyType, 
proxyType.getMethod("getStartTime", null))] = new GetStartTimeInvoke(kernel);
-invokers[getSuperIndex(proxyType, 
proxyType.getMethod("getObjectName", null))] = new GetObjectNameInvoke(kernel);
+if (GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
+int superIndex;
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("getState", null))) > -1) {
+invokers[superIndex] = new GetStateInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("getStateInstance", null))) > -1) {
+invokers[superIndex] = new GetStateInstanceInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("start", null))) > -1) {
+invokers[superIndex] = new StartInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("startRecursive", null))) > -1) {
+invokers[superIndex] = new StartRecursiveInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("stop", null))) > -1) {
+invokers[superIndex] = new StopInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("getStartTime", null))) > -1) {
+invokers[superIndex] = new GetStartTimeInvoke(kernel);
+}
+if ((superIndex = getSuperIndex(proxyType, 
proxyType.getMethod("getObjectName", null))) > -1) {
+invokers[superIndex] = new GetObjectNameInvoke(kernel);
+}
 }
 } catch (Exception e) {
 // this can not happen... all classes must implement equals, 
hashCode and toString

Dain, do you have any clues why this is happening?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2415) TestSupport should support xmlbeans tests

 [ http://issues.apache.org/jira/browse/GERONIMO-2415?page=all ]

David Jencks updated GERONIMO-2415:
---

Attachment: GERONIMO-2415.patch

Here's the class I want to add with the pom mods that work for me.  Don't know 
if there are better scopes for the additional dependencies.

> TestSupport should support xmlbeans tests
> -
>
> Key: GERONIMO-2415
> URL: http://issues.apache.org/jira/browse/GERONIMO-2415
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: Jason Dillon
> Fix For: 1.2
>
> Attachments: GERONIMO-2415.patch
>
>
> There are a bunch of tests of xmlbeans functionality scattered through the 
> code that all have copies of a compare method.  I'd like to move this to a 
> testsupport-common class.  This involves dragging xmlbeans into all modules 
> test dependencies.  Would it be better to create another module for this 
> class?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-2415) TestSupport should support xmlbeans tests

TestSupport should support xmlbeans tests
-

 Key: GERONIMO-2415
 URL: http://issues.apache.org/jira/browse/GERONIMO-2415
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: buildsystem
Affects Versions: 1.2
Reporter: David Jencks
 Assigned To: Jason Dillon
 Fix For: 1.2


There are a bunch of tests of xmlbeans functionality scattered through the code 
that all have copies of a compare method.  I'd like to move this to a 
testsupport-common class.  This involves dragging xmlbeans into all modules 
test dependencies.  Would it be better to create another module for this class?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-2414) SchemaConversionUtils should have only generic code: individual builders should have specific code

SchemaConversionUtils should have only generic code: individual builders should 
have specific code
--

 Key: GERONIMO-2414
 URL: http://issues.apache.org/jira/browse/GERONIMO-2414
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.2


SchemaConversionUtils has a lot of j2ee 1.4 specific methods such as 
ConvertToServletSchema that reference the xmlbeans generated classes for j2ee 
1.4.  These should be moved into  the j2ee 1.4 builders, and appropriate 
similar methods included in jee5 builders.  SchemaConversionUtils should have 
only parameterized-for-ee-version generic methods and geronimo-specific methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Is JIRA for sandbox'ed and branch'ed code? (was Re: [jira] Created: (GERONIMO-2407) openwire impl in gcache won't compile)



On Sep 18, 2006, at 10:59 PM, Jacek Laskowski wrote:


On 9/15/06, David Jencks <[EMAIL PROTECTED]> wrote:

Jacek,

This use seems completely appropriate to me. Bill is supplying a
patch against some code that he cant commit against himself.  Where
else could he put the patch?  Among other advantages, using jira
gives him the opportunity to explicitly authorize apache (or the
geronimo committers) to apply the patch... if he used the mailing
list it would not be so clear IMO.


Whenever I think about our tools we can use to help in development
process I try to see their final results. In this case - would it ever
become part of RELEASE NOTES that's generated from JIRA? It would not
if gcache never did its way to the trunk, would it? I think JIRA is
not meant for sandbox'ed code. JIRA messages may mislead easily that
gcache is already on trunk. On the other hand, it bothers me that we
can't provide anything better to help non-committers contribute to it.


Not having tried to write release notes :-) I'm not sure what  
problems show up, but certainly not everything in JIRA goes into  
every release notes: the issues have to be filtered by branches/ 
version.  So as long as JIRAs for sandbox stuff don't have a release  
version number associated with them they shouldn't get into any  
release notes.  Maybe along with "Wish List" we should have "Sandbox"?


thanks
david jencks


I'm not convinced with JIRA and gcache playing together, but don't
have anything better to advocate. Eh, I'll have to get used to it.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: SUM: Re: Changing the name of the ServiceMix project at the Codehaus

2006-09-19 Thread [EMAIL PROTECTED]

Hej Bruce,

bsnyder wrote:
> 
>> Could you please sketch the scope/content of the future codehaus project
>> space in a few sentences?
> There is no predefined scope. The project at the Codehaus is only used
> to house addtions Apache ServiceMix that are not compatible with the
> Apache License. Just as with Apache ServiceMix, anyone can contribute.
> 

then IMHO "BeyondServiceMix" (4 results, with space 9k) and "MixDepot" (50k
results) are best as they fulfill the posted requirements AND describe that
anything related to ServiceMix may be placed in the codehaus project. For
the first one: Is this already an "illegal" use of the name ServiceMix?

my 2 cents
Georg

-- 
View this message in context: 
http://www.nabble.com/Changing-the-name-of-the-ServiceMix-project-at-the-Codehaus-tf2203136.html#a6391846
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: build failure

Correction ... the failure is actually on "bootstrap modules" ... not 
openejb2 (that was what I was building on another machine while typing 
the note :-) ).

Joe

Joe Bohn wrote:

I think the difference might be when you did a bootstrap clean build.

I'm hitting the same problem as Manu after I decided that I needed to 
clean out my repo and run the bootstrap again.  Until then I was running 
fine with the latest source and only doing mvn install or mvn clean 
install.  However, after cleaning out the repo I can't get openejb2 to 
build successfully due to the tranql dependency (seems strange that 
we're looking for a 1.0-SNAPSHOT version of tranql-parent).

Joe

Vamsavardhana Reddy wrote:

Manu,

I followed the steps from wiki page.  Initially I ran into some 
problems with JAVA_HOME variable etc.  I have now set it to the SUN 
JDK.  I do not know if this variable has any relevance here, but take 
no chances.  I have run bootstrap in steps.  I could not get the build 
going fine within the first attempt.  The last bootstrap I ran was 
"bootstrap minimal".  Afterwards it is working fine for me.  Now I run 
"mvn -o install"  and if there are any failures, I run w/o -o.

Regards,
Vamsi

On 9/19/06, *Manu George* <[EMAIL PROTECTED] 
> wrote:

Hi Vamsi/Lasantha,
  I am having the latest revision(447787). I followed the
steps in the wiki and did a build by separately calling
   1.  bootstrap clean
   2. bootstrap specs
   3. bootstrap modules
   4. bootstrap openejb2
   5. bootstrap assemble

My sources are in C:\g\trunk. bootstrap assemble fails and then gives
the build successful message as I have shown. I used Sun JDK 1.4.2_12
for building and 1.5 for building specs.
I am doing the m2 build for the first time. Any idea on what may be
going wrong? Did you follow the same steps as in wiki or different
ones? I am aware of the changes Vamsi made but are you also following
different steps Lasantha?

Thanks
Manu

On 9/19/06, Lasantha Ranaweera <[EMAIL PROTECTED]
> wrote:
 > Yes I agree with Vamsi. It works correctly for me too with
reversion 447778.
 >
 > Vamsavardhana Reddy wrote:
 > > Hi Manu,
 > >
 > > I did an svn update on the trunk and then ran a build.  The
build was
 > > successful.  Are you sure you have the latest source files?
 > >
 > > Regards,
 > > Vamsi
 > >
 > > On 9/19/06, *Manu George* < [EMAIL PROTECTED]

 > > mailto:[EMAIL PROTECTED]>>> wrote:
 > >
 > > Hi,
 > >When i am building the trunk using Maven 2 I am 
getting the

 > > following error.
 > > Also even though the build is failing it says build
successful. I get
 > > this when I run bootstrap assemble. The preceding steps all
showed
 > > build successful
 > >
 > > Downloading:
 > >
http://people.apache.org/repo/m1-snapshot-repository/org.tranql/pom

 > > s/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
 > > apache-snapshots-m1 ( http://peo
 > > ple.apache.org/repo/m1-snapshot-repository

 > > < http://ple.apache.org/repo/m1-snapshot-repository>)
 > > Downloading:
 > >
http://people.apache.org/repo/m2-snapshot-repository/org/tranql/tra

 > > nql-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
apache-snapshots
 > > ( http://people
 > > .apache.org/repo/m2-snapshot-repository)
 > > Downloading:
 > >
http://snapshots.repository.codehaus.org/org/tranql/tranql-parent/1

 > > .0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
 > > codehaus-snapshots ( http://snap < http://snap>
 > > shots.repository.codehaus.org
 <
http://shots.repository.codehaus.org>)
 > > Downloading:
 > >
http://people.apache.org/maven-snapshot-repository/org/tranql/tranq

 > > <
http://people.apache.org/maven-snapshot-repository/org/tranql/tranq>
 > > l-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
apache.snapshots
 > > (http://people
 > > .apache.org/maven-snapshot-repository)
 > > [INFO]
 > >

 > >
 > > [ERROR] BUILD ERROR

Re: build failure

I think the difference might be when you did a bootstrap clean build.

I'm hitting the same problem as Manu after I decided that I needed to 
clean out my repo and run the bootstrap again.  Until then I was running 
fine with the latest source and only doing mvn install or mvn clean 
install.  However, after cleaning out the repo I can't get openejb2 to 
build successfully due to the tranql dependency (seems strange that 
we're looking for a 1.0-SNAPSHOT version of tranql-parent).

Joe

Vamsavardhana Reddy wrote:

Manu,

I followed the steps from wiki page.  Initially I ran into some problems 
with JAVA_HOME variable etc.  I have now set it to the SUN JDK.  I do 
not know if this variable has any relevance here, but take no chances.  
I have run bootstrap in steps.  I could not get the build going fine 
within the first attempt.  The last bootstrap I ran was "bootstrap 
minimal".  Afterwards it is working fine for me.  Now I run "mvn -o 
install"  and if there are any failures, I run w/o -o.

Regards,
Vamsi

On 9/19/06, *Manu George* <[EMAIL PROTECTED] 
> wrote:

Hi Vamsi/Lasantha,
  I am having the latest revision(447787). I followed the
steps in the wiki and did a build by separately calling
   1.  bootstrap clean
   2. bootstrap specs
   3. bootstrap modules
   4. bootstrap openejb2
   5. bootstrap assemble

My sources are in C:\g\trunk. bootstrap assemble fails and then gives
the build successful message as I have shown. I used Sun JDK 1.4.2_12
for building and 1.5 for building specs.
I am doing the m2 build for the first time. Any idea on what may be
going wrong? Did you follow the same steps as in wiki or different
ones? I am aware of the changes Vamsi made but are you also following
different steps Lasantha?

Thanks
Manu

On 9/19/06, Lasantha Ranaweera <[EMAIL PROTECTED]
> wrote:
 > Yes I agree with Vamsi. It works correctly for me too with
reversion 447778.
 >
 > Vamsavardhana Reddy wrote:
 > > Hi Manu,
 > >
 > > I did an svn update on the trunk and then ran a build.  The
build was
 > > successful.  Are you sure you have the latest source files?
 > >
 > > Regards,
 > > Vamsi
 > >
 > > On 9/19/06, *Manu George* < [EMAIL PROTECTED]

 > > mailto:[EMAIL PROTECTED]>>> wrote:
 > >
 > > Hi,
 > >When i am building the trunk using Maven 2 I am getting the
 > > following error.
 > > Also even though the build is failing it says build
successful. I get
 > > this when I run bootstrap assemble. The preceding steps all
showed
 > > build successful
 > >
 > > Downloading:
 > >
http://people.apache.org/repo/m1-snapshot-repository/org.tranql/pom

 > > s/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
 > > apache-snapshots-m1 ( http://peo
 > > ple.apache.org/repo/m1-snapshot-repository

 > > < http://ple.apache.org/repo/m1-snapshot-repository>)
 > > Downloading:
 > >
http://people.apache.org/repo/m2-snapshot-repository/org/tranql/tra

 > > nql-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
apache-snapshots
 > > ( http://people
 > > .apache.org/repo/m2-snapshot-repository)
 > > Downloading:
 > >
http://snapshots.repository.codehaus.org/org/tranql/tranql-parent/1

 > > .0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
 > > codehaus-snapshots ( http://snap < http://snap>
 > > shots.repository.codehaus.org
 <
http://shots.repository.codehaus.org>)
 > > Downloading:
 > >
http://people.apache.org/maven-snapshot-repository/org/tranql/tranq

 > > <
http://people.apache.org/maven-snapshot-repository/org/tranql/tranq>
 > > l-parent/1.0-SNAPSHOT/tranql-parent-1.0-SNAPSHOT.pom
 > > [WARNING] Unable to get resource from repository
apache.snapshots
 > > (http://people
 > > .apache.org/maven-snapshot-repository)
 > > [INFO]
 > >

 > >
 > > [ERROR] BUILD ERROR
 > > [INFO]
 > >

 > > [INFO] Failed to resolve artifact.
 > > GroupId: org.tr

Re: Let us please use a JIRA for every code change we make

2006-09-19 Thread Prasad Kashyap

Kevan, Jason, Blevins, et al,

Thanks for your constructive feedback and comments. You are right. The
issue is not about the type of changes Jason mentioned. Those don't
warrant a JIRA. Jason recently strenghtened the protection and privacy
on some methods. It would be ridiculous to expect him to file a JIRA
for it. Moreover, I come from a work culture where EVERY single change
had to  go thro' a JIRA and I have bitched, moaned and complained
about it. So this to me is manna.

I am more concerned about having a ready link between a change and
it's relevant discussion. How do we maintain it ? Would people have to
take the trouble of googling the  archives to search for the relevant
discussion ? This is kinda tangential to the discussion on the other
thread about having javadocs.

Going thro' subversion history doesn't necessarily provide this link.
Not all changes have the required, appropriate comments.

Next,  are there any guidelines about when to create JIRAs and when
one can get by without ?

Thanx
Prasad

On 9/19/06, Kevan Miller <[EMAIL PROTECTED]> wrote:

On Sep 19, 2006, at 6:57 AM, Jason Dillon wrote:

> There are always small changes that are not directly tied to a
> specific JIRA issue.  My point is that by making it a requirement
> to have a JIRA issue that people will end up creating more issues
> than we really nee (or want).
>
> I have made a lot of small changes to the build which fit into this
> category.  Some clean up also fits into that category.  Say, adding
> or fixing javadocs, or adding TODO comments, etc... all things
> which probably don't have a JIRA issue and it would be a PITA to
> force folks to go an make one.  That is way to artificial and
> pointless.

I agree with Jason. There are instances (and Jason's mentioned a few)
where generating a Jira ends up producing noise to the community and
extra work for the developer, without delivering any additional
benefit to the community.

Prasad,
Perhaps you can be a little more explicit about the problem and we
can work our way to a solution?

I doubt that the types of changes referenced by Jason are the types
of changes that you're seeing a problem with... Perhaps you can
discuss the problem a bit more specifically? Are you seeing instances
where larger functional enhancements/commits aren't referencing Jira/
discussion?

I'm guessing that you are seeing commits for significant functional
enhancements for which a Jira was not created (and thus not
referenced in the commit message). If this is your issue, then I
think we can find a reasonable solution which the community will
agree with...

--kevan

[jira] Created: (SM-584) Servicemix archive for Jboss

2006-09-19 Thread Eric Dofonsou (JIRA)

Servicemix archive for Jboss


 Key: SM-584
 URL: https://issues.apache.org/activemq/browse/SM-584
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core, servicemix-http
Affects Versions: 3.0
 Environment: All environement
Reporter: Eric Dofonsou


I've found the following issue with the way servicemix works in JBOSS.

I'am building endpoints that uses the servicemix-http component.

For this to work I need to add these two files to the 
$JBOSS_HOME/server/default/lib folder :
1- geronimo-j2ee-management_1.0_spec-1.0.1.jar
2- commons-httpclient-3.0.jar

The geronimo-j2ee-management jar is required by the .sar file (Should this not 
be included in the sar archive ?)

The Common-httpclient is required by the servicemix-http module (however there 
is an older version of this lib included with JBoss).  So for this too work we 
have to delete the old version and replace it with this version.  The ideal 
work around would be to include a jboss-web.xml file that specifies to jboss 
that we want to use our versino of common-httpclient for this application.

Here is the content of the jboss-web.xml file that should be included in the 
servicemix-http-*-zip service assembly file (should be in the META-INF folder) :
-

  

  org.apache.commons.httpclient:loader=commons-httpclient-3.0.jar

  

--- 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Jboss and servicemix.

2006-09-19 Thread Eric Dofonsou


DONE with a description for the solution : 
https://issues.apache.org/activemq/browse/SM-584



gnodet wrote:
> 
> Please raise a JIRA and attach your patch.
> Thanks for looking at this issue.
> 
> On 9/18/06, Eric Dofonsou <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> I've found the following issue with the way servicemix works in JBOS.
>>
>> I'am building endpoints that use the ervicemix-http component.
>>
>> For this to work I need to add these two files to the
>> $JBOSS_HOME/server/default/lib folder :
>> 1- geronimo-j2ee-management_1.0_spec-1.0.1.jar
>> 2- commons-httpclient-3.0.jar
>>
>> The geronimo-j2ee-management jar is required by the .sar file (Should
>> this
>> not be included in the sar archive ?)
>>
>> The Common-httpclient is required by the servicemix-http module (however
>> there is an older version of this lib included with JBoss).  So for this
>> too
>> work we have to delete the old version and replace it with this version.
>> The ideal work around would be to include a jboss-web.xml file that
>> specifies to jboss that we want to use our versino of common-httpclient
>> for
>> this application.
>>
>> Can this be done ?  Ican includ an extract of the jboss-web.xml file
>> justin
>> case.
>> --
>> View this message in context:
>> http://www.nabble.com/Jboss-and-servicemix.-tf2293019.html#a6369481
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Jboss-and-servicemix.-tf2293019.html#a6388532
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: Swing console?

2006-09-19 Thread Andrus Adamchik

Agreed. Aside from the UI aspect, managing a server from within the  
server process is limited by definition. Ideally there should be a  
rich client and some kind of server-side daemon that can bounce the  
server process and provide access to configuration when the server is  
down.

One other advantage would be an ability to manage multiple instances  
of Geronimo from the single console. From the recent experience the  
lack of this capability is the single biggest concern in migrating to  
Geronimo from commercial app servers.

Andrus

On Sep 19, 2006, at 2:30 AM, Heinz Drews wrote:

Chris,

I agree that with Ajax sufficient functionality can be provided in  
a webapp.

My primary argument for a rich client would be as I have said before
that a webapp requires a running server.  And what should be done if
there are problems in the configuration which prevents that the server
starts?

The console webapp should at least run in a seperate server with
minimalistic configuration.
Something which I would prefer anyhow instead of the current  
situation in G.

Heinz

On 9/19/06, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:

I think this idea can be explored but we should give the current
initiative to include Ajax functionality to the console a shot first.
There's no doubt that rich clients have their advantages over web  
apps

(performance and sophisticated widgets to name a few) but I think we
have a potential in Ajax to close this gap. It would be nice to  
get more

comments on this. What do others think?

Jason Dillon wrote:
> Anyone have any thoughts on using Swing for the console...  
instead of

> a webapp (which are kinda evil IMO)... and then using webstart to
> serve it? Maybe using Netbeans (or that license not ASL friendly)?
> I've done some work with NB before at it would be very easy to  
create

> a rich user experience... and its easy to drop in new modules to
> support different aspects of administration and monitoring.
>
> I dunno.. just a thought...
>
> --jason
>

Re: Swing console?

You raise an excellent point, which is that all that functionality in
the console doesn't do much good if the server won't start.  I also
really like your idea that the console should be able to run in a
server with a minimalistic configuration.  To me this is analogous to
booting an operating system in recovery mode so you can make repairs
using the console before rebooting in normal mode.  I think this could
be accomplished by providing a specialized config, say
var/config/minimal-config.xml, that would get loaded if you passed a
special flag to geronimo.sh.

The console is not currently implemented in such a way that would
allow this because it uses Geronimo's dependency system to gain the
level of access it needs to administer a module.  e.g. its deployment
plan has a dependency against geronimo-activemq-gbean so that it can
manage ActiveMQ.  As a result ActiveMQ needs to be running before the
console can start  But with all the excitement around Little G and
modularizing the server via plugins we've been talking about changing
this so that the console can manage incremental bits of function.  As
part of that effort I think that we definitely need to support the use
case you have brought to our attention -- recovery mode.

Best wishes,
Paul

On 9/19/06, Heinz Drews <[EMAIL PROTECTED]> wrote:

Chris,

I agree that with Ajax sufficient functionality can be provided in a webapp.
My primary argument for a rich client would be as I have said before
that a webapp requires a running server.  And what should be done if
there are problems in the configuration which prevents that the server
starts?

The console webapp should at least run in a seperate server with
minimalistic configuration.
Something which I would prefer anyhow instead of the current situation in G.

Heinz

On 9/19/06, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:
> I think this idea can be explored but we should give the current
> initiative to include Ajax functionality to the console a shot first.
> There's no doubt that rich clients have their advantages over web apps
> (performance and sophisticated widgets to name a few) but I think we
> have a potential in Ajax to close this gap. It would be nice to get more
> comments on this. What do others think?
>
>
> Jason Dillon wrote:
> > Anyone have any thoughts on using Swing for the console... instead of
> > a webapp (which are kinda evil IMO)... and then using webstart to
> > serve it? Maybe using Netbeans (or that license not ASL friendly)?
> > I've done some work with NB before at it would be very easy to create
> > a rich user experience... and its easy to drop in new modules to
> > support different aspects of administration and monitoring.
> >
> > I dunno.. just a thought...
> >
> > --jason
> >
>
>

Re: Jboss and servicemix.

2006-09-19 Thread Eric Dofonsou



To fix this you just have to include a jboss-web.xml (in thte META-INF
fodler) file like the one below, 

-

  

  org.apache.commons.httpclient:loader=commons-httpclient-3.0.jar 

  

---


The j2ee management  dependy was not added in my .sar file however.

I've created and tested the two archives and they work well

I will open a JIRA.  and the solution.



gnodet wrote:
> 
> Bruce, these dependencies are already added and deployed but they
> conflict with the existing ones shipped with JBoss.
> I have already seen that problem but had no time to understand
> how to tweak the JBoss classloader to workaround that.
> 
> Jboss ships commons-http v2.x and ServiceMix uses v3.0.
> Unfortunately, these versions are slightly incompatible...
> 
> On 9/18/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
>> On 9/18/06, Eric Dofonsou <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > I've found the following issue with the way servicemix works in JBOS.
>> >
>> > I'am building endpoints that use the ervicemix-http component.
>> >
>> > For this to work I need to add these two files to the
>> > $JBOSS_HOME/server/default/lib folder :
>> > 1- geronimo-j2ee-management_1.0_spec-1.0.1.jar
>> > 2- commons-httpclient-3.0.jar
>> >
>> > The geronimo-j2ee-management jar is required by the .sar file (Should
>> this
>> > not be included in the sar archive ?)
>> >
>> > The Common-httpclient is required by the servicemix-http module
>> (however
>> > there is an older version of this lib included with JBoss).  So for
>> this too
>> > work we have to delete the old version and replace it with this
>> version.
>> > The ideal work around would be to include a jboss-web.xml file that
>> > specifies to jboss that we want to use our versino of common-httpclient
>> for
>> > this application.
>> >
>> > Can this be done ?  Ican includ an extract of the jboss-web.xml file
>> justin
>> > case.
>>
>> Can these additional dependencies be added to the service assembly to
>> be deployed with it?
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E> );'
>>
>> Apache Geronimo - http://geronimo.apache.org/
>> Apache ActiveMQ - http://incubator.apache.org/activemq/
>> Apache ServiceMix - http://incubator.apache.org/servicemix/
>> Castor - http://castor.org/
>>
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Jboss-and-servicemix.-tf2293019.html#a6388262
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: Swing console?

I think that moving to a swing based console at this point in time would 
be the wrong move.   As Chris and Paul have mentioned, Ajax and other 
technologies are moving toward closing the function/usability gap for 
web based applications.  A web based console provides greater 
flexibility for administration from various device types in the future. 
   And rich clients introduce another whole set of client issues that 
we then have to consider.  Technologies like JWS do help with the 
install/mgmt of the clients but don't address other client side issues 
such as verification on multiple (sometimes obscure) platforms, JRE 
versions on the client, hardware requirements, etc...

I agree with the exposure that Heinz has pointed out of running the 
admin console on the same platform that it is managing.  However I think 
we need to view the admin console within the complete context of 
Geronimo.  The console is a great usability enhancement in managing 
Geronimo and for most users is the primary way that they will manage 
Geronimo.  However, it is not (and should not) be the only management 
tool.  Anything that is possible with the web console should also be 
possible (but not necessarily as easy) via some some other means.

It would be good if we could insulate the console further from the 
server (possibly running it on it's own minimal configuration as Greg 
mentioned) but we need to consider the server cost/benefit trade-off any 
such choices.

Joe

Heinz Drews wrote:

Chris,

I agree that with Ajax sufficient functionality can be provided in a 
webapp.

My primary argument for a rich client would be as I have said before
that a webapp requires a running server.  And what should be done if
there are problems in the configuration which prevents that the server
starts?

The console webapp should at least run in a seperate server with
minimalistic configuration.
Something which I would prefer anyhow instead of the current situation 
in G.

Heinz

On 9/19/06, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:

I think this idea can be explored but we should give the current
initiative to include Ajax functionality to the console a shot first.
There's no doubt that rich clients have their advantages over web apps
(performance and sophisticated widgets to name a few) but I think we
have a potential in Ajax to close this gap. It would be nice to get more
comments on this. What do others think?

Jason Dillon wrote:
> Anyone have any thoughts on using Swing for the console... instead of
> a webapp (which are kinda evil IMO)... and then using webstart to
> serve it? Maybe using Netbeans (or that license not ASL friendly)?
> I've done some work with NB before at it would be very easy to create
> a rich user experience... and its easy to drop in new modules to
> support different aspects of administration and monitoring.
>
> I dunno.. just a thought...
>
> --jason
>

[jira] Created: (SM-583) Jetty context Path verification

2006-09-19 Thread Charles Souillard (JIRA)

Jetty context Path verification
---

 Key: SM-583
 URL: https://issues.apache.org/activemq/browse/SM-583
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-http
Affects Versions: incubation
 Environment: Linux, jdk 1.5 sun
Reporter: Charles Souillard


i am using sm build from 2006/09/12.
I am trying to deploy 2 SUs in sm-http.

the first one has the following path :
locationURI="http://localhost:8192/junit_HttpEndpoint_invokeUtilTester";

the second :
locationURI="http://localhost:8192/junit_HttpEndpoint_invoke";

I get the following exception :
The requested context for path '/junit_HttpEndpoint_invoke' overlaps
with an existing context for path: '/junit_HttpEndpoint_invokeUtilTester'

I had a look at the code in
org.apache.servicemix.http.jetty.JettyContextManager at line 138 (the
method where is thrown the exception) and I found very strange the
following test :

if (h.getContextPath().startsWith(path) ||
path.startsWith(h.getContextPath())) {
  throw new Exception("The requested context for path '" + path + "'
overlaps with an existing context for path: '" + h.getContextPath() + "'");
}

h is a handler which represents an already deployed path
(/junit_HttpEndpoint_invokeUtilTester).
path is the current path (being deployed = /junit_HttpEndpoint_invoke)

The exception is thrown as  the following is true I think   :
h.getContextPath().startsWith(path)

I can deploy another su having the following path without any error:
/junit_HttpEndpoint_incrementService

This let me thinking that there could have a matching region but one
could not be completely included in another...

PATCH : 

replace 
if (h.getContextPath().startsWith(path) ||
path.startsWith(h.getContextPath())) {

by 

if (h.getContextPath().equals(path)) {

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Writing Readable Code

2006-09-19 Thread anita kulshreshtha

 I have read a lot of code and found that the code is
understandable enough. However I found it was hard to get an overall
picture. 
   I agree with Kevan that "When a  method is a part of an overall
larger picture, pulling that context  together can be extremely useful
to the reader". Matt suggested that "for the person who is looking at
the code six months from now it might be nice to have part of that
discussion on the dev list condensed into the code in the form of a
comment". IMHO, it would be better to put this condensed discussion in
the Jira issue that was used to commit the code. The code should have a
link to this issue. We should make sure that this informal design
document includes all the explanations/issues raised by the community
but still be high level enough to be not affected by minor tweaks in
the implementation. A finished document for the wiki is even better but
not required.
   Other than this I agree with Paul that " low bar for committing to
trunk should be that it compiles, does no harm, and has undergone
adequate discussion within the Dev community.  Providing adequate
comments lies just outside that threshold as something that you should
expect to be nagged heavily about but not necessarily vetoed."

Thanks
Anita

--- Kevan Miller <[EMAIL PROTECTED]> wrote:

> During the recent discussions regarding the Geronimo Development  
> process, several people expressed some concern about moving away from
>  
> RTC.  The biggest issue seemed to be that RTC insured multiple people
>  
> reviewed new code. Having reviewed the code, the reviewers now  
> understood and would be able to support the code (i.e. fix bugs).
> 
> This is certainly a valid concern. However, even though we're now  
> following CTR, we all need to be making a concerted effort to provide
>  
> the same level of review as commits are made.
> 
> No matter what process we're following, IMO, the best way to insure  
> that people are reading *and* understanding your code is to write  
> code that is easy to read and understand. This does not mean writing 
> 
> simple code. It simply means keeping the reader in mind and trying to
>  
> make their job easier.
> 
> The single, most important thing, in my mind, is to provide clear and
>  
> insightful comments to assist the reader. These don't need to be  
> verbose tomes. They don't need to state the obvious. However, any  
> assistance you can provide the reader is helpful. Describe the  
> processing flow that methods are being invoked. What are the  
> threading assumptions? Identify subtleties that a reader might not be
>  
> aware of. Who are the potential callers? etc...
> 
> In case anyone is wondering -- I think we've been lacking in this  
> department. I'd like to see simple comment guidelines incorporated  
> into the Documentation Guidelines for our CTR process.
> 
> In my opinion, failure to appropriately comment new code is cause for
>  
> a commit to be vetoed. I doubt that this will happen often. I expect 
> 
> that in most instances these issues can be resolved appropriately  
> through simple discussion. Some basic rules-of-thumb are likely to  
> help resolve any issues.
> 
> What do others think?
> 
> Specific ideas on comment guidelines? Javadoc-style comments for
> APIs/ 
> SPIs, etc? What types of comments should be expected?
> 
> --kevan
>   
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

XML-Schema

2006-09-19 Thread Kanchana Welagedara


Hi All

XML shcema and deployment plans documentation is now available for the
followings

* geronimo-application-1.1.xsd
* geronimo-application-client-1.1.xsd
* geronimo-connector-1.1.xsd
* geronimo-web-1.1.xsd
* openejb-jar-2.1.xsd

at

http://cwiki.apache.org/confluence/display/GMOxDOC11/XML+schemas

Considering the user feed back we hope to improve the look and feel of
the documentation.In early stage we have already got few users feed
back and will improve the documentation accordingly. Your comments are
very welcome.

Regards
Kanchana

Re: Board Report - Comments please

2006-09-19 Thread John Sisson


Moved Geronimo's Wiki from Moin Moin to Confluence.

Inter-project relationship status:
* Yoko (CORBA orb) integration work in Geronimo under way.
* Changed Geronimo trunk build to maven 2.
* Future versions of Geronimo (2.x) will use the ActiveMQ and OpenEJB 
projects currently in the incubator instead of the versions of these 
projects from Codehaus.


John

Matt Hogstrom wrote:

Hi everyone,

We have a board report due and it appears that the RoUS is a tad busy 
at the moment.  I pulled the following from STATUS and added my 
recollections and musings.  Please add your comments to this thread 
and I'll happily roll them up into a big bushel of information to the 
board.  We need to get this pulled together for Wednesday morning.


Thanks!

This report is for the last two months (let's say August  - September):

*Community*
- Voted in 1 new committer which brings us to 32 committers
- Voted in 7 new PMC members.  PMC currently at 19 members
- Community voted to return to CTR from RTC starting on September 18th

*Releases*
Geronimo - Version 1.1.1 was approved for release and the jars were 
made available on Monday, September 18th.

Xbean
Devtools
DayTrader - Version 1.1.1 is ready to start the release process.  It 
includes minor tweaks and a few bug fixes.  Nothing major.


*Development*
Geronimo
- Dain and Alan were voted in as release managers for 1.2.
- Content being defined by the community.

Xbean

DayTrader
- Bug fixes for 1.1.1.
- Some POCs on new Ajax interfaces

DevTools

*Other Stuff*


Matt Hogstrom
[EMAIL PROTECTED]

Re: Let us please use a JIRA for every code change we make

2006-09-19 Thread Sachin Patel

-1On Sep 18, 2006, at 2:03 PM, Prasad Kashyap wrote:As we move back towards CTR, can we please adopt the practice of usinga JIRA for every code change we make, however small the code changemay be.Since we have assumed the responsibility of providing gooddocumentation/discussion with all code changes, a JIRA provides thatcrucial link between a particular change and it's open discussion.Some use the JIRA comments for discussion. JIRA comments are goodenough for small minor changes. For most others, it is the dev-list.If the discussion is held on the dev-list, the JIRA should mention thelink to that discussion's archive page. Use your favorite archivesite.http://www.mail-archive.com/dev@geronimo.apache.org/http://mail-archives.apache.org/mod_mbox/geronimo-dev/http://www.nabble.com/Apache-Geronimo---Dev-f136.htmlAnd then, as you commit the changes, please mention the appropriateJIRA under which the code was being changed.For posterity sake, this will ensure that a link to the discussion isis always available for any change that went into the file.Please feel free to correct, modify or suggest better methods to keep this link.ThanxPrasad  -sachin

Re: Let us please use a JIRA for every code change we make

2006-09-19 Thread Kevan Miller



On Sep 19, 2006, at 6:57 AM, Jason Dillon wrote:

There are always small changes that are not directly tied to a  
specific JIRA issue.  My point is that by making it a requirement  
to have a JIRA issue that people will end up creating more issues  
than we really nee (or want).


I have made a lot of small changes to the build which fit into this  
category.  Some clean up also fits into that category.  Say, adding  
or fixing javadocs, or adding TODO comments, etc... all things  
which probably don't have a JIRA issue and it would be a PITA to  
force folks to go an make one.  That is way to artificial and  
pointless.


I agree with Jason. There are instances (and Jason's mentioned a few)  
where generating a Jira ends up producing noise to the community and  
extra work for the developer, without delivering any additional  
benefit to the community.


Prasad,
Perhaps you can be a little more explicit about the problem and we  
can work our way to a solution?


I doubt that the types of changes referenced by Jason are the types  
of changes that you're seeing a problem with... Perhaps you can  
discuss the problem a bit more specifically? Are you seeing instances  
where larger functional enhancements/commits aren't referencing Jira/ 
discussion?


I'm guessing that you are seeing commits for significant functional  
enhancements for which a Jira was not created (and thus not  
referenced in the commit message). If this is your issue, then I  
think we can find a reasonable solution which the community will  
agree with...


--kevan

Re: Board Report - Comments please

2006-09-19 Thread Kevan Miller



On Sep 18, 2006, at 10:46 PM, Matt Hogstrom wrote:


Hi everyone,

We have a board report due and it appears that the RoUS is a tad  
busy at the moment.  I pulled the following from STATUS and added  
my recollections and musings.  Please add your comments to this  
thread and I'll happily roll them up into a big bushel of  
information to the board.  We need to get this pulled together for  
Wednesday morning.


Thanks!

This report is for the last two months (let's say August  -  
September):


*Community*
- Voted in 1 new committer which brings us to 32 committers
- Voted in 7 new PMC members.  PMC currently at 19 members
- Community voted to return to CTR from RTC starting on September 18th

*Releases*
Geronimo - Version 1.1.1 was approved for release and the jars were  
made available on Monday, September 18th.

Xbean
Devtools
DayTrader - Version 1.1.1 is ready to start the release process.   
It includes minor tweaks and a few bug fixes.  Nothing major.

Genesis - initial release vote nearly complete
GShell - ?



*Development*
Geronimo
- Dain and Alan were voted in as release managers for 1.2.

Unless I'm mistaken, this was only discussed. There hasn't been a vote.

- Content being defined by the community.

Xbean

DayTrader
- Bug fixes for 1.1.1.
- Some POCs on new Ajax interfaces

DevTools

*Other Stuff*


--kevan

Re: [VOTE] Publish Genesis 1.0 to m2 central

2006-09-19 Thread Kevan Miller


Time to call this vote, I think. Alan or Jason?
--kevan
On Sep 12, 2006, at 7:44 PM, Alan D. Cabrera wrote:


+1

Thanks Jason for getting this rolling again.


Regards,
ALan


On Sep 12, 2006, at 1:44 PM, Jason Dillon wrote:

I had thought Alan was going to resume the 1.0 vote with the  
artifacts thats I published to:


http://people.apache.org/~jdillon/repository/org/apache/ 
geronimo/genesis/


This is a re-release of 1.0, with the clover license removed, but  
not the artifact (its empty now).


--jason


On Sep 7, 2006, at 5:16 AM, Bill Dudney wrote:


Hi Jason,

Did this ever get done? I'm +1 on releasing something (1.1, 1.0.1  
1.0-oops whatever) since we are forced to build it after a  
complete bootstrap.


TTFN,

-bd-
On Aug 30, 2006, at 7:19 PM, Jason Dillon wrote:

Well... it was actually released... and then pulled back...  
which is my fault.


But, I don't see any reason why 1.0 needs to be re-released.   
I've already updated the tree to use 1.1-SNAPSHOT and have been  
making changes to it to fix the noted problems as well as a few  
other enhancements... IMO it is much more confusing to look at  
the SVN logs and see that 1.0 was made from a 1.1-SNAPSHOT.


I think that the unfortunate practice of making a release then  
voting on it and then possibly re-cutting the same release is  
very poor.  I'd much rather consider 1.0 dead and release 1.1 so  
that there is no confusion as to which is which.


In almost every other software project I have worked on, a  
release is cut, if there are changes, then a new revision is  
made and then a new release is cut for the changes.  If you  
wanted to keep the 1.0 bits in there then 1.0-1 and then 1.0-2  
is common practice for minor fix iterations.


While I can understand since the time to run the tck for the  
Geronimo server on the release binaries and then after that has  
run we vote... that the server release is a bit different.  I  
don't think this needs to be or should be the case for other  
projects.  I believe it is much, much better to test the latest  
SNAPSHOT, then vote to make the release and then make the release.


Anyways, I don't think that the version matters very much here.   
This is an internal project used to support internal builds.  I  
don't expect anyone outside of Geronimo to even care.  So, I  
still recommend that 1.0 is dead and next to be released w/ 
proper oversight and vote is 1.1.


--jason


On Aug 30, 2006, at 6:02 PM, Alan D. Cabrera wrote:

I'm confused, how do we vote for 1.1 if 1.0 was never  
released?  We need to keep the version number the same.



Regards,
Alan

Jason Dillon wrote:
Okay, I'm canceling this vote.  I've removed the clover bits  
from Genesis, and added headers to scripts... will start a new  
vote for 1.1 soonish.


Thanks for all of your input.  Sorry I jumped the gun and  
created the release before the vote.


--jason


On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote:



On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote:


On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote:
I appreciate that, I applaud your efforts, and apologize if  
I'm being a PITA. However, we also have a responsibility as  
a community when releasing software. I'm trying to be sure  
we are addressing that responsibility.


Mmmkay.  I'm taking deep breaths... :-]


For instance, I see that genesis-1.0 includes a software  
license for Clover? News to me, but I confess that genesis  
has been a bit of an unknown to me...


from
Product: Clover
License: Open Source License, 0.x, 1.x
Issued: Sun May 14 2006 21:59:13 CDT
Expiry: Never
Maintenance Expiry: Never
Key: 965016739f4031c43d67e61b0
Name: Jason Dillon
Org: Apache Geronimo

Clause 5 of the Clover license says "The Licensee may copy  
the Software for back-up purposes only. The Licensee may  
not assign or otherwise transfer the Software to any third  
party." IANAL ADNWTB, however, this gives me cause for  
concern. Can you explain what this is about?


I have no idea what "IANAL ADNWTB" means.  But Clover grants  
licenses for open source projects.  I used the license they  
granted to me to be used to run the site builds.  This is  
shared configuration, which was checked into genesis to  
simplify the configuration of modules which need it to run  
the plugin.


Sorry..
I Am Not A Lawyer
And Don't Want To Be

I don't think we can put this license in on ibiblio. I also  
don't think it should be public in our source tree... I  
understand that this may make things more difficult, but it  
sure seems to me that we're violating the terms of the  
license agreement... Can you convince me otherwise?


--kevan

Re: Let us please use a JIRA for every code change we make

There are always small changes that are not directly tied to a  
specific JIRA issue.  My point is that by making it a requirement to  
have a JIRA issue that people will end up creating more issues than  
we really nee (or want).


I have made a lot of small changes to the build which fit into this  
category.  Some clean up also fits into that category.  Say, adding  
or fixing javadocs, or adding TODO comments, etc... all things which  
probably don't have a JIRA issue and it would be a PITA to force  
folks to go an make one.  That is way to artificial and pointless.


--jason


On Sep 19, 2006, at 12:08 AM, Jacek Laskowski wrote:


On 9/18/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

I think it is a bad idea to force every change to have a JIRA issue
created (or associated).  This will only lead to forcing people to
add a bunch of junk to JIRA.

-1 to forcing each change to have a JIRA... common sense should
dictate which changes need JIRA issues and which do not.

JIRA is more useful to track high-level coarse grained information
and bugs fixed.  If you need fine grained history, look at  
subversion.


Would you present some examples of changes (commits) that should not
be reported in JIRA? What changes would you make that don't fall into
some kind of high-level coarse-grained information? If they're not
part of a bigger picture, why would you care to commit them? I can't
think of any change that goes to trunk without a need for it so if
there's a need for it people will expect it to be trackable and
RELEASE NOTES are one of the excellent means. It requires that each
and every change is bound to a JIRA report, though.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: CWiki questions

On Sep 18, 2006, at 4:12 PM, Matthieu Riou wrote:Hi,Hi :-)I'm working on Ode (incubated project of a WS-BPEL implementation) and we'd like to put up a decent site based on our Confluence space (we already have a setup on cwiki.apache.org ). It seems that, even if it isn't already your official site yet, you've already been through a lot with this so I had a couple of questions.Jason (Dillon), Bruce told me that you were the right person to ask this to, hope you're here :) Yup and yup.1. Your auto-exported site uses the nice looking Geronimo site template, did you patch autoexport for that?Nope, just using the AutoExport plugin as it was installed by Pier at the moment.Did you do it yourself? I just don't think I have the karma for this, is there somebody who could do it for us?You need to be in confluence-administrators to access the plugin's config:    http://cwiki.apache.org/confluence/admin/autoexport/configuration.action2. Where do you get the autoexported pages from? Ideally we could commit them in our svn regularly.Jeff used to have the exports sync'd to people here:    http://people.apache.org/~jefft/confluence/But, looks like its gone now.--jason

Re: Geronimo site POC using Confluence & Autoexport