Re: Expired message stuck inside the queue

2007-01-19 Thread James Strachan

Does the same thing happen if you try the latest 4.2-snapshot (from January)?

On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:


4.1

James.Strachan wrote:

 Which version are you using?

 On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:

 I had sent an 10 sec expired message to a queue(i stopped the application
 server tat reading the queue's message for 10 sec to create this
 scenario),
 then started the application server and i send another message to the
 same
 queue after 20 sec (in this case the previous message should be expired).
 The 2nd message that I send to the queue cannot be consumed due to the
 previous expired message stuck inside the queue. May i know how to solve
 this? thanks.
 --
 View this message in context:
 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8445948
 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.




 --

 James
 ---
 http://radio.weblogs.com/0112098/



--
View this message in context: 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8446196
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





--

James
---
http://radio.weblogs.com/0112098/


Re: Expired message stuck inside the queue

2007-01-19 Thread bluedolphin

we just allowed to use official release for our production use. Since 4.2
haven been officially released, we r not allowed to use it. Is there any
other solution? 

Thanks in advance

James.Strachan wrote:
 
 Does the same thing happen if you try the latest 4.2-snapshot (from
 January)?
 
 On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:

 4.1

 James.Strachan wrote:
 
  Which version are you using?
 
  On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:
 
  I had sent an 10 sec expired message to a queue(i stopped the
 application
  server tat reading the queue's message for 10 sec to create this
  scenario),
  then started the application server and i send another message to the
  same
  queue after 20 sec (in this case the previous message should be
 expired).
  The 2nd message that I send to the queue cannot be consumed due to the
  previous expired message stuck inside the queue. May i know how to
 solve
  this? thanks.
  --
  View this message in context:
 
 http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8445948
  Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
 
 
 
 
  --
 
  James
  ---
  http://radio.weblogs.com/0112098/
 
 

 --
 View this message in context:
 http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8446196
 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


 
 
 -- 
 
 James
 ---
 http://radio.weblogs.com/0112098/
 
 

-- 
View this message in context: 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8446603
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



Re: Expired message stuck inside the queue

2007-01-19 Thread James Strachan

On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:


we just allowed to use official release for our production use. Since 4.2
haven been officially released, we r not allowed to use it. Is there any
other solution?


Can't you try reproduce it in development?

--

James
---
http://radio.weblogs.com/0112098/


getaddrinfo() error

2007-01-19 Thread Motl

I 've fixed a tiny bug with getaddrinfo() error handling. Whom should I
delegate a patch?
-- 
View this message in context: 
http://www.nabble.com/getaddrinfo%28%29-error-tf3039518.html#a8447964
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



Re: Doxample: Can we ship it with our code?

2007-01-19 Thread Hiram Chirino

Thanks Oren!

On Jan 18, 2007, at 6:49 PM, Oren Ben-Kiki wrote:


On Thu, 2007-01-18 at 18:09 -0500, Hiram Chirino wrote:

...
Yeah the differences between the two get a bit complex and IANAL  
too :)


But I think the biggest difference between the Licenses are that
Apache licensed software is a bit more liberal with how it can be
used.  For example it allows commercial companies to make
modifications and redistribute without giving back the changes.
Which is contrary to the GPL philosophy.  In essence the Apache, BSD,
and MIT licenses are more Business friendly.

So I light of that, you might not actually want to Apache License
it.. And that would be OK...


I don't feel that strongly about it. It isn't exactly the crown
jewels :-)


But if you don't mind other folks using your file (even for
commercial reasons), you would just need to also add this to the
header for us to be able to consume it:

Copyright [] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,  
software

distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing  
permissions and

limitations under the License.


Fine, put that in there with my name (Oren Ben-Kiki) and the current
year (2007). And hopefully within a short period of time this  
will be

in the Autoconf archive and the problem will go away.

Share  Enjoy,

Oren Ben-Kiki





[jira] Commented: (AMQ-1016) 4.1 RC1: META-INF/spring.schemas refers to building user file:/Users/chirino/

2007-01-19 Thread JIRA

[ 
https://issues.apache.org/activemq/browse/AMQ-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37935
 ] 

Endre Stølsvik commented on AMQ-1016:
-

Now the 4.2 SNAPSHOT version doesn't work either.

I've now put a 4.1-working version here (its a 4.2 SNAPSHOT version that I 
apparently downloaded 2007-01-08, according to its timestamp):
  http://picorg.net/schema/activemq-4.1-working-V4.2.xsd

Hopefully the maintainers of ActiveMQ at some point will understand and fix 
this rather big problem.

By exchanging the xsi:schemaLocation URL with that one, I got both Eclipse to 
be happy, and my app to actually boot.

NOTE: I will not promise that I'll leave that file there forever, so don't go 
production with it.


 4.1 RC1: META-INF/spring.schemas refers to building user 
 file:/Users/chirino/
 ---

 Key: AMQ-1016
 URL: https://issues.apache.org/activemq/browse/AMQ-1016
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.1.0
 Environment: n/a
Reporter: Endre Stølsvik
 Assigned To: Hiram Chirino
Priority: Minor
 Fix For: 4.1.1, 4.2.0


 Referring to the 4.1 RC1 posted by Hiram Chirino  Oct 06, here:
   http://www.nabble.com/ActiveMQ-4.1-RC-1-tf2397970.html#a6686974
 The META-INF file spring.schemas have the single line.
 http\://activemq.org/config/1.0=file:/Users/chirino/sandbox/activemq-4.1/activemq-core/target/activemq.xsd
 Notice file:/ and Users/chirino. Referring to 
 org.springframework.beans.factory.xml.PluggableSchemaResolver's javadoc: 
 schema-location should also be a schema file in the classpath, and that 
 no-one can tell what structure I will have on my fs, this must be wrong. In 
 addition, I most probably won't have a user name chirino.
 PS: In addition, the doc at
   
 http://www.activemq.org/site/how-do-i-embed-a-broker-inside-a-connection.html
 refers as such:
 xmlns:amq=http://activemq.org/config/1.0;
  .. and ..
 xsi:schemaLocation=http://activemq.org/config/1.0 
 http://people.apache.org/repository/org.apache.activemq/xsds/activemq-core-4.1-incubator-SNAPSHOT.xsd;
 Wouldn't it be nice if this was put at a better place than such a 
 snapshot-build URI? It could be put where it will reside when 4.1 actually is 
 out, w/o anyone being to angry about changes during the finalization period, 
 I personally believe.

-- 
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: Dedicated ActiveMQ pooled ConnectionFactory with XA / JCA support

2007-01-19 Thread Christopher G. Stach II
Guillaume Nodet wrote:
 Btw, I've blogged about that at http://gnodet.blogspot.com/
 
 On 12/19/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
 I have committed in jencks some work I have done the past weeks
 on a pooled ConnectionFactory for ActiveMQ.
 This add the following features:
* multiple connections are used to improve throughput (until the
 AMQ broker is multithreaded)
* support for XA transactions: when creating a session, if an XA
 transaction is active,
  the session will be enlisted in this transaction
* support for JCA : if used with JCA inbound support, there is a
 need to wrap the
   XAResource so that the TM knows that both XA resources belongs
 to the same
   ResourceManager

 Support for XA / JCA is much faster than the JCA outbound support
 because the AMQ resource adapter reverts the connection in a fully
 clean state
 after use.  This may be needed when dealing with container managed
 security,
 but when this feature is not used, I would recommend using this pooled
 connection factories, which performs much better.

 -- 
 Cheers,
 Guillaume Nodet


Could you put up some configuration examples, perhaps amqpool outbound
in combination with JCA inbound using AMQ's RA with XA JTA transactions
in Spring? :)

-- 
Christopher G. Stach II



[jira] Commented: (GERONIMO-2752) Axis2 integration displays invalid information for URL requests

2007-01-19 Thread Jacek Laskowski (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465978
 ] 

Jacek Laskowski commented on GERONIMO-2752:
---

Reviewed and it looked fine.

Sending
modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java
Transmitting file data .
Committed revision 497732.

Please, create patches from within Geronimo directory.  
'GERONIMO-issue-id-consecutive-number-when-more-patches-available.patch' 
format would be highly appreciated.

 Axis2 integration displays invalid information for URL requests
 ---

 Key: GERONIMO-2752
 URL: https://issues.apache.org/jira/browse/GERONIMO-2752
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M1
Reporter: Lasantha Ranaweera
 Assigned To: Jacek Laskowski
 Attachments: GERONIMO-2752.patch1, GERONIMO-2752.patch2, 
 GERONIMO-2752.patch3


 Current integration of Axis2 gives wrong information to the wsdl, wsdl2, xsd= 
 .. etc URL requests.

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




[jira] Assigned: (GERONIMO-2752) Axis2 integration displays invalid information for URL requests

2007-01-19 Thread Jacek Laskowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacek Laskowski reassigned GERONIMO-2752:
-

Assignee: (was: Jacek Laskowski)

Give it a shot and report back whether it works as expected or not.

 Axis2 integration displays invalid information for URL requests
 ---

 Key: GERONIMO-2752
 URL: https://issues.apache.org/jira/browse/GERONIMO-2752
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M1
Reporter: Lasantha Ranaweera
 Attachments: GERONIMO-2752.patch1, GERONIMO-2752.patch2, 
 GERONIMO-2752.patch3


 Current integration of Axis2 gives wrong information to the wsdl, wsdl2, xsd= 
 .. etc URL requests.

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




[jira] Commented: (GERONIMO-2752) Axis2 integration displays invalid information for URL requests

2007-01-19 Thread Lasantha Ranaweera (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465981
 ] 

Lasantha Ranaweera commented on GERONIMO-2752:
--

Thanks Jacek!

I will follow the your proposed patch file format. 

Still there is a problem in the ?xsd and ?xsd= requests. I will come up with a 
solution for that soon.

 Axis2 integration displays invalid information for URL requests
 ---

 Key: GERONIMO-2752
 URL: https://issues.apache.org/jira/browse/GERONIMO-2752
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M1
Reporter: Lasantha Ranaweera
 Attachments: GERONIMO-2752.patch1, GERONIMO-2752.patch2, 
 GERONIMO-2752.patch3


 Current integration of Axis2 gives wrong information to the wsdl, wsdl2, xsd= 
 .. etc URL requests.

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




Maven troubles with yesterday's SNAPSHOT

2007-01-19 Thread Rossmanith, Philipp

Hi,

In the project I'm working, we're planning to subclass the DefaultBroker
in order to enhance its features. Hence, I'll have to do some SM
programming and want to make its code available in Eclipse.

Knowing from the past that the latest features are usually available in
the SVN, only, I tried to set up today's snapshot
(apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had
some difficulties with Maven, though.

I followed the steps described in
http://servicemix.org/site/building.html from within the top-level src
directory. I also added M2_REPO to my workspace. MD5 checksums are ok,
as well.

At first, the build went fine, but when I opened the project, I got an
error about my build path and some missing libraries. However, they were
available in my Maven2 repository.

Assuming it might be related to the Maven repository, I deleted it.
However, repeating the compilation process, the build yielded an error:

Project ID: null:xfire-all:jar:1.2.2
Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
project: null:xfire-all:jar:1.2.2

I tried with both the pom.xml contained within the src directory as well
as the apache-servicemix-3.1-incubating-20070118.083008-58.pom.

I changed to the stable 3.0 version and did the same thing all over
again. Now, when executing:

 [INFO] Error building POM (may not be this project's POM).
Project ID: null:xfire-all:jar:1.2.1
Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for project:
null:xfire-all:jar:1.2.1

Hence my questions:
1. Any idea of what I did wrong
2. Which is the fool-proof way of getting Eclipse-Access to the SM
sources
3. Which of the two POMs do I have to use

In the meanwhile, I'll be trying to fix the issues by manually
downloading and executing the missing poms (and perhaps adding the
repositories I find to the top-level pom).

Thanks in advance,
Ciao,
Philipp Rossmanith

This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.


Expired message stuck inside the queue

2007-01-19 Thread bluedolphin

I had sent an 10 sec expired message to a queue(i stopped the application
server tat reading the queue's message for 10 sec to create this scenario),
then started the application server and i send another message to the same
queue after 20 sec (in this case the previous message should be expired).
The 2nd message that I send to the queue cannot be consumed due to the
previous expired message stuck inside the queue. May i know how to solve
this? thanks.
-- 
View this message in context: 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8445948
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



[jira] Created: (AMQCPP-48) Fix compilation with Visual Studio .NET 2003

2007-01-19 Thread Albert Strasheim (JIRA)
Fix compilation with Visual Studio .NET 2003


 Key: AMQCPP-48
 URL: https://issues.apache.org/activemq/browse/AMQCPP-48
 Project: ActiveMQ C++ Client
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Albert Strasheim
 Assigned To: Nathan Mittler
Priority: Trivial
 Fix For: 2.0
 Attachments: amqcpp-vs2003.diff

The attached patch contains a few minor changes to make the AMQCPP library 
compile with Visual Studio .NET 2003.

This will be very useful for the [Python 
wrapper|http://code.google.com/p/pyactivemq/] I'm working on, since Python 2.4 
and Python 2.5 still need their extension modules compiled with VS .NET 2003.

If you're interested, I can also submit project files for VS .NET 2003.

-- 
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: Expired message stuck inside the queue

2007-01-19 Thread James Strachan

Which version are you using?

On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:


I had sent an 10 sec expired message to a queue(i stopped the application
server tat reading the queue's message for 10 sec to create this scenario),
then started the application server and i send another message to the same
queue after 20 sec (in this case the previous message should be expired).
The 2nd message that I send to the queue cannot be consumed due to the
previous expired message stuck inside the queue. May i know how to solve
this? thanks.
--
View this message in context: 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8445948
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





--

James
---
http://radio.weblogs.com/0112098/


Help Needed on AbastractNamingBuilder

2007-01-19 Thread Lasantha Ranaweera

Hi,

I have been working with the Geronimo Axis2 integration and following 
the foot steps of the CXF and Axis implementations of Geronimo. Finally 
this integration will provide one of the  JAXWS integrations of the 
Geronimo ;-) . 

In the Axis 1 integration there is a  class called  
AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we need a 
same kind of class for the Axis2 integration too considering the above 
requirement?  (CXF module has not implemented this kind of class yet but 
it has been commented out in the config.xml).


If anybody explain bit more in depth on this AbastractNamingBuilder 
class and it's effect to the JEE it would be great help for my work 
since it looks bit more complicated for me now :-) .


Thanks in Advance,
Lasantha Ranaweera


Re: Expired message stuck inside the queue

2007-01-19 Thread bluedolphin

4.1

James.Strachan wrote:
 
 Which version are you using?
 
 On 1/19/07, bluedolphin [EMAIL PROTECTED] wrote:

 I had sent an 10 sec expired message to a queue(i stopped the application
 server tat reading the queue's message for 10 sec to create this
 scenario),
 then started the application server and i send another message to the
 same
 queue after 20 sec (in this case the previous message should be expired).
 The 2nd message that I send to the queue cannot be consumed due to the
 previous expired message stuck inside the queue. May i know how to solve
 this? thanks.
 --
 View this message in context:
 http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8445948
 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


 
 
 -- 
 
 James
 ---
 http://radio.weblogs.com/0112098/
 
 

-- 
View this message in context: 
http://www.nabble.com/Expired-message-stuck-inside-the-queue-tf3038899.html#a8446196
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



Re: OpenEJB 3 integration working

2007-01-19 Thread Jacek Laskowski

On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:

It has been a long week, but David and I got the integration working
tonight.  We successful got the OpenEJB 3 itest application to deploy
and got the client to fire up and call the server.  A bunch of tests
fail due to a bug in lookup of datasources in OpenEJB, but we got a
good number of passes.


Awesome! Although it might've seemed hard to crack, THEY again did it! Thanks!

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl


[jira] Commented: (GERONIMO-2105) When redeploying with no version number, new entries in config.xml break

2007-01-19 Thread Vamsavardhana Reddy (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466032
 ] 

Vamsavardhana Reddy commented on GERONIMO-2105:
---

Fixed (partly??) in rev 497782 in branches\1.2 and trunk. 

 o This was fixed in rev 413342 in branches\1.1 (though the entries in 
config.xml are migrated properly, attribute value changes get reflected only 
upon restarting the configuration). Neither the revision was merged into trunk 
nor the JIRA was updated about the revision.
  o Merging rev 413342 into branches\1.2 and trunk

 When redeploying with no version number, new entries in config.xml break
 

 Key: GERONIMO-2105
 URL: https://issues.apache.org/jira/browse/GERONIMO-2105
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: kernel
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Aaron Mulder
Priority: Blocker
 Fix For: 1.1.2, 1.x, 2.0

 Attachments: g2105-1.2.war, g2105.war


 Let's say you deploy foo with no version number and config.xml content.  Then 
 through the console or some other mechanism, you set a property on a 
 previously unlisted GBean.  Now you get something like this:
   module name=default/foo/1149955208117/war
 gbean 
 name=default/foo/1149955208117/war?J2EEApplication=null,WebModule=default/foo/1149955208117/war,j2eeType=GBean,name=MyGBean
   attribute name=barvalue/attribute
 Now you redeploy foo, and it migrates the config.xml entry to the new version 
 number.  However, what you actually get is this:
   module name=default/foo/1149955408117/war
 gbean 
 name=default/foo/1149955223470/war?J2EEApplication=null,WebModule=default/foo/1149955223470/war,j2eeType=GBean,name=MyGBean
   attribute name=barvalue/attribute
 Note the different version numbers between module and gbean elements.  In 
 other words, the version in the main config.xml entry is updated, but the 
 version in the GBean entries is not.  This means that the module will fail to 
 start, as it will treat the GBean as a brand new GBean declaration and crap 
 out when it has no GBeanInfo defined.

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




Re: OpenEJB 3 integration working

2007-01-19 Thread Sachin Patel

Wow, this is awesome!  Great Job!!

On Jan 19, 2007, at 4:20 AM, Dain Sundstrom wrote:

It has been a long week, but David and I got the integration  
working tonight.  We successful got the OpenEJB 3 itest application  
to deploy and got the client to fire up and call the server.  A  
bunch of tests fail due to a bug in lookup of datasources in  
OpenEJB, but we got a good number of passes.


-dain


-sachin




Re: getaddrinfo() error

2007-01-19 Thread James Strachan

On 1/19/07, Motl [EMAIL PROTECTED] wrote:

I 've fixed a tiny bug with getaddrinfo() error handling. Whom should I
delegate a patch?


Details on submitting patches here...
http://incubator.apache.org/activemq/support.html

--

James
---
http://radio.weblogs.com/0112098/


Re: OpenEJB 3 integration working

2007-01-19 Thread Joe Bohn

This is great news that will really make 2.0-M2 shine!

Thanks for all the hard work, long hours, and dedication that it took to 
make this happen.


Joe

Dain Sundstrom wrote:
It has been a long week, but David and I got the integration working 
tonight.  We successful got the OpenEJB 3 itest application to deploy 
and got the client to fire up and call the server.  A bunch of tests 
fail due to a bug in lookup of datasources in OpenEJB, but we got a good 
number of passes.


-dain



Re: OpenEJB 3 integration working

2007-01-19 Thread Matt Hogstrom


On Jan 19, 2007, at 4:20 AM, Dain Sundstrom wrote:

It has been a long week, but David and I got the integration  
working tonight.  We successful got the OpenEJB 3 itest application  
to deploy and got the client to fire up and call the server.


(yawn)

A bunch of tests fail due to a bug in lookup of datasources in  
OpenEJB, but we got a good number of passes.


Ok, all kidding aside this is awesome.  I'm building this morning.   
Hats off dudes.




-dain



Matt Hogstrom
[EMAIL PROTECTED]




Re: Proposal for property substitution in config.xml

2007-01-19 Thread Ted Kirby

A properties file sounds like a good idea.  Presumably this would work like
how the config.xml filename is passed in: from the configFile attribute of
the AttributeManager GBean in the j2ee-system module, although it may be
overridden by the org.apache.geronimo.config.file system property.  The
LocalAttributeManager constructor would then read in the properties file,
setting up a hashmap for substitution variables and their values.


It seems there are three possibilities for value sources: system properties,
environment variables and the properties file.  We should develop a
hierarchal search order for them, which is probably how I listed them.  We
might add a syntax for specifying the source, although the hierarchy is
probably better.

On 1/18/07, David Jencks [EMAIL PROTECTED] wrote:


This seems reasonable and I think it will work but I'm worried about an
infinite regress of configuration systems.  Config.xml was supposed to be
this handy way to substitute attribute values for the correct ones
provided in the module plans.  Now we're considering overriding these on the
command line, and perhaps next we'll be able to specify property files and
additional xml files to further customize the configuration not to mention
files containing lists of other configuration override files.. Imagining
this is making me a little worried.  I wonder if a different approach could
possibly work better, but I sure don't know what it is.  I think it might be
useful to figure out exactly what anyone is likely to want to configure in
this way.  I suspect that it's going to turn out to be the connections to
the edges of the system, such as host name/ ip and ports, and db locations.
Maybe we should think about configuring those separately in e.g a
properties file or something.

thanks
david jencks

 On Jan 18, 2007, at 3:15 PM, Ted Kirby wrote:

 The idea is allow an identical configuration on a set of machines, yet
allow customization through property substitution with command line/system
property override ( i.e. java -Dxxx.yyy.zzz=ABC).


For example, allow the following in config.xml:

module name=...
gbean name=TomcatConnector
attribute name=port${tomcat.port}/attribute
attribute name=host${tomcat.listen.ip}/attribute
/gbean
/module


These variables are set on server startup via:
java –Dtomcat.port=9090 –Dtomcat.listen.ip=10.0.0.7


JBoss has this capability, and I'd like to bring it to Geronimo.


I have opened JIRA 2735 (https://issues.apache.org/jira/browse/GERONIMO-2735
) for the feature, but I wanted to solicit community input and feedback on
features and implementation.


I think this feature could be pretty easily implemented in GBeanOverride.
The constructor reads the values from config.xml.  The values could be
parsed for ${…} constructs.   If a known substitution variable is found
inside, the attribute and its unsubstituted value could be saved in an
unsubstitutedAttribute hashmap.  The attribute hashmap would contain the
substituted value.  This logic can also be applied to the setAttribute
method.  The writeXML method is used to write out the config.xml.  As it
is processing the attributes hashmap, if the attribute name was found in the
new unsubstitutedAttribute hashmap, write out its value instead.


Thoughts?






[jira] Created: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread Jarek Gawor (JIRA)
Basic @Resource injection for CXF web services
--

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Attachments: GERONIMO-2756.patch



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




[jira] Updated: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread Jarek Gawor (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor updated GERONIMO-2756:
--

Attachment: GERONIMO-2756.patch

 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Attachments: GERONIMO-2756.patch




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




Re: OpenEJB 3 integration working

2007-01-19 Thread Paul McMahan

Sweet!  great job Dain and David.

Paul

On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:

It has been a long week, but David and I got the integration working
tonight.  We successful got the OpenEJB 3 itest application to deploy
and got the client to fire up and call the server.  A bunch of tests
fail due to a bug in lookup of datasources in OpenEJB, but we got a
good number of passes.

-dain



Re: OpenEJB 3 integration working

2007-01-19 Thread Prasad Kashyap

Wow !!!  You guyz are terrific !

Cheers
Prasad


On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:

It has been a long week, but David and I got the integration working
tonight.  We successful got the OpenEJB 3 itest application to deploy
and got the client to fire up and call the server.  A bunch of tests
fail due to a bug in lookup of datasources in OpenEJB, but we got a
good number of passes.

-dain



Maven troubles with ServiceMix 3.0 - Follow-up

2007-01-19 Thread Rossmanith, Philipp

Hi,

I managed to resolve the problem
  [INFO] Error building POM (may not be this project's POM).
 Project ID: null:xfire-all:jar:1.2.1
 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
project:
 null:xfire-all:jar:1.2.1

... by proceeding as suggested here:
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061
0.mbox/[EMAIL PROTECTED], that is, commenting out the
https-repository in
.m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom.

Now, my SM 3.0 Maven build works fine. Still, when opening the project
in Eclipse, there are 3388 errors, obviously resulting from missing
dependencies.

I installed the Maven Eclipse plugin from
http://maven.apache.org/eclipse-plugin.html and added the Maven-managed
dependencies to the build-path.

This reduces the number of errors to 1166. Still, it gets stuck with
tranql-1.3.pom, an issue that has been described in
http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598
0.html

At the moment, I am adding the missing jars manually. However, that's a
major pain.

Hence, any feedback on how to resolve this issue would be highly
appreciated. Should this post better be sent to a different mailing
list, please let me know about it.

Thanks in advance,
Ciao,
Philipp Rossmanith

 -Mensaje original-
 De: Rossmanith, Philipp
 Enviado el: viernes, 19 de enero de 2007 9:30
 Para: servicemix-dev@geronimo.apache.org
 Asunto: Maven troubles with yesterday's SNAPSHOT


 Hi,

 In the project I'm working, we're planning to subclass the
DefaultBroker
 in order to enhance its features. Hence, I'll have to do some SM
 programming and want to make its code available in Eclipse.

 Knowing from the past that the latest features are usually available
in
 the SVN, only, I tried to set up today's snapshot
 (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had
 some difficulties with Maven, though.

 I followed the steps described in
 http://servicemix.org/site/building.html from within the top-level src
 directory. I also added M2_REPO to my workspace. MD5 checksums are ok,
 as well.

 At first, the build went fine, but when I opened the project, I got an
 error about my build path and some missing libraries. However, they
were
 available in my Maven2 repository.

 Assuming it might be related to the Maven repository, I deleted it.
 However, repeating the compilation process, the build yielded an
error:

 Project ID: null:xfire-all:jar:1.2.2
 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
 project: null:xfire-all:jar:1.2.2

 I tried with both the pom.xml contained within the src directory as
well
 as the apache-servicemix-3.1-incubating-20070118.083008-58.pom.

 I changed to the stable 3.0 version and did the same thing all over
 again. Now, when executing:


 Hence my questions:
 1. Any idea of what I did wrong
 2. Which is the fool-proof way of getting Eclipse-Access to the SM
 sources
 3. Which of the two POMs do I have to use

 In the meanwhile, I'll be trying to fix the issues by manually
 downloading and executing the missing poms (and perhaps adding the
 repositories I find to the top-level pom).

 Thanks in advance,
 Ciao,
 Philipp Rossmanith

This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.


Re: Maven troubles with ServiceMix 3.0 - Follow-up

2007-01-19 Thread Guillaume Nodet

Have you tried following instructions available at
 http://servicemix.org/site/importing-servicemix-into-eclipse.html ?

On 1/19/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote:


Hi,

I managed to resolve the problem
  [INFO] Error building POM (may not be this project's POM).
 Project ID: null:xfire-all:jar:1.2.1
 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
project:
 null:xfire-all:jar:1.2.1

... by proceeding as suggested here:
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061
0.mbox/[EMAIL PROTECTED], that is, commenting out the
https-repository in
.m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom.

Now, my SM 3.0 Maven build works fine. Still, when opening the project
in Eclipse, there are 3388 errors, obviously resulting from missing
dependencies.

I installed the Maven Eclipse plugin from
http://maven.apache.org/eclipse-plugin.html and added the Maven-managed
dependencies to the build-path.

This reduces the number of errors to 1166. Still, it gets stuck with
tranql-1.3.pom, an issue that has been described in
http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598
0.html

At the moment, I am adding the missing jars manually. However, that's a
major pain.

Hence, any feedback on how to resolve this issue would be highly
appreciated. Should this post better be sent to a different mailing
list, please let me know about it.

Thanks in advance,
Ciao,
Philipp Rossmanith

 -Mensaje original-
 De: Rossmanith, Philipp
 Enviado el: viernes, 19 de enero de 2007 9:30
 Para: servicemix-dev@geronimo.apache.org
 Asunto: Maven troubles with yesterday's SNAPSHOT


 Hi,

 In the project I'm working, we're planning to subclass the
DefaultBroker
 in order to enhance its features. Hence, I'll have to do some SM
 programming and want to make its code available in Eclipse.

 Knowing from the past that the latest features are usually available
in
 the SVN, only, I tried to set up today's snapshot
 (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I had
 some difficulties with Maven, though.

 I followed the steps described in
 http://servicemix.org/site/building.html from within the top-level src
 directory. I also added M2_REPO to my workspace. MD5 checksums are ok,
 as well.

 At first, the build went fine, but when I opened the project, I got an
 error about my build path and some missing libraries. However, they
were
 available in my Maven2 repository.

 Assuming it might be related to the Maven repository, I deleted it.
 However, repeating the compilation process, the build yielded an
error:

 Project ID: null:xfire-all:jar:1.2.2
 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
 project: null:xfire-all:jar:1.2.2

 I tried with both the pom.xml contained within the src directory as
well
 as the apache-servicemix-3.1-incubating-20070118.083008-58.pom.

 I changed to the stable 3.0 version and did the same thing all over
 again. Now, when executing:


 Hence my questions:
 1. Any idea of what I did wrong
 2. Which is the fool-proof way of getting Eclipse-Access to the SM
 sources
 3. Which of the two POMs do I have to use

 In the meanwhile, I'll be trying to fix the issues by manually
 downloading and executing the missing poms (and perhaps adding the
 repositories I find to the top-level pom).

 Thanks in advance,
 Ciao,
 Philipp Rossmanith

This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.




--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/


new maven repository for tomcat

2007-01-19 Thread Paul McMahan

The tomcat6 jars are currently being imported into geronimo from the
apache snapshot repo.  The tomcat team is now also publishing
officially released jars to a maven repo at
http://tomcat.apache.org/dev/dist/m2-repository (thanks Filip!).  I
would like to import the jars from that repo instead of the snapshot
repo so we can avoid using snapshot versions.  Is it OK to enable the
tomcat repo in the root pom or should I only enable it in the specific
module(s) that needs it?  I prefer to enable in the root pom but as I
recall adding new repos has caused some problems in the past.

Best wishes,
Paul


Re: new maven repository for tomcat

2007-01-19 Thread Jeff Genender
Is there a reason they won't post them to the usual places to get picked
up by ibiblio?

Jeff

Paul McMahan wrote:
 The tomcat6 jars are currently being imported into geronimo from the
 apache snapshot repo.  The tomcat team is now also publishing
 officially released jars to a maven repo at
 http://tomcat.apache.org/dev/dist/m2-repository (thanks Filip!).  I
 would like to import the jars from that repo instead of the snapshot
 repo so we can avoid using snapshot versions.  Is it OK to enable the
 tomcat repo in the root pom or should I only enable it in the specific
 module(s) that needs it?  I prefer to enable in the root pom but as I
 recall adding new repos has caused some problems in the past.
 
 Best wishes,
 Paul


Re: new maven repository for tomcat

2007-01-19 Thread Paul McMahan

In Filip's post on [EMAIL PROTECTED] :
http://www.nabble.com/Tomcat-Jars---Maven2-repo-tf3023226.html#a8397986

 We can run with this setup for a while, once outside folks are happy
 with the release jars, we can start deploying to ASF Ibiblio sync
 repo, so they get copied to the central repository.




On 1/19/07, Jeff Genender [EMAIL PROTECTED] wrote:

Is there a reason they won't post them to the usual places to get picked
up by ibiblio?

Jeff

Paul McMahan wrote:
 The tomcat6 jars are currently being imported into geronimo from the
 apache snapshot repo.  The tomcat team is now also publishing
 officially released jars to a maven repo at
 http://tomcat.apache.org/dev/dist/m2-repository (thanks Filip!).  I
 would like to import the jars from that repo instead of the snapshot
 repo so we can avoid using snapshot versions.  Is it OK to enable the
 tomcat repo in the root pom or should I only enable it in the specific
 module(s) that needs it?  I prefer to enable in the root pom but as I
 recall adding new repos has caused some problems in the past.

 Best wishes,
 Paul



[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception

2007-01-19 Thread Donald Woods (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-1585:
---

Attachment: G1585-Geronimo2.0.patch

 Web app security on /* causes deployment exception
 --

 Key: GERONIMO-1585
 URL: https://issues.apache.org/jira/browse/GERONIMO-1585
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security, web
Affects Versions: 1.1
 Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
Priority: Critical
 Fix For: 1.1.x, 1.2

 Attachments: G1585-Geronimo2.0.patch, g1585-nologin.war, g1585.war, 
 security.patch


 Deploying a web app with the following security block causes a deployment 
 error:
 security-constraint
 web-resource-collection
 web-resource-nameAll Pages/web-resource-name
 url-pattern/*/url-pattern
 http-methodGET/http-method
 http-methodPOST/http-method
 http-methodPUT/http-method
 /web-resource-collection
 auth-constraint
 role-nameUser/role-name
 /auth-constraint
 /security-constraint
 Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
 2.4 spec).
 The error is:
 org.apache.geronimo.common.DeploymentException: Unable to initialize 
 webapp GBean
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
 ...
 Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
 URLPatternSpec cannot match the first URLPattern
 at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
 at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
 ... 70 more
 Changing the url-pattern to / fixes the problem, but it seems to me that /* 
 ought to work too.

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




[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception

2007-01-19 Thread Donald Woods (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-1585:
---

Affects Version/s: 2.0
   1.2
   1.1.2
Fix Version/s: 2.0-M2

Original security.patch is for 1.1/1.2, so I created one for the new file 
structure in 2.0 called G1585-Geronimo2.0.patch.


 Web app security on /* causes deployment exception
 --

 Key: GERONIMO-1585
 URL: https://issues.apache.org/jira/browse/GERONIMO-1585
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security, web
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
 Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
Priority: Critical
 Fix For: 1.1.x, 1.2, 2.0-M2

 Attachments: G1585-Geronimo2.0.patch, g1585-nologin.war, g1585.war, 
 security.patch


 Deploying a web app with the following security block causes a deployment 
 error:
 security-constraint
 web-resource-collection
 web-resource-nameAll Pages/web-resource-name
 url-pattern/*/url-pattern
 http-methodGET/http-method
 http-methodPOST/http-method
 http-methodPUT/http-method
 /web-resource-collection
 auth-constraint
 role-nameUser/role-name
 /auth-constraint
 /security-constraint
 Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
 2.4 spec).
 The error is:
 org.apache.geronimo.common.DeploymentException: Unable to initialize 
 webapp GBean
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
 ...
 Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
 URLPatternSpec cannot match the first URLPattern
 at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
 at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
 ... 70 more
 Changing the url-pattern to / fixes the problem, but it seems to me that /* 
 ought to work too.

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




Re: Help Needed on AbastractNamingBuilder

2007-01-19 Thread David Jencks


On Jan 19, 2007, at 1:08 AM, Lasantha Ranaweera wrote:


Hi,

I have been working with the Geronimo Axis2 integration and  
following the foot steps of the CXF and Axis implementations of  
Geronimo. Finally this integration will provide one of the  JAXWS  
integrations of the Geronimo ;-) .
In the Axis 1 integration there is a  class called   
AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we  
need a same kind of class for the Axis2 integration too considering  
the above requirement?  (CXF module has not implemented this kind  
of class yet but it has been commented out in the config.xml).


If anybody explain bit more in depth on this AbastractNamingBuilder  
class and it's effect to the JEE it would be great help for my work  
since it looks bit more complicated for me now :-) .


We definitely need one of these for axis2 and one for cxf.  They  
deploy web service clients.  For example, if your ejb needs to access  
a web service, it declares a service-ref in its deployment descriptor  
(there's probably a way to do this with annotations as well) and we  
have to set up a web service client and bind it into the local jndi  
context for that ejb.


There are several steps a naming builder can take:

buildEnvironment.  Here the builder should figure out if it's going  
to need to do anything and if so add the defaultEnvironment it's  
configured with to the supplied environment.  This means that if you  
don't use web services, the ws classes don't need to be there, and if  
you do use web services, they will be available.


initContext:  Here you can add stuff to the shared context that other  
naming builders can use.  I don't think this is going  to be useful  
for ws client builders.  In the future if we get the service builders  
to use the same interface we might be able to use this to construct  
shortcuts so use of a ws in the same app it's supplied in doesn't  
have to go through tcp/ip. this is far in the future.


buildNaming: Here you actually construct something that will make the  
web service client exist when the app is run, put whatever gbeans you  
need into the deployment context, and add a naming reference into the  
map that will populate the jndi tree.


Hope this helps,
david jencks



Thanks in Advance,
Lasantha Ranaweera




Re: OpenEJB 3 integration working

2007-01-19 Thread anita kulshreshtha
Wonderful

   Thanks Dain and David for all the hard work. 

Anita

--- Dain Sundstrom [EMAIL PROTECTED] wrote:

 It has been a long week, but David and I got the integration working 
 
 tonight.  We successful got the OpenEJB 3 itest application to deploy
  
 and got the client to fire up and call the server.  A bunch of tests 
 
 fail due to a bug in lookup of datasources in OpenEJB, but we got a  
 good number of passes.
 
 -dain
 



 

Never Miss an Email
Stay connected with Yahoo! Mail on your mobile.  Get started!
http://mobile.yahoo.com/services?promote=mail


[jira] Assigned: (GERONIMO-1585) Web app security on /* causes deployment exception

2007-01-19 Thread David Jencks (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks reassigned GERONIMO-1585:
--

Assignee: David Jencks

 Web app security on /* causes deployment exception
 --

 Key: GERONIMO-1585
 URL: https://issues.apache.org/jira/browse/GERONIMO-1585
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security, web
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
 Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
 Assigned To: David Jencks
Priority: Critical
 Fix For: 1.1.x, 1.2, 2.0-M2

 Attachments: G1585-Geronimo2.0.patch, g1585-nologin.war, g1585.war, 
 security.patch


 Deploying a web app with the following security block causes a deployment 
 error:
 security-constraint
 web-resource-collection
 web-resource-nameAll Pages/web-resource-name
 url-pattern/*/url-pattern
 http-methodGET/http-method
 http-methodPOST/http-method
 http-methodPUT/http-method
 /web-resource-collection
 auth-constraint
 role-nameUser/role-name
 /auth-constraint
 /security-constraint
 Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
 2.4 spec).
 The error is:
 org.apache.geronimo.common.DeploymentException: Unable to initialize 
 webapp GBean
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
 ...
 Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
 URLPatternSpec cannot match the first URLPattern
 at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
 at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
 ... 70 more
 Changing the url-pattern to / fixes the problem, but it seems to me that /* 
 ought to work too.

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




Re: OpenEJB 3 integration working

2007-01-19 Thread David Jencks

This is great news!  Congratulations!!

david jencks

On Jan 19, 2007, at 1:20 AM, Dain Sundstrom wrote:

It has been a long week, but David and I got the integration  
working tonight.  We successful got the OpenEJB 3 itest application  
to deploy and got the client to fire up and call the server.  A  
bunch of tests fail due to a bug in lookup of datasources in  
OpenEJB, but we got a good number of passes.


-dain




New Samples Framework for Geronimo.

2007-01-19 Thread Prasad Kashyap

Encouraged by your kind words of appreciation for the Testsuite
framework, I put together a similar Samples Framework.

http://svn.apache.org/viewvc/geronimo/samples/

UseCase Scenario 1
---
Actor: Geronimo user, JEE5 Developer.

Requirements:
  * Actor wants to learn the new features of JEE5 by looking at sample code
  * He wants to play with sample code.
  * He wants to learn how to develop applications on Geronimo.
  * He may want to use the sample code as a template for his own application.

Flow A (install downloaded sample binary)
  * Actor downloads a Geronimo server binary  and unpacks it.
  * He then downloads a sample binary.
  * He starts Geronimo server.
  * He then deploys the sample artifact into running server.
  * He goes to the sample app's home page (context-root).

Flow B: (build sample source and install)
  * Actor downloads a sample source package.
  * He installs Maven if he doesn't have it already.
  * He builds the sample project using maven.
  * Sample project automatically downloads the latest Geronimo
server, starts it, and deploys the newly built sample.
  * It fires up a browser and brings up the sample home page  (not
implemented yet).

See the following links in Firefox only !
Here is a page that gives a user instructions on working with samples.
Every sample download will also have a customized  relevant page like
this, say as a README.html
http://people.apache.org/~prasad/samples/index.html

Here is a sample sample page. Notice the javadoc and source tabs in
the top right corner of the page.
http://people.apache.org/~prasad/samples/sample.html


UseCase Scenario 2
---
Actor: Geronimo Developer, JEE5 Spec Implementor

Interactions: Document Writer.

Requirements:
  * Actor wants to create sample projects quickly without having to
deal too much with Maven.

Flow:
  * Actor executes a sample-archetype-plugin.
  * It creates a mvn project which will act as a template.
  * He only has to write JEE5 code for the sample application.
  * He then works with Document Writer to write the sample document.


Cheers
Prasad.


RE: Maven troubles with ServiceMix 3.0 - Follow-up

2007-01-19 Thread Rossmanith, Philipp

Not yet :-) I checked Building, Documentation, and the main page of
servicemix.org, but that link slipped me. I'll try it out...

Thanks - you made my day :-)

Philipp Rossmanith

 -Mensaje original-
 De: Guillaume Nodet [mailto:[EMAIL PROTECTED]
 Enviado el: viernes, 19 de enero de 2007 16:33
 Para: servicemix-dev@geronimo.apache.org
 Asunto: Re: Maven troubles with ServiceMix 3.0 - Follow-up

 Have you tried following instructions available at
   http://servicemix.org/site/importing-servicemix-into-eclipse.html ?

 On 1/19/07, Rossmanith, Philipp [EMAIL PROTECTED]
wrote:
 
  Hi,
 
  I managed to resolve the problem
[INFO] Error building POM (may not be this project's POM).
   Project ID: null:xfire-all:jar:1.2.1
   Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
  project:
   null:xfire-all:jar:1.2.1
 
  ... by proceeding as suggested here:
 
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/20061
  0.mbox/[EMAIL PROTECTED], that is, commenting out
the
  https-repository in
 
.m2\repository\org\codehaus\xfire\xfire-all\1.2.1\xfire-all-1.2.1.pom.
 
  Now, my SM 3.0 Maven build works fine. Still, when opening the
project
  in Eclipse, there are 3388 errors, obviously resulting from missing
  dependencies.
 
  I installed the Maven Eclipse plugin from
  http://maven.apache.org/eclipse-plugin.html and added the
Maven-managed
  dependencies to the build-path.
 
  This reduces the number of errors to 1166. Still, it gets stuck with
  tranql-1.3.pom, an issue that has been described in
 
http://www.mail-archive.com/servicemix-users@geronimo.apache.org/msg0598
  0.html
 
  At the moment, I am adding the missing jars manually. However,
that's a
  major pain.
 
  Hence, any feedback on how to resolve this issue would be highly
  appreciated. Should this post better be sent to a different mailing
  list, please let me know about it.
 
  Thanks in advance,
  Ciao,
  Philipp Rossmanith
 
   -Mensaje original-
   De: Rossmanith, Philipp
   Enviado el: viernes, 19 de enero de 2007 9:30
   Para: servicemix-dev@geronimo.apache.org
   Asunto: Maven troubles with yesterday's SNAPSHOT
  
  
   Hi,
  
   In the project I'm working, we're planning to subclass the
  DefaultBroker
   in order to enhance its features. Hence, I'll have to do some SM
   programming and want to make its code available in Eclipse.
  
   Knowing from the past that the latest features are usually
available
  in
   the SVN, only, I tried to set up today's snapshot
   (apache-servicemix-3.1-incubating-20070118.083008-58-src.zip). I
had
   some difficulties with Maven, though.
  
   I followed the steps described in
   http://servicemix.org/site/building.html from within the top-level
src
   directory. I also added M2_REPO to my workspace. MD5 checksums are
ok,
   as well.
  
   At first, the build went fine, but when I opened the project, I
got an
   error about my build path and some missing libraries. However,
they
  were
   available in my Maven2 repository.
  
   Assuming it might be related to the Maven repository, I deleted
it.
   However, repeating the compilation process, the build yielded an
  error:
  
   Project ID: null:xfire-all:jar:1.2.2
   Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for
   project: null:xfire-all:jar:1.2.2
  
   I tried with both the pom.xml contained within the src directory
as
  well
   as the apache-servicemix-3.1-incubating-20070118.083008-58.pom.
  
   I changed to the stable 3.0 version and did the same thing all
over
   again. Now, when executing:
  
  
   Hence my questions:
   1. Any idea of what I did wrong
   2. Which is the fool-proof way of getting Eclipse-Access to the SM
   sources
   3. Which of the two POMs do I have to use
  
   In the meanwhile, I'll be trying to fix the issues by manually
   downloading and executing the missing poms (and perhaps adding the
   repositories I find to the top-level pom).
  
   Thanks in advance,
   Ciao,
   Philipp Rossmanith
 
  This e-mail may contain confidential or privileged information. Any
 unauthorised
  copying, use or distribution of this information is strictly
prohibited.
 


 --
 Cheers,
 Guillaume Nodet
 
 Architect, LogicBlaze (http://www.logicblaze.com/)
 Blog: http://gnodet.blogspot.com/

This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.


EJB deployment error

2007-01-19 Thread Jarek Gawor

I get the following error after the openejb update:

Deployer operation failed: org.apache.openejb.OpenEJBException: Cannot Load jar
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir\jaxb-ejb-2.0-SN
APSHOT.jar.  The number of beans deployed (0) does not match the number of beans
actually in the jar (1).  Please redeploy this jar.

I see this error after updating the openejb-jar.xml
(http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml
(http://java.sun.com/xml/ns/javaee) descriptors with right namespaces.

I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb tests.

The ejbs are very simple and do not use any annotations.

Jarek


Test Failure in opeejb-builder

2007-01-19 Thread anita kulshreshtha
  I am seeing this in openejb-builder rev 497879, win XP:

Thanks
Anita

---
Test set: org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.907
sec  FAILURE!
test(org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest)  Time
elapsed: 4.844 sec   ERROR!
org.apache.openejb.OpenEJBException: Error building bean
'BasicCmp2Bean'.  Exception: class org.apache.openejb.OpenEJBException:
CMP 2.x implementation class not found
org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA: CMP 2.x
implementation class not found
org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA
at
org.apache.openejb.assembler.classic.EjbJarBuilder.build(EjbJarBuilder.java:61)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:318)
at
org.apache.openejb.assembler.classic.Assembler.createEjbJar(Assembler.java:276)
at
org.apache.geronimo.openejb.OpenEjbSystemGBean.createEjbJar(OpenEjbSystemGBean.java:155)
at 
org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest.test(EjbModuleBuilderTest.java:69)


 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index


Re: EJB deployment error

2007-01-19 Thread Dain Sundstrom
Please take a look at the M2 Status - branch on Wednesday thread.   
It contains a list of what works and what doesn't.  The webservices  
integration doesn't work yet.


-dain

On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote:


I get the following error after the openejb update:

Deployer operation failed: org.apache.openejb.OpenEJBException:  
Cannot Load jar
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir 
\jaxb-ejb-2.0-SN
APSHOT.jar.  The number of beans deployed (0) does not match the  
number of beans

actually in the jar (1).  Please redeploy this jar.

I see this error after updating the openejb-jar.xml
(http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml
(http://java.sun.com/xml/ns/javaee) descriptors with right namespaces.

I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb  
tests.


The ejbs are very simple and do not use any annotations.

Jarek




Re: EJB deployment error

2007-01-19 Thread Jarek Gawor

Dain,

This is just a simple EJB that tires to use JAXB or StAX API. It is
not exposed (or deployed) as a web service.

Jarek

On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:

Please take a look at the M2 Status - branch on Wednesday thread.
It contains a list of what works and what doesn't.  The webservices
integration doesn't work yet.

-dain

On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote:

 I get the following error after the openejb update:

 Deployer operation failed: org.apache.openejb.OpenEJBException:
 Cannot Load jar
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir
 \jaxb-ejb-2.0-SN
 APSHOT.jar.  The number of beans deployed (0) does not match the
 number of beans
 actually in the jar (1).  Please redeploy this jar.

 I see this error after updating the openejb-jar.xml
 (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml
 (http://java.sun.com/xml/ns/javaee) descriptors with right namespaces.

 I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb
 tests.

 The ejbs are very simple and do not use any annotations.

 Jarek




Re: Test Failure in opeejb-builder

2007-01-19 Thread anita kulshreshtha
Never mind.. Updated openejb3 to 497885 and rebuilt openejb3.
   
Thanks
Anita

--- anita kulshreshtha [EMAIL PROTECTED] wrote:

   I am seeing this in openejb-builder rev 497879, win XP:
 
 Thanks
 Anita
 

---
 Test set: org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest

---
 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.907
 sec  FAILURE!
 test(org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest) 
 Time
 elapsed: 4.844 sec   ERROR!
 org.apache.openejb.OpenEJBException: Error building bean
 'BasicCmp2Bean'.  Exception: class
 org.apache.openejb.OpenEJBException:
 CMP 2.x implementation class not found
 org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA: CMP 2.x
 implementation class not found
 org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA
   at

org.apache.openejb.assembler.classic.EjbJarBuilder.build(EjbJarBuilder.java:61)
   at

org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:318)
   at

org.apache.openejb.assembler.classic.Assembler.createEjbJar(Assembler.java:276)
   at

org.apache.geronimo.openejb.OpenEjbSystemGBean.createEjbJar(OpenEjbSystemGBean.java:155)
   at

org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest.test(EjbModuleBuilderTest.java:69)
 
 
  


 Want to start your own business?
 Learn how on Yahoo! Small Business.
 http://smallbusiness.yahoo.com/r-index
 



 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/


Re: Test Failure in opeejb-builder

2007-01-19 Thread Dain Sundstrom

Looks like you have an old build of OpenEJB.

I'll get some new snapshots published but in the mean time try  
building it from source.


-dain

On Jan 19, 2007, at 9:40 AM, anita kulshreshtha wrote:


  I am seeing this in openejb-builder rev 497879, win XP:

Thanks
Anita

-- 
-

Test set: org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest
-- 
-

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.907
sec  FAILURE!
test(org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest)   
Time

elapsed: 4.844 sec   ERROR!
org.apache.openejb.OpenEJBException: Error building bean
'BasicCmp2Bean'.  Exception: class  
org.apache.openejb.OpenEJBException:

CMP 2.x implementation class not found
org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA: CMP 2.x
implementation class not found
org.apache.openejb.test.entity.cmp.BasicCmp2Bean_JPA
at
org.apache.openejb.assembler.classic.EjbJarBuilder.build 
(EjbJarBuilder.java:61)

at
org.apache.openejb.assembler.classic.Assembler.createApplication 
(Assembler.java:318)

at
org.apache.openejb.assembler.classic.Assembler.createEjbJar 
(Assembler.java:276)

at
org.apache.geronimo.openejb.OpenEjbSystemGBean.createEjbJar 
(OpenEjbSystemGBean.java:155)
	at org.apache.geronimo.openejb.deployment.EjbModuleBuilderTest.test 
(EjbModuleBuilderTest.java:69)




__ 
__

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index




[jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Paul McMahan (JIRA)
Enhance plugin schema to allow for multiple versions of a plugin


 Key: GERONIMO-2757
 URL: https://issues.apache.org/jira/browse/GERONIMO-2757
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Plugins
Affects Versions: 2.0
Reporter: Paul McMahan


plugins-1.1.xsd currently allows for a single version of a plugin to be 
described from within a plugin element.   For example, if there were a 
different version of plugin for each version of geronimo then the plugin 
catalog would like something like:

plugin
module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.1/car/module-id
geronimo-version1.1/geronimo-version

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/source-repository
[...]
/plugin
plugin
module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.2/car/module-id
geronimo-version1.2/geronimo-version

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/source-repository
[...]
/plugin
plugin
module-idorg.apache.geronimo.configs/ca-helper-tomcat/2.0/car/module-id
geronimo-version2.0/geronimo-version

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/source-repository
[...]
/plugin
default-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/default-repository
default-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/default-repository
default-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/default-repository

Plugins are usually not compatible across versions of Geronimo for various 
reasons, probably the most prominent of which is Geronimo's reliance on 
serialized java objects in CAR files.  Browsing a catalog that contains a 
plugin element for each version of Geronimo's plugins from the  admin console 
or from the CLI  would be confusing because of the many (seemingly redundant) 
entries.  Therefore the collection of Geronimo plugins is distributed across a 
set of catalogs, one per version of Geronimo, and each version of Geronimo 
points at a version specific plugin catalog.

Modifying the plugin schema so that a plugin element can allow the plugin's 
module-id and source-repository to depend on the geronimo-version would allow 
there to be much fewer entries in a consolidated plugin catalog.  A plugin 
catalog that is created using this modified schema might look something like 
(this is just a sample) :

plugin
geronimo-version version=1.1

module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.1/car/module-id

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/source-repository
/geronimo-version
geronimo-version version=1.2

module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.2/car/module-id

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/source-repository
/geronimo-version
geronimo-version version=2.0

module-idorg.apache.geronimo.configs/ca-helper-tomcat/2.0/car/module-id

source-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/source-repository
/geronimo-version
[...]
/plugin

Also, for this to work a customized list of prerequisite elements would 
probably have to be supported inside the geronimo-version element as well, 
since those might also be version specific.

Once this improvement is in place it will be easier to maintain Geronimo's 
plugin collection since each version of Geronimo won't require a separate 
catalog.  Also it will be easier for end users and other external sources to 
refer to Geronimo's plugin catalog since the repository URL will no longer be 
version specific.

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




[jira] Created: (AMQ-1134) stomp connections in the broker don't get cleared up if the socket dies

2007-01-19 Thread james strachan (JIRA)
stomp connections in the broker don't get cleared up if the socket dies
---

 Key: AMQ-1134
 URL: https://issues.apache.org/activemq/browse/AMQ-1134
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1.1, 4.2.0


it looks like there's a bug causing the connection to keep around 

-- 
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] Resolved: (AMQ-1134) stomp connections in the broker don't get cleared up if the socket dies

2007-01-19 Thread james strachan (JIRA)

 [ 
https://issues.apache.org/activemq/browse/AMQ-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

james strachan resolved AMQ-1134.
-

Resolution: Fixed

 stomp connections in the broker don't get cleared up if the socket dies
 ---

 Key: AMQ-1134
 URL: https://issues.apache.org/activemq/browse/AMQ-1134
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1.1, 4.2.0


 it looks like there's a bug causing the connection to keep around 

-- 
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] Resolved: (AMQ-1067) Stomp consumer not removed if client does not send disconnect message.

2007-01-19 Thread james strachan (JIRA)

 [ 
https://issues.apache.org/activemq/browse/AMQ-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

james strachan resolved AMQ-1067.
-

   Resolution: Fixed
Fix Version/s: 4.2.0
   4.1.1

 Stomp consumer not removed if client does not send disconnect message.
 --

 Key: AMQ-1067
 URL: https://issues.apache.org/activemq/browse/AMQ-1067
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.1.0
 Environment: Solaris 10, Perl 5.8.4
Reporter: Chris Knight
Priority: Critical
 Fix For: 4.1.1, 4.2.0

 Attachments: perl.tar.gz


 Run clearQueue.pl TEST.QUEUE
 Check in jconsole. The client will still be marked as active even when the 
 script is killed. This prevents any meaningful use of queues if any 
 consumption is done via stomp.

-- 
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] Closed: (GERONIMODEVTOOLS-122) When creating geronimo-web.xml from scratch using Plug-in Form Editor, the Dependencies view doesn't show the just added dependency

2007-01-19 Thread Sachin Patel (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sachin Patel closed GERONIMODEVTOOLS-122.
-

   Resolution: Fixed
Fix Version/s: (was: 1.2.0)
   1.2.1

Path applied. Thank you.

 When creating geronimo-web.xml from scratch using Plug-in Form Editor, the 
 Dependencies view doesn't show the just added dependency
 -

 Key: GERONIMODEVTOOLS-122
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.2.1
Reporter: Shiva Kumar H R
 Assigned To: Sachin Patel
Priority: Critical
 Fix For: 1.2.1

 Attachments: GERONIMODEVTOOLS-122.patch


 Follow these steps to re-create the problem:
 1) Create a new dynamic web project (don't use import of an existing project, 
 this scenario requires that no sys:dependencies element is present in 
 geronimo-web.xml)
 2) Open geronimo-web.xml in Geronimo Deployment Plan Editor
 3) Switch to Deployment tab
 4) Under Dependecies section click on Add
 5) Enter values and click Finish
 6) You will see that Dependencies view doesn't show the just added 
 dependency
 Only upon Save, Close and Re-open of geronimo-web.xml you will be able to 
 see the added dependencies.
 The patch included solves this problem by updating the performFinish() 
 function of class org.apache.geronimo.st.v11.ui.wizards.DependencyWizard. 
 Functionality of performFinish() function of class 
 org.apache.geronimo.st.v11.ui.wizards.SecurityRoleWizard is used as the 
 hint for coming up with this patch.

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




Build failure

2007-01-19 Thread Hernan Cunico

Hi All,
I have been consistently having this build failure all day while building from 
trunk rev #497879.

For the record I have removed several times the entire local .m2 repo and did 
brand new svn co on totally different directories. This problem shows up on my 
Windows XP box (which I rebooted a number of times also just to make sure)

Here is the last piece of the log with the error I am consistently getting. I 
am building Geronimo with either mvn install, mvn clean install or mvn -U clean 
install

Any pointer will be greatly appreciated, so far I can't figure out what the 
problem is.

Cheers!
Hernan

Compiling 15 source files to d:\trunk\modules\geronimo-openejb\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar to 
C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO] 

[INFO] [tools:require-java-version {execution: validate-java-version}]
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository apache-incubating-repository 
(http://people.apache.org/repo/m2-incubating-repository)
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading 
C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom;
 error in opening zip file
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] XmlBeans compile failed:
xml ErrorLoading schema file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd
xml ErrorLoading config file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO] 

d:\trunk


































Re: Build failure

2007-01-19 Thread Prasad Kashyap

Hernan,

Can you please post the stacktrace of the mvn -e command ? Maybe
something in the trace  can help us decipher what's actually going on.

Cheers
Prasad

On 1/19/07, Hernan Cunico [EMAIL PROTECTED] wrote:

Hi All,
I have been consistently having this build failure all day while building from 
trunk rev #497879.

For the record I have removed several times the entire local .m2 repo and did 
brand new svn co on totally different directories. This problem shows up on my 
Windows XP box (which I rebooted a number of times also just to make sure)

Here is the last piece of the log with the error I am consistently getting. I 
am building Geronimo with either mvn install, mvn clean install or mvn -U clean 
install

Any pointer will be greatly appreciated, so far I can't figure out what the 
problem is.

Cheers!
Hernan

Compiling 15 source files to d:\trunk\modules\geronimo-openejb\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar to 
C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO] 

[INFO] [tools:require-java-version {execution: validate-java-version}]
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
[WARNING] Unable to get resource from repository apache-incubating-repository 
(http://people.apache.org/repo/m2-incubating-repository)
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading 
C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom;
 error in opening zip file
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] XmlBeans compile failed:
 xml ErrorLoading schema file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd
xml ErrorLoading config file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO] 

d:\trunk



































Re: [jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Jason Warner

I have been looking into this issue and would like to continue doing so.  I
seem to lack the ability to assign jira's to myself, though.  How would I go
about gaining this ability?  Thanks.

Jason Warner


Re: Build failure

2007-01-19 Thread anita kulshreshtha
   Since you have tried everything else, try cleaning the disk, i.e.
the windows TEMP dir.

Thanks
Anita

--- Hernan Cunico [EMAIL PROTECTED] wrote:

 Hi All,
 I have been consistently having this build failure all day while
 building from trunk rev #497879.
 
 For the record I have removed several times the entire local .m2 repo
 and did brand new svn co on totally different directories. This
 problem shows up on my Windows XP box (which I rebooted a number of
 times also just to make sure)
 
 Here is the last piece of the log with the error I am consistently
 getting. I am building Geronimo with either mvn install, mvn clean
 install or mvn -U clean install
 
 Any pointer will be greatly appreciated, so far I can't figure out
 what the problem is.
 
 Cheers!
 Hernan
 
 Compiling 15 source files to
 d:\trunk\modules\geronimo-openejb\target\classes
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Not compiling test sources
 [INFO] [surefire:test]
 [INFO] Tests are skipped.
 [INFO] [jar:jar]
 [INFO] Building jar:

d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar
 [INFO] [install:install]
 [INFO] Installing

d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar
 to

C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar
 [INFO]


 [INFO] Building Geronimo :: OpenEJB :: Builder
 [INFO]task-segment: [install]
 [INFO]


 [INFO] [tools:require-java-version {execution:
 validate-java-version}]
 Downloading:

http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
 [WARNING] Unable to get resource from repository apache-incubator
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading:

http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
 [WARNING] Unable to get resource from repository codehaus
 (http://repository.codehaus.org)
 Downloading:

http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
 [WARNING] Unable to get resource from repository
 apache-incubating-repository
 (http://people.apache.org/repo/m2-incubating-repository)
 Downloading:

http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar
 19K downloaded
 [INFO] [xmlbeans:xmlbeans {execution: default}]
 Time to build schema type system: 0.078 seconds
 Time to generate code: 0.437 seconds
 error: error reading

C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom;
 error in opening zip file
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 1 error
 
 BUILD FAILED
 [INFO]


 [ERROR] BUILD ERROR
 [INFO]


 [INFO] XmlBeans compile failed:
  xml ErrorLoading schema file

d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd
 xml ErrorLoading config file

d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml
 
 [INFO]


 [INFO] For more information, run Maven with the -e switch
 [INFO]


 [INFO] Total time: 3 minutes 47 seconds
 [INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
 [INFO] Final Memory: 56M/110M
 [INFO]


 
 d:\trunk
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 




 

Need Mail bonding?
Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=listsid=396546091


[jira] Created: (GERONIMO-2758) Upgrade to Howl 1.0.2

2007-01-19 Thread Donald Woods (JIRA)
Upgrade to Howl 1.0.2
-

 Key: GERONIMO-2758
 URL: https://issues.apache.org/jira/browse/GERONIMO-2758
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: dependencies
Affects Versions: 2.0
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 2.0-beta1


Howl 1.0.2 was released on 2007-01-02, but has not been published to the m2 
repo yet.
Will attach a patch once the jar is available on the default m2 repo.

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




Re: [jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Kevan Miller


On Jan 19, 2007, at 2:40 PM, Jason Warner wrote:

I have been looking into this issue and would like to continue  
doing so.  I seem to lack the ability to assign jira's to myself,  
though.  How would I go about gaining this ability?  Thanks.


Jason,
That's great. What's your jira username?

--kevan




[jira] Created: (GERONIMO-2759) Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 release

2007-01-19 Thread Donald Woods (JIRA)
Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 release
---

 Key: GERONIMO-2759
 URL: https://issues.apache.org/jira/browse/GERONIMO-2759
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: JVM-compatibility
Affects Versions: 2.0-M1
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 2.0-M2


We need to re-enable the JVMCheck call in Daemon.java to warn Java 1.4 or Java 
6 users that Java SE 5 is required.
JEE 5 requires a Java SE 5 or later JVM.
A recent 1/9/07 posting on the users list mentioned that Java 6 will not work, 
due to a javax.xml.stream.FactoryConfigurationError and a Stax implementation 
included in Java 6.


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




Re: [jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Jason Warner

My jira username is jawarner.  Thanks, Kevan

Jason

On 1/19/07, Kevan Miller [EMAIL PROTECTED] wrote:



On Jan 19, 2007, at 2:40 PM, Jason Warner wrote:

 I have been looking into this issue and would like to continue
 doing so.  I seem to lack the ability to assign jira's to myself,
 though.  How would I go about gaining this ability?  Thanks.

Jason,
That's great. What's your jira username?

--kevan





Re: Build failure

2007-01-19 Thread Hernan Cunico

yeah, tried that one too. didn't work either.

Cheers!
Hernan

anita kulshreshtha wrote:

   Since you have tried everything else, try cleaning the disk, i.e.
the windows TEMP dir.

Thanks
Anita

--- Hernan Cunico [EMAIL PROTECTED] wrote:


Hi All,
I have been consistently having this build failure all day while
building from trunk rev #497879.

For the record I have removed several times the entire local .m2 repo
and did brand new svn co on totally different directories. This
problem shows up on my Windows XP box (which I rebooted a number of
times also just to make sure)

Here is the last piece of the log with the error I am consistently
getting. I am building Geronimo with either mvn install, mvn clean
install or mvn -U clean install

Any pointer will be greatly appreciated, so far I can't figure out
what the problem is.

Cheers!
Hernan

Compiling 15 source files to
d:\trunk\modules\geronimo-openejb\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar:


d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar

[INFO] [install:install]
[INFO] Installing


d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar

to


C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar

[INFO]




[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO]




[INFO] [tools:require-java-version {execution:
validate-java-version}]
Downloading:


http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar

[WARNING] Unable to get resource from repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:


http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar

[WARNING] Unable to get resource from repository codehaus
(http://repository.codehaus.org)
Downloading:


http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar

[WARNING] Unable to get resource from repository
apache-incubating-repository
(http://people.apache.org/repo/m2-incubating-repository)
Downloading:


http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar

19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading


C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom;

error in opening zip file
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO]




[ERROR] BUILD ERROR
[INFO]




[INFO] XmlBeans compile failed:
 xml ErrorLoading schema file


d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd

xml ErrorLoading config file


d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml

[INFO]




[INFO] For more information, run Maven with the -e switch
[INFO]




[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO]




d:\trunk






































 


Need Mail bonding?
Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=listsid=396546091



[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception

2007-01-19 Thread David Jencks (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466135
 ] 

David Jencks commented on GERONIMO-1585:


Fix for /* applied in rev 497925 in 1.2 and rev 497904.  I have not yet 
investigated whether the other problems discussed here are in fact transferred 
to other jira issues.

 Web app security on /* causes deployment exception
 --

 Key: GERONIMO-1585
 URL: https://issues.apache.org/jira/browse/GERONIMO-1585
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security, web
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
 Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
 Assigned To: David Jencks
Priority: Critical
 Fix For: 1.1.x, 1.2, 2.0-M2

 Attachments: G1585-Geronimo2.0.patch, g1585-nologin.war, g1585.war, 
 security.patch


 Deploying a web app with the following security block causes a deployment 
 error:
 security-constraint
 web-resource-collection
 web-resource-nameAll Pages/web-resource-name
 url-pattern/*/url-pattern
 http-methodGET/http-method
 http-methodPOST/http-method
 http-methodPUT/http-method
 /web-resource-collection
 auth-constraint
 role-nameUser/role-name
 /auth-constraint
 /security-constraint
 Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
 2.4 spec).
 The error is:
 org.apache.geronimo.common.DeploymentException: Unable to initialize 
 webapp GBean
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
 ...
 Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
 URLPatternSpec cannot match the first URLPattern
 at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
 at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
 at 
 org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
 ... 70 more
 Changing the url-pattern to / fixes the problem, but it seems to me that /* 
 ought to work too.

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




Re: [jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Kevan Miller


On Jan 19, 2007, at 2:57 PM, Jason Warner wrote:


My jira username is jawarner.  Thanks, Kevan


OK. You should have contributor access to our Jira database. Let us  
know if you have any problems.


--kevan



Re: Build failure

2007-01-19 Thread Kevan Miller


On Jan 19, 2007, at 3:00 PM, Hernan Cunico wrote:


yeah, tried that one too. didn't work either.


What're your maven and java version numbers?

--kevan


Re: Build failure

2007-01-19 Thread Donald Woods
I just built Rev497904 on my XP laptop and didn't run into any problems, 
but I didn't start with a clean repo.  I only cleaned the 
org\apache\axis2 and org\apache\geronimo directories from the repo 
first, built the latest openejb3 code locally and then built the latest 
server code.


-Donald

Hernan Cunico wrote:

Hi All,
I have been consistently having this build failure all day while 
building from trunk rev #497879.


For the record I have removed several times the entire local .m2 repo 
and did brand new svn co on totally different directories. This problem 
shows up on my Windows XP box (which I rebooted a number of times also 
just to make sure)


Here is the last piece of the log with the error I am consistently 
getting. I am building Geronimo with either mvn install, mvn clean 
install or mvn -U clean install


Any pointer will be greatly appreciated, so far I can't figure out what 
the problem is.


Cheers!
Hernan

Compiling 15 source files to 
d:\trunk\modules\geronimo-openejb\target\classes

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar

[INFO] [install:install]
[INFO] Installing 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 
to 
C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar 

[INFO] 
 


[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO] 
 


[INFO] [tools:require-java-version {execution: validate-java-version}]
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository 
apache-incubating-repository 
(http://people.apache.org/repo/m2-incubating-repository)
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 


19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading 
C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom; 
error in opening zip file

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] XmlBeans compile failed:
xml ErrorLoading schema file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd 

xml ErrorLoading config file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml


[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 


[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO] 



d:\trunk




































smime.p7s
Description: S/MIME Cryptographic Signature


[jira] Assigned: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread David Jencks (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks reassigned GERONIMO-2756:
--

Assignee: David Jencks

 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Assigned To: David Jencks
 Attachments: GERONIMO-2756.patch




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




Re: [jira] Created: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Jason Warner

Worked perfectly.  Thanks, again.

On 1/19/07, Kevan Miller [EMAIL PROTECTED] wrote:



On Jan 19, 2007, at 2:57 PM, Jason Warner wrote:

 My jira username is jawarner.  Thanks, Kevan

OK. You should have contributor access to our Jira database. Let us
know if you have any problems.

--kevan




[jira] Assigned: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin

2007-01-19 Thread Jason Warner (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Warner reassigned GERONIMO-2757:
--

Assignee: Jason Warner

 Enhance plugin schema to allow for multiple versions of a plugin
 

 Key: GERONIMO-2757
 URL: https://issues.apache.org/jira/browse/GERONIMO-2757
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Plugins
Affects Versions: 2.0
Reporter: Paul McMahan
 Assigned To: Jason Warner

 plugins-1.1.xsd currently allows for a single version of a plugin to be 
 described from within a plugin element.   For example, if there were a 
 different version of plugin for each version of geronimo then the plugin 
 catalog would like something like:
 plugin
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.1/car/module-id
 geronimo-version1.1/geronimo-version
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/source-repository
 [...]
 /plugin
 plugin
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.2/car/module-id
 geronimo-version1.2/geronimo-version
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/source-repository
 [...]
 /plugin
 plugin
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/2.0/car/module-id
 geronimo-version2.0/geronimo-version
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/source-repository
 [...]
 /plugin
 default-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/default-repository
 default-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/default-repository
 default-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/default-repository
 Plugins are usually not compatible across versions of Geronimo for various 
 reasons, probably the most prominent of which is Geronimo's reliance on 
 serialized java objects in CAR files.  Browsing a catalog that contains a 
 plugin element for each version of Geronimo's plugins from the  admin 
 console or from the CLI  would be confusing because of the many (seemingly 
 redundant) entries.  Therefore the collection of Geronimo plugins is 
 distributed across a set of catalogs, one per version of Geronimo, and each 
 version of Geronimo points at a version specific plugin catalog.
 Modifying the plugin schema so that a plugin element can allow the plugin's 
 module-id and source-repository to depend on the geronimo-version would 
 allow there to be much fewer entries in a consolidated plugin catalog.  A 
 plugin catalog that is created using this modified schema might look 
 something like (this is just a sample) :
 plugin
 geronimo-version version=1.1
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.1/car/module-id
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.1/source-repository
 /geronimo-version
 geronimo-version version=1.2
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/1.2/car/module-id
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-1.2/source-repository
 /geronimo-version
 geronimo-version version=2.0
 
 module-idorg.apache.geronimo.configs/ca-helper-tomcat/2.0/car/module-id
 
 source-repositoryhttp://geronimo.apache.org/plugins/geronimo-2.0/source-repository
 /geronimo-version
 [...]
 /plugin
 Also, for this to work a customized list of prerequisite elements would 
 probably have to be supported inside the geronimo-version element as well, 
 since those might also be version specific.
 Once this improvement is in place it will be easier to maintain Geronimo's 
 plugin collection since each version of Geronimo won't require a separate 
 catalog.  Also it will be easier for end users and other external sources to 
 refer to Geronimo's plugin catalog since the repository URL will no longer be 
 version specific.

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




[jira] Closed: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread David Jencks (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-2756.
--

Fix Version/s: 2.0-M2

forgot fix version...

 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Assigned To: David Jencks
 Fix For: 2.0-M2

 Attachments: GERONIMO-2756.patch




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




[jira] Closed: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread David Jencks (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-2756.
--

Resolution: Fixed

Applied with slight changes in rev 497935.

- corrected spelling of JNDIResourceResolver class
- left out change to tomcat builder, it looked to me as if it did nothing 
differently.

many thanks!

 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Assigned To: David Jencks
 Attachments: GERONIMO-2756.patch




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




Re: Build failure

2007-01-19 Thread Hernan Cunico

Here is the trace from an earlier build from today. Still see the very same 
error

http://rifers.org/paste/show/3296

Cheers!
Hernan

Prasad Kashyap wrote:

Hernan,

Can you please post the stacktrace of the mvn -e command ? Maybe
something in the trace  can help us decipher what's actually going on.

Cheers
Prasad

On 1/19/07, Hernan Cunico [EMAIL PROTECTED] wrote:

Hi All,
I have been consistently having this build failure all day while 
building from trunk rev #497879.


For the record I have removed several times the entire local .m2 repo 
and did brand new svn co on totally different directories. This 
problem shows up on my Windows XP box (which I rebooted a number of 
times also just to make sure)


Here is the last piece of the log with the error I am consistently 
getting. I am building Geronimo with either mvn install, mvn clean 
install or mvn -U clean install


Any pointer will be greatly appreciated, so far I can't figure out 
what the problem is.


Cheers!
Hernan

Compiling 15 source files to 
d:\trunk\modules\geronimo-openejb\target\classes

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 


[INFO] [install:install]
[INFO] Installing 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 
to 
C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar 

[INFO] 
 


[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO] 
 


[INFO] [tools:require-java-version {execution: validate-java-version}]
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository 
apache-incubating-repository 
(http://people.apache.org/repo/m2-incubating-repository)
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 


19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading 
C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom; 
error in opening zip file

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] XmlBeans compile failed:
 xml ErrorLoading schema file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd 

xml ErrorLoading config file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml


[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 


[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO] 



d:\trunk





































Re: Build failure

2007-01-19 Thread Hernan Cunico

Here is the info, hopefully one of these is the one causing the headache.

d:\trunkjava -version
java version 1.5.0_10
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing)

d:\trunkmvn -v
Maven version: 2.0.4


Cheers!
Hernan

Kevan Miller wrote:


On Jan 19, 2007, at 3:00 PM, Hernan Cunico wrote:


yeah, tried that one too. didn't work either.


What're your maven and java version numbers?

--kevan



[jira] Commented: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread Jarek Gawor (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466141
 ] 

Jarek Gawor commented on GERONIMO-2756:
---

The Tomcat change is required otherwise the at the time configurePOJO() method 
is called the moduleGBean is not added yet to the DeploymentContext. If you 
look at the JettyModuleBuilder the moduleGBean is added right away and 
therefore is visible to CXFBuilder when configurePOJO() method is called.


 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Assigned To: David Jencks
 Fix For: 2.0-M2

 Attachments: GERONIMO-2756.patch




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




Re: Build failure

2007-01-19 Thread Hernan Cunico

Did anybody on windows totally nuked the local repo and tried to build from 
scratch?

even if I try to build openejb first I get this error.

Cheers!
Hernan

Donald Woods wrote:
I just built Rev497904 on my XP laptop and didn't run into any problems, 
but I didn't start with a clean repo.  I only cleaned the 
org\apache\axis2 and org\apache\geronimo directories from the repo 
first, built the latest openejb3 code locally and then built the latest 
server code.


-Donald

Hernan Cunico wrote:

Hi All,
I have been consistently having this build failure all day while 
building from trunk rev #497879.


For the record I have removed several times the entire local .m2 repo 
and did brand new svn co on totally different directories. This 
problem shows up on my Windows XP box (which I rebooted a number of 
times also just to make sure)


Here is the last piece of the log with the error I am consistently 
getting. I am building Geronimo with either mvn install, mvn clean 
install or mvn -U clean install


Any pointer will be greatly appreciated, so far I can't figure out 
what the problem is.


Cheers!
Hernan

Compiling 15 source files to 
d:\trunk\modules\geronimo-openejb\target\classes

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 


[INFO] [install:install]
[INFO] Installing 
d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 
to 
C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-openejb-2.0-SNAPSHOT.jar 

[INFO] 
 


[INFO] Building Geronimo :: OpenEJB :: Builder
[INFO]task-segment: [install]
[INFO] 
 


[INFO] [tools:require-java-version {execution: validate-java-version}]
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

[WARNING] Unable to get resource from repository 
apache-incubating-repository 
(http://people.apache.org/repo/m2-incubating-repository)
Downloading: 
http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 


19K downloaded
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.078 seconds
Time to generate code: 0.437 seconds
error: error reading 
C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-incubating-SNAPSHOT.pom; 
error in opening zip file

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] XmlBeans compile failed:
xml ErrorLoading schema file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2.0.xsd 

xml ErrorLoading config file 
d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml


[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 


[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
[INFO] Final Memory: 56M/110M
[INFO] 



d:\trunk




































Re: Using JIRA

2007-01-19 Thread Alan D. Cabrera


On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote:


Howdy,
it may sound weird asking this now but I'm either creating JIRAs  
the wrong way or we are not displaying the all the info in http:// 
issues.apache.org/jira/browse/geronimo (or I just don't know how to  
read it)


On the JIRA front page for GERONIMO you can see open issues due to  
be fixed per version.
When I create a JIRA for a specific version I normally specify the  
affected version (let's say 2.0-M2) in the *Affects Version/s:*  
box and leave the *Fix Version/s:* empty as I don't really know for  
sure when that issue is going to be fixed unless I am the assignee.


This issue I just created does not get listed (counted actually)  
for that particular version in the project's JIRA home page.


Is this query is automatically provided by JIRA or we can customize  
it to show the affected version instead?
At this particular point in time the actual setting show 5 open  
issues, if we could change it to affected versions it would show 16.


Does this make any sense at all?

Again, it might be just me not really understanding how to use JIRAs.

Comments appreciated


I think that Jira is working correctly as is.  It should not show up  
on the radar, http://issues.apache.org/jira/browse/geronimo, until  
someone makes a commitment to fixing it for a particular release at  
which time the issue gets assigned Fix Version/s.  If you look at  
the description below the Versions column on the home page you will  
see with open issues due to be fixed per version.  This indicates  
that someone has made a commitment to complete the issue for that  
version.


You can make your own personal report and add it to your personalized  
portal page.



Regards,
Alan




[jira] Updated: (GERONIMO-2759) Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 release

2007-01-19 Thread Donald Woods (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-2759:
---

Attachment: G2759.patch

 Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 
 release
 ---

 Key: GERONIMO-2759
 URL: https://issues.apache.org/jira/browse/GERONIMO-2759
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: JVM-compatibility
Affects Versions: 2.0-M1
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 2.0-M2

 Attachments: G2759.patch


 We need to re-enable the JVMCheck call in Daemon.java to warn Java 1.4 or 
 Java 6 users that Java SE 5 is required.
 JEE 5 requires a Java SE 5 or later JVM.
 A recent 1/9/07 posting on the users list mentioned that Java 6 will not 
 work, due to a javax.xml.stream.FactoryConfigurationError and a Stax 
 implementation included in Java 6.

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




[jira] Updated: (GERONIMO-2759) Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 release

2007-01-19 Thread Donald Woods (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-2759:
---

Patch Info: [Patch Available]
  Assignee: (was: Donald Woods)

Patch was created against server/trunk directory and will warn non Java 1.5 
users that they are using an unsupported Java version.

 Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 
 release
 ---

 Key: GERONIMO-2759
 URL: https://issues.apache.org/jira/browse/GERONIMO-2759
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: JVM-compatibility
Affects Versions: 2.0-M1
Reporter: Donald Woods
Priority: Minor
 Fix For: 2.0-M2

 Attachments: G2759.patch


 We need to re-enable the JVMCheck call in Daemon.java to warn Java 1.4 or 
 Java 6 users that Java SE 5 is required.
 JEE 5 requires a Java SE 5 or later JVM.
 A recent 1/9/07 posting on the users list mentioned that Java 6 will not 
 work, due to a javax.xml.stream.FactoryConfigurationError and a Stax 
 implementation included in Java 6.

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




[jira] Created: (GERONIMO-2760) Upgrade tomcat to version 6.0.8a

2007-01-19 Thread Paul McMahan (JIRA)
Upgrade tomcat to version 6.0.8a


 Key: GERONIMO-2760
 URL: https://issues.apache.org/jira/browse/GERONIMO-2760
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
  Components: Tomcat
Affects Versions: 2.0-M2
Reporter: Paul McMahan
 Assigned To: Paul McMahan
 Fix For: 2.0-M2


Upgrade to tomcat 6.0.8a.  Also discontinue usage of snapshot version by 
enabling tomcat's new m2 repo at 
http://tomcat.apache.org/dev/dist/m2-repository/

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




Re: new maven repository for tomcat

2007-01-19 Thread Paul McMahan

I'll go ahead and add tomcat's m2 repo to the root pom and bump the
version to 6.0.8.  If there are any concerns with that approach then
please let me know and I'll move the repo to the specific modules.
We can remove this reference altogether when tomcat starts deploying
to the ASF ibiblio sync repo.

Best wishes,
Paul

On 1/19/07, Paul McMahan [EMAIL PROTECTED] wrote:

In Filip's post on [EMAIL PROTECTED] :
http://www.nabble.com/Tomcat-Jars---Maven2-repo-tf3023226.html#a8397986
  We can run with this setup for a while, once outside folks are happy
  with the release jars, we can start deploying to ASF Ibiblio sync
  repo, so they get copied to the central repository.



On 1/19/07, Jeff Genender [EMAIL PROTECTED] wrote:
 Is there a reason they won't post them to the usual places to get picked
 up by ibiblio?

 Jeff

 Paul McMahan wrote:
  The tomcat6 jars are currently being imported into geronimo from the
  apache snapshot repo.  The tomcat team is now also publishing
  officially released jars to a maven repo at
  http://tomcat.apache.org/dev/dist/m2-repository (thanks Filip!).  I
  would like to import the jars from that repo instead of the snapshot
  repo so we can avoid using snapshot versions.  Is it OK to enable the
  tomcat repo in the root pom or should I only enable it in the specific
  module(s) that needs it?  I prefer to enable in the root pom but as I
  recall adding new repos has caused some problems in the past.
 
  Best wishes,
  Paul




[jira] Created: (GERONIMO-2761) Upgrade to Log4J 1.2.14 maintenance release

2007-01-19 Thread Donald Woods (JIRA)
Upgrade to Log4J 1.2.14 maintenance release
---

 Key: GERONIMO-2761
 URL: https://issues.apache.org/jira/browse/GERONIMO-2761
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Logging
Affects Versions: 2.0-M2
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 2.0-beta1


The Log4J project released v1.2.14 last Sept., which includes several bug fixes 
worth picking up - http://logging.apache.org/log4j/docs/download.html

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




[jira] Commented: (AMQ-1038) Incorrect redelivery behavior and counters

2007-01-19 Thread Barry Kaplan (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37938
 ] 

Barry Kaplan commented on AMQ-1038:
---

Any chance that this will get some attention? The current behavior pretty much 
requires that redelivery be implemented in client code by incrementing a 
message property and putting a cloned message back on the queue.

 Incorrect redelivery behavior and counters
 --

 Key: AMQ-1038
 URL: https://issues.apache.org/activemq/browse/AMQ-1038
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
 Environment: Windows XP Pro
 java version 1.5.0_06
Reporter: Steve Bate
 Attachments: RedeliveryTest.java


 Our understanding is that the RedeliveryPolicy maxRedeliveryCount controls 
 the maximum number of times a message will be redelivered (assumed to be a 
 global count and not a per-consumer count). The behavior we are seeing is 
 that messages are redelivered more times than we specified. The problem may 
 be related to the way the redelivery counter is being maintained. We see the 
 redelivery counter incrementing by one for redeliveries to a specific 
 consumer, but then it resets to a lower number when the message is 
 redelivered to a different consumer.
 I have attached a test case to demonstrate the problem. The first test is a 
 simple baseline example that passes. The second test shows that messages are 
 being redelivered too many times for the redelivery policy. The third tests 
 catches a regression in the delivery count (redelivery count + 1) when 
 sending a rolled back message to a new consumer.
 The test suite uses an embedded broker using the VM protocol so it should be 
 standalone.

-- 
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: Build failure

2007-01-19 Thread Lin Sun

I just did on my winxp laptop and finally got a successful build (with rev
497935).  I had a few failures (different than yours) earlier on, so I wiped
out the local repo and rechecked out Geronimo\trunk.   

lin
-Original Message-
From: Hernan Cunico [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 19, 2007 3:25 PM
To: dev@geronimo.apache.org
Subject: Re: Build failure

Did anybody on windows totally nuked the local repo and tried to build from
scratch?

even if I try to build openejb first I get this error.

Cheers!
Hernan

Donald Woods wrote:
 I just built Rev497904 on my XP laptop and didn't run into any problems, 
 but I didn't start with a clean repo.  I only cleaned the 
 org\apache\axis2 and org\apache\geronimo directories from the repo 
 first, built the latest openejb3 code locally and then built the latest 
 server code.
 
 -Donald
 
 Hernan Cunico wrote:
 Hi All,
 I have been consistently having this build failure all day while 
 building from trunk rev #497879.

 For the record I have removed several times the entire local .m2 repo 
 and did brand new svn co on totally different directories. This 
 problem shows up on my Windows XP box (which I rebooted a number of 
 times also just to make sure)

 Here is the last piece of the log with the error I am consistently 
 getting. I am building Geronimo with either mvn install, mvn clean 
 install or mvn -U clean install

 Any pointer will be greatly appreciated, so far I can't figure out 
 what the problem is.

 Cheers!
 Hernan

 Compiling 15 source files to 
 d:\trunk\modules\geronimo-openejb\target\classes
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Not compiling test sources
 [INFO] [surefire:test]
 [INFO] Tests are skipped.
 [INFO] [jar:jar]
 [INFO] Building jar: 

d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 

 [INFO] [install:install]
 [INFO] Installing 

d:\trunk\modules\geronimo-openejb\target\geronimo-openejb-2.0-SNAPSHOT.jar 
 to 

C:\.m2\org\apache\geronimo\modules\geronimo-openejb\2.0-SNAPSHOT\geronimo-op
enejb-2.0-SNAPSHOT.jar 

 [INFO] 




 [INFO] Building Geronimo :: OpenEJB :: Builder
 [INFO]task-segment: [install]
 [INFO] 




 [INFO] [tools:require-java-version {execution: validate-java-version}]
 Downloading: 

http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/
specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_
spec-1.0-M1.jar 

 [WARNING] Unable to get resource from repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 

http://repository.codehaus.org/org/apache/geronimo/specs/geronimo-j2ee-manag
ement_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

 [WARNING] Unable to get resource from repository codehaus 
 (http://repository.codehaus.org)
 Downloading: 

http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/s
pecs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_s
pec-1.0-M1.jar 

 [WARNING] Unable to get resource from repository 
 apache-incubating-repository 
 (http://people.apache.org/repo/m2-incubating-repository)
 Downloading: 

http://repo.mergere.com/maven2/org/apache/geronimo/specs/geronimo-j2ee-manag
ement_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.jar 

 19K downloaded
 [INFO] [xmlbeans:xmlbeans {execution: default}]
 Time to build schema type system: 0.078 seconds
 Time to generate code: 0.437 seconds
 error: error reading 

C:\.m2\org\apache\openejb\container\3.0-incubating-SNAPSHOT\container-3.0-in
cubating-SNAPSHOT.pom; 
 error in opening zip file
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 1 error

 BUILD FAILED
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] XmlBeans compile failed:
 xml ErrorLoading schema file 

d:\trunk\modules\geronimo-openejb-builder\src\main\schema\geronimo-openejb-2
.0.xsd 

 xml ErrorLoading config file 
 d:\trunk\modules\geronimo-openejb-builder\src\main\schema\xmlconfig.xml

 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 3 minutes 47 seconds
 [INFO] Finished at: Fri Jan 19 13:57:50 EST 2007
 [INFO] Final Memory: 56M/110M
 [INFO] 
 

 d:\trunk





































[jira] Assigned: (GERONIMO-2761) Upgrade to Log4J 1.2.14 maintenance release

2007-01-19 Thread Jason Dillon (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon reassigned GERONIMO-2761:
--

Assignee: Jason Dillon  (was: Donald Woods)

 Upgrade to Log4J 1.2.14 maintenance release
 ---

 Key: GERONIMO-2761
 URL: https://issues.apache.org/jira/browse/GERONIMO-2761
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Logging
Affects Versions: 2.0-M2
Reporter: Donald Woods
 Assigned To: Jason Dillon
Priority: Minor
 Fix For: 2.0-beta1


 The Log4J project released v1.2.14 last Sept., which includes several bug 
 fixes worth picking up - http://logging.apache.org/log4j/docs/download.html

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




Re: New Samples Framework for Geronimo.

2007-01-19 Thread Matt Hogstrom
Very nice...I like the idea of standalone samples.  Without getting  
into the specs debate yet again ... but most likely will ... I like  
the samples released with the version of the server so people can  
pick up one version and know what its for.  I think the organization  
for now is great as we can get the actual work done on the samples  
while we debate how to organize them for the next several months.   
Good job !  :)



On Jan 19, 2007, at 12:22 PM, Prasad Kashyap wrote:


Encouraged by your kind words of appreciation for the Testsuite
framework, I put together a similar Samples Framework.

http://svn.apache.org/viewvc/geronimo/samples/

UseCase Scenario 1
---
Actor: Geronimo user, JEE5 Developer.

Requirements:
  * Actor wants to learn the new features of JEE5 by looking at  
sample code

  * He wants to play with sample code.
  * He wants to learn how to develop applications on Geronimo.
  * He may want to use the sample code as a template for his own  
application.


Flow A (install downloaded sample binary)
  * Actor downloads a Geronimo server binary  and unpacks it.
  * He then downloads a sample binary.
  * He starts Geronimo server.
  * He then deploys the sample artifact into running server.
  * He goes to the sample app's home page (context-root).

Flow B: (build sample source and install)
  * Actor downloads a sample source package.
  * He installs Maven if he doesn't have it already.
  * He builds the sample project using maven.
  * Sample project automatically downloads the latest Geronimo
server, starts it, and deploys the newly built sample.
  * It fires up a browser and brings up the sample home page  (not
implemented yet).

See the following links in Firefox only !
Here is a page that gives a user instructions on working with samples.
Every sample download will also have a customized  relevant page like
this, say as a README.html
http://people.apache.org/~prasad/samples/index.html

Here is a sample sample page. Notice the javadoc and source tabs in
the top right corner of the page.
http://people.apache.org/~prasad/samples/sample.html


UseCase Scenario 2
---
Actor: Geronimo Developer, JEE5 Spec Implementor

Interactions: Document Writer.

Requirements:
  * Actor wants to create sample projects quickly without having to
deal too much with Maven.

Flow:
  * Actor executes a sample-archetype-plugin.
  * It creates a mvn project which will act as a template.
  * He only has to write JEE5 code for the sample application.
  * He then works with Document Writer to write the sample document.


Cheers
Prasad.



Matt Hogstrom
[EMAIL PROTECTED]




[jira] Closed: (GERONIMO-2761) Upgrade to Log4J 1.2.14 maintenance release

2007-01-19 Thread Jason Dillon (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon closed GERONIMO-2761.
--

   Resolution: Fixed
Fix Version/s: (was: 2.0-beta1)
   2.0-M2
   1.2

Updated trunk and branches/1.2.

Thanks for the attention to detail :-)

 Upgrade to Log4J 1.2.14 maintenance release
 ---

 Key: GERONIMO-2761
 URL: https://issues.apache.org/jira/browse/GERONIMO-2761
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Logging
Affects Versions: 2.0-M2
Reporter: Donald Woods
 Assigned To: Jason Dillon
Priority: Minor
 Fix For: 1.2, 2.0-M2


 The Log4J project released v1.2.14 last Sept., which includes several bug 
 fixes worth picking up - http://logging.apache.org/log4j/docs/download.html

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




Re: GBeanInstance/GBeanInstanceState eating exceptions?

2007-01-19 Thread Jason Dillon
Where are the methods to pass back failure information from  
GBeanInstanceState to GBeanInstance (and so on) ?


I don't see anything like getFailureReason() or anything similar.

How is one supposed to expose the MissingDependencyException that is  
thrown in GBeanInstanceState.attemptFullStart(), which occurs when  
calling gbeanInstance.createInstance() and is then caught and eaten?


I need to propagate this exception detail back further to the  
component that asked for the component to be loaded, and attach the  
detail to the failure exception that is thrown when we ask a  
configuration to load.


What is the api to store and retrieve exceptions later that you mention?

--jason


On Jan 17, 2007, at 10:40 PM, Dain Sundstrom wrote:


I'm not going to try to justify the design, but I'll explain it...

The lifecycle method don't necessarily result in the bean fully  
completing a state change.  The bean may enter a transition state  
like starting or stopping and wait there for a resource to become  
available.  Really, they just initiate  a lifecycle change that  
will complete at a later time.  If the method were to throw an  
exception it would be completely random if it worked or not.   
Therefore, the methods don't throw exceptions and then are supposed  
to store the exception so it can be retrieved later.


The key is that most gbeans are started by the configuration and  
the configuration will gather any failures and throw a single  
exception containing all the problems.


Now if there are places problems occurs and the exceptions aren't  
saved, it is a bug.


-dain

On Jan 17, 2007, at 2:06 PM, Jason Dillon wrote:

Why do GBeanInstance/GBeanInstanceState eat exceptions instead of  
throwing them?


This seems to be a common pattern with GBeans, where they don't  
propagate the exception detail.  I was just looking at  
GBeanInstance.start(), but looks like stop() and other methods  
have the same basic issues.


The lack of detail being propagated results in build failures like:

snip
Configuration gbean failed to start org.apache.geronimo.configs/ 
openejb/2.0-SNAPSHOT/car

/snip

But they show no detail as to why they failed.  This one happens  
to be caused by:


snip
org.apache.geronimo.kernel.repository.MissingDependencyException:  
Unable to resolve dependency org.apache.openejb/openejb-loader//jar
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolve 
InClassLoader(DefaultArtifactResolver.java:123)
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver$ 
$FastClassByCGLIB$$e847b746.invoke(generated)

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
...
/snip

But you would never know that unless you hack up the  
GBeanInstanceState with printlns or something.  There is some  
logging which is done, but that is getting lost due to mismatch in  
log4j and maven logging systems.  I thought I had a bridge setup  
to handle this, but it appears to have been broken for sometime.   
But aside from the logging issue, I think its a bigger problem  
that the GBean stuff is not throwing exceptions with meaningful  
details.


There are other bits which look rather wrong wrt showing exception  
details, like:


snip
try {
kernel.startRecursiveGBean(dependent);
} catch (GBeanNotFoundException e) {
// this is ok the gbean died before we could start it
} catch (Exception e) {
// there is something wrong with this gbean... skip it
}
/snip

There is no log here at all... this exception just gets swallowed up.

This also looks fishy:

snip
try {
// try to create the instance
if (!gbeanInstance.createInstance()) {
// instance is not ready to start... this is normally  
caused by references
// not being available, but could be because someone  
already started the gbean.
// in another thread.  The reference will log a debug  
message about why

// it could not start
return;
}
} catch (Throwable t) {
// oops there was a problem and the gbean failed
log.error(Error while starting; GBean is now in the FAILED  
state: abstractName=\ + abstractName + \, t);

setStateInstance(State.FAILED);
lifecycleBroadcaster.fireFailedEvent();

if (t instanceof Exception) {
// ignore - we only rethrow errors
return;
} else if (t instanceof Error) {
throw (Error) t;
} else {
throw new Error(t);
}
}

// started successfully... notify everyone else
setStateInstance(State.RUNNING);
lifecycleBroadcaster.fireRunningEvent();
/snip

The catch here is actually what was handling the above  
MissingDependencyException, which sets the state to failed,  
broadcasts the event, then eats the exception, and then continues  
to set the state to running and broadcasts that event, which  
should fail on the state transition of FAILED - RUNNING... but we  
should not even be attempting that transition because of the  
caught exception.


The 

Re: New Samples Framework for Geronimo.

2007-01-19 Thread Jason Dillon
Why are there reporting elements in the architype (and also in the  
first sample), which are not at the top-level, but are in calculator- 
stateless-pojo?


Why does this project not inherit from genesis project-config?

Why is the geronimo-maven-plugin configured here?

And why on earth are there sources (CalculatorServlet) checked in with:

snip
/*
* Copyright 2002 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
/snip

:-(

And you should use the released dependencies you are referencing in  
he top-level pom, better yet depend on some part of Geronimo to pick  
those up transitively so don't have to work about keeping the  
versions in sync with a Geronimo version.


Right now though this won't build, can probably fix by inheriting  
from genesis project-config to pick the right repository  
configurations, though these are old dep versions anyways... and you  
probably don't want to make them dependencies of all modules of the  
project, which is what you have setup right now.


 * * *

I think its good to have some real samples to help folks get started,  
but I wish that a little more attention to some of these details was  
given.


--jason


On Jan 19, 2007, at 9:22 AM, Prasad Kashyap wrote:


Encouraged by your kind words of appreciation for the Testsuite
framework, I put together a similar Samples Framework.

http://svn.apache.org/viewvc/geronimo/samples/

UseCase Scenario 1
---
Actor: Geronimo user, JEE5 Developer.

Requirements:
  * Actor wants to learn the new features of JEE5 by looking at  
sample code

  * He wants to play with sample code.
  * He wants to learn how to develop applications on Geronimo.
  * He may want to use the sample code as a template for his own  
application.


Flow A (install downloaded sample binary)
  * Actor downloads a Geronimo server binary  and unpacks it.
  * He then downloads a sample binary.
  * He starts Geronimo server.
  * He then deploys the sample artifact into running server.
  * He goes to the sample app's home page (context-root).

Flow B: (build sample source and install)
  * Actor downloads a sample source package.
  * He installs Maven if he doesn't have it already.
  * He builds the sample project using maven.
  * Sample project automatically downloads the latest Geronimo
server, starts it, and deploys the newly built sample.
  * It fires up a browser and brings up the sample home page  (not
implemented yet).

See the following links in Firefox only !
Here is a page that gives a user instructions on working with samples.
Every sample download will also have a customized  relevant page like
this, say as a README.html
http://people.apache.org/~prasad/samples/index.html

Here is a sample sample page. Notice the javadoc and source tabs in
the top right corner of the page.
http://people.apache.org/~prasad/samples/sample.html


UseCase Scenario 2
---
Actor: Geronimo Developer, JEE5 Spec Implementor

Interactions: Document Writer.

Requirements:
  * Actor wants to create sample projects quickly without having to
deal too much with Maven.

Flow:
  * Actor executes a sample-archetype-plugin.
  * It creates a mvn project which will act as a template.
  * He only has to write JEE5 code for the sample application.
  * He then works with Document Writer to write the sample document.


Cheers
Prasad.




Re: New Samples Framework for Geronimo.

2007-01-19 Thread Jason Dillon
Spec versioning with the server would have been nice to help keep  
artifacts in sync with the version of the server they are meant to go  
with.


The new samples stuff is actually depending on versions of specs  
which are not the versions used by the server.  Everytime we update a  
version of a spec in the server, we are gonna need to be sure to  
update all projects which are intended to work with that version of  
the server to get the correct versions too.


:-(

--jason


On Jan 19, 2007, at 1:53 PM, Matt Hogstrom wrote:

Very nice...I like the idea of standalone samples.  Without getting  
into the specs debate yet again ... but most likely will ... I like  
the samples released with the version of the server so people can  
pick up one version and know what its for.  I think the  
organization for now is great as we can get the actual work done on  
the samples while we debate how to organize them for the next  
several months.  Good job !  :)



On Jan 19, 2007, at 12:22 PM, Prasad Kashyap wrote:


Encouraged by your kind words of appreciation for the Testsuite
framework, I put together a similar Samples Framework.

http://svn.apache.org/viewvc/geronimo/samples/

UseCase Scenario 1
---
Actor: Geronimo user, JEE5 Developer.

Requirements:
  * Actor wants to learn the new features of JEE5 by looking at  
sample code

  * He wants to play with sample code.
  * He wants to learn how to develop applications on Geronimo.
  * He may want to use the sample code as a template for his own  
application.


Flow A (install downloaded sample binary)
  * Actor downloads a Geronimo server binary  and unpacks it.
  * He then downloads a sample binary.
  * He starts Geronimo server.
  * He then deploys the sample artifact into running server.
  * He goes to the sample app's home page (context-root).

Flow B: (build sample source and install)
  * Actor downloads a sample source package.
  * He installs Maven if he doesn't have it already.
  * He builds the sample project using maven.
  * Sample project automatically downloads the latest Geronimo
server, starts it, and deploys the newly built sample.
  * It fires up a browser and brings up the sample home page  (not
implemented yet).

See the following links in Firefox only !
Here is a page that gives a user instructions on working with  
samples.
Every sample download will also have a customized  relevant page  
like

this, say as a README.html
http://people.apache.org/~prasad/samples/index.html

Here is a sample sample page. Notice the javadoc and source tabs in
the top right corner of the page.
http://people.apache.org/~prasad/samples/sample.html


UseCase Scenario 2
---
Actor: Geronimo Developer, JEE5 Spec Implementor

Interactions: Document Writer.

Requirements:
  * Actor wants to create sample projects quickly without having to
deal too much with Maven.

Flow:
  * Actor executes a sample-archetype-plugin.
  * It creates a mvn project which will act as a template.
  * He only has to write JEE5 code for the sample application.
  * He then works with Document Writer to write the sample document.


Cheers
Prasad.



Matt Hogstrom
[EMAIL PROTECTED]






[jira] Created: (GERONIMO-2762) Updated JAX-WS tests

2007-01-19 Thread Jarek Gawor (JIRA)
Updated JAX-WS tests


 Key: GERONIMO-2762
 URL: https://issues.apache.org/jira/browse/GERONIMO-2762
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Affects Versions: 2.0-M2
Reporter: Jarek Gawor


The attached patch mostly contains updated JAX-WS tests. For example, the 
references to CXF were removed in WSDL, etc. and the test also test @Resource 
injection.

The patch also contains a minor fix to CXFWebServiceContainerFactoryGBean.java 
so that each service gets its own instance of the Bus. 
Also, this patch contains a required fix to TomcatModuleBuilder.java (carried 
over from https://issues.apache.org/jira/browse/GERONIMO-2756) without which 
the @Resource injection will not work in Tomcat (because the CXFBuilder will 
not be able to obtain a reference to JNDI context).






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




[jira] Updated: (GERONIMO-2762) Updated JAX-WS tests

2007-01-19 Thread Jarek Gawor (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor updated GERONIMO-2762:
--

Attachment: GERONIMO-2762.patch

 Updated JAX-WS tests
 

 Key: GERONIMO-2762
 URL: https://issues.apache.org/jira/browse/GERONIMO-2762
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Attachments: GERONIMO-2762.patch


 The attached patch mostly contains updated JAX-WS tests. For example, the 
 references to CXF were removed in WSDL, etc. and the test also test @Resource 
 injection.
 The patch also contains a minor fix to 
 CXFWebServiceContainerFactoryGBean.java so that each service gets its own 
 instance of the Bus. 
 Also, this patch contains a required fix to TomcatModuleBuilder.java (carried 
 over from https://issues.apache.org/jira/browse/GERONIMO-2756) without which 
 the @Resource injection will not work in Tomcat (because the CXFBuilder will 
 not be able to obtain a reference to JNDI context).

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




Re: Using JIRA

2007-01-19 Thread Hernan Cunico



Alan D. Cabrera wrote:


On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote:


Howdy,
it may sound weird asking this now but I'm either creating JIRAs the 
wrong way or we are not displaying the all the info in 
http://issues.apache.org/jira/browse/geronimo (or I just don't know 
how to read it)


On the JIRA front page for GERONIMO you can see open issues due to be 
fixed per version.
When I create a JIRA for a specific version I normally specify the 
affected version (let's say 2.0-M2) in the *Affects Version/s:* box 
and leave the *Fix Version/s:* empty as I don't really know for sure 
when that issue is going to be fixed unless I am the assignee.


This issue I just created does not get listed (counted actually) for 
that particular version in the project's JIRA home page.


Is this query is automatically provided by JIRA or we can customize it 
to show the affected version instead?
At this particular point in time the actual setting show 5 open 
issues, if we could change it to affected versions it would show 16.


Does this make any sense at all?

Again, it might be just me not really understanding how to use JIRAs.

Comments appreciated


I think that Jira is working correctly as is.  It should not show up on 
the radar, http://issues.apache.org/jira/browse/geronimo, until someone 
makes a commitment to fixing it for a particular release at which time 
the issue gets assigned Fix Version/s. 


So then that page is not representative of the number of issues open against a 
particular version. It looks more like a wish list of issues to be resolved by 
that particular release.

 If you look at the description 
below the Versions column on the home page you will see with open 
issues due to be fixed per version.  This indicates that someone has 
made a commitment to complete the issue for that version.


with open issues due to be fixed per version for me has a different meaning. 
IMO all issues need to be fixed, assigned or not, my point is that there are a bunch more 
issues that have been reported that are not being listed.

Maybe there should be a condition that one cannot specify the Fix versions 
unless that issues is assigned to that person, then we know for sure who made the 
commitment to get that issue fixed for that particular release.


You can make your own personal report and add it to your personalized 
portal page.



Yup, something like that I'm using for the release notes and pulling some 
dynamic content directly from JIRA.

Cheers!
Hernan


Regards,
Alan





Re: New Samples Framework for Geronimo.

2007-01-19 Thread Matt Hogstrom

On Jan 19, 2007, at 5:24 PM, Jason Dillon wrote:

Why are there reporting elements in the architype (and also in the  
first sample), which are not at the top-level, but are in  
calculator-stateless-pojo?


Why does this project not inherit from genesis project-config?

Why is the geronimo-maven-plugin configured here?

And why on earth are there sources (CalculatorServlet) checked in  
with:


snip
/*
* Copyright 2002 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
/snip



Ug...didn't look at the aources...my bad...good catch.





Matt Hogstrom
[EMAIL PROTECTED]




Re: EJB deployment error

2007-01-19 Thread David Blevins

Jarek, if you can send me the app I can take a look.

-David

On Jan 19, 2007, at 9:48 AM, Jarek Gawor wrote:


Dain,

This is just a simple EJB that tires to use JAXB or StAX API. It is
not exposed (or deployed) as a web service.

Jarek

On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:

Please take a look at the M2 Status - branch on Wednesday thread.
It contains a list of what works and what doesn't.  The webservices
integration doesn't work yet.

-dain

On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote:

 I get the following error after the openejb update:

 Deployer operation failed: org.apache.openejb.OpenEJBException:
 Cannot Load jar
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir
 \jaxb-ejb-2.0-SN
 APSHOT.jar.  The number of beans deployed (0) does not match the
 number of beans
 actually in the jar (1).  Please redeploy this jar.

 I see this error after updating the openejb-jar.xml
 (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml
 (http://java.sun.com/xml/ns/javaee) descriptors with right  
namespaces.


 I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb
 tests.

 The ejbs are very simple and do not use any annotations.

 Jarek








[jira] Commented: (GERONIMO-2756) Basic @Resource injection for CXF web services

2007-01-19 Thread David Jencks (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466180
 ] 

David Jencks commented on GERONIMO-2756:


Applied patch to tomcat builder in rev 498000, thanks!

 Basic @Resource injection for CXF web services
 --

 Key: GERONIMO-2756
 URL: https://issues.apache.org/jira/browse/GERONIMO-2756
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M2
Reporter: Jarek Gawor
 Assigned To: David Jencks
 Fix For: 2.0-M2

 Attachments: GERONIMO-2756.patch




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




Re: GBeanInstance/GBeanInstanceState eating exceptions?

2007-01-19 Thread Dain Sundstrom
I didn't know you wanted details :)   Honestly, I have no idea why  
the exception is being eaten, other than it may be expected.  The  
startup is asynchronous, so the start may wake up in a not yet  
ready state.  The reason it is in the current state is recorded in  
GBEanInstance.getStateReason().


It is the configuration object that has decided, that it has waited  
long enough and if all beans are not started it is going to give up.   
The feature was recently added, and is a big improvement over the  
previous behavior of waiting forever.  Basically, the configuration  
attempts to get all beans started, if they don't all start then it  
throws an exception stating why some of the beans didn't start.


Anyway, if you see some more information that needs to be propagated,  
by all means add it, just be careful, that you aren't wiping out  
relevant information with irrelevant info.


-dain

On Jan 19, 2007, at 2:05 PM, Jason Dillon wrote:

Where are the methods to pass back failure information from  
GBeanInstanceState to GBeanInstance (and so on) ?


I don't see anything like getFailureReason() or anything similar.

How is one supposed to expose the MissingDependencyException that  
is thrown in GBeanInstanceState.attemptFullStart(), which occurs  
when calling gbeanInstance.createInstance() and is then caught and  
eaten?


I need to propagate this exception detail back further to the  
component that asked for the component to be loaded, and attach the  
detail to the failure exception that is thrown when we ask a  
configuration to load.


What is the api to store and retrieve exceptions later that you  
mention?


--jason


On Jan 17, 2007, at 10:40 PM, Dain Sundstrom wrote:


I'm not going to try to justify the design, but I'll explain it...

The lifecycle method don't necessarily result in the bean fully  
completing a state change.  The bean may enter a transition state  
like starting or stopping and wait there for a resource to become  
available.  Really, they just initiate  a lifecycle change that  
will complete at a later time.  If the method were to throw an  
exception it would be completely random if it worked or not.   
Therefore, the methods don't throw exceptions and then are  
supposed to store the exception so it can be retrieved later.


The key is that most gbeans are started by the configuration and  
the configuration will gather any failures and throw a single  
exception containing all the problems.


Now if there are places problems occurs and the exceptions aren't  
saved, it is a bug.


-dain

On Jan 17, 2007, at 2:06 PM, Jason Dillon wrote:

Why do GBeanInstance/GBeanInstanceState eat exceptions instead of  
throwing them?


This seems to be a common pattern with GBeans, where they don't  
propagate the exception detail.  I was just looking at  
GBeanInstance.start(), but looks like stop() and other methods  
have the same basic issues.


The lack of detail being propagated results in build failures like:

snip
Configuration gbean failed to start org.apache.geronimo.configs/ 
openejb/2.0-SNAPSHOT/car

/snip

But they show no detail as to why they failed.  This one happens  
to be caused by:


snip
org.apache.geronimo.kernel.repository.MissingDependencyException:  
Unable to resolve dependency org.apache.openejb/openejb-loader//jar
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolv 
eInClassLoader(DefaultArtifactResolver.java:123)
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver$ 
$FastClassByCGLIB$$e847b746.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java: 
53)

...
/snip

But you would never know that unless you hack up the  
GBeanInstanceState with printlns or something.  There is some  
logging which is done, but that is getting lost due to mismatch  
in log4j and maven logging systems.  I thought I had a bridge  
setup to handle this, but it appears to have been broken for  
sometime.  But aside from the logging issue, I think its a bigger  
problem that the GBean stuff is not throwing exceptions with  
meaningful details.


There are other bits which look rather wrong wrt showing  
exception details, like:


snip
try {
kernel.startRecursiveGBean(dependent);
} catch (GBeanNotFoundException e) {
// this is ok the gbean died before we could start it
} catch (Exception e) {
// there is something wrong with this gbean... skip it
}
/snip

There is no log here at all... this exception just gets swallowed  
up.


This also looks fishy:

snip
try {
// try to create the instance
if (!gbeanInstance.createInstance()) {
// instance is not ready to start... this is normally  
caused by references
// not being available, but could be because someone  
already started the gbean.
// in another thread.  The reference will log a debug  
message about why

// it could not start
return;
}
} catch (Throwable t) {
// oops there 

Re: OpenEJB 3 integration working

2007-01-19 Thread Dain Sundstrom
Datasource references work but other important ones like  
UserTransaction and persistence context don't.


I'm working on those now.

-dain

On Jan 19, 2007, at 1:20 AM, Dain Sundstrom wrote:

It has been a long week, but David and I got the integration  
working tonight.  We successful got the OpenEJB 3 itest application  
to deploy and got the client to fire up and call the server.  A  
bunch of tests fail due to a bug in lookup of datasources in  
OpenEJB, but we got a good number of passes.


-dain




Re: Help Needed on AbastractNamingBuilder

2007-01-19 Thread Lasantha Ranaweera
Hi David,

Great !!! Thank you very much for your very descriptive reply. I am sure
now I can continue my work from here.

Thanks Again,
Lasantha

 On Jan 19, 2007, at 1:08 AM, Lasantha Ranaweera wrote:

 Hi,

 I have been working with the Geronimo Axis2 integration and
 following the foot steps of the CXF and Axis implementations of
 Geronimo. Finally this integration will provide one of the  JAXWS
 integrations of the Geronimo ;-) .
 In the Axis 1 integration there is a  class called
 AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we
 need a same kind of class for the Axis2 integration too considering
 the above requirement?  (CXF module has not implemented this kind
 of class yet but it has been commented out in the config.xml).

 If anybody explain bit more in depth on this AbastractNamingBuilder
 class and it's effect to the JEE it would be great help for my work
 since it looks bit more complicated for me now :-) .

 We definitely need one of these for axis2 and one for cxf.  They
 deploy web service clients.  For example, if your ejb needs to access
 a web service, it declares a service-ref in its deployment descriptor
 (there's probably a way to do this with annotations as well) and we
 have to set up a web service client and bind it into the local jndi
 context for that ejb.

 There are several steps a naming builder can take:

 buildEnvironment.  Here the builder should figure out if it's going
 to need to do anything and if so add the defaultEnvironment it's
 configured with to the supplied environment.  This means that if you
 don't use web services, the ws classes don't need to be there, and if
 you do use web services, they will be available.

 initContext:  Here you can add stuff to the shared context that other
 naming builders can use.  I don't think this is going  to be useful
 for ws client builders.  In the future if we get the service builders
 to use the same interface we might be able to use this to construct
 shortcuts so use of a ws in the same app it's supplied in doesn't
 have to go through tcp/ip. this is far in the future.

 buildNaming: Here you actually construct something that will make the
 web service client exist when the app is run, put whatever gbeans you
 need into the deployment context, and add a naming reference into the
 map that will populate the jndi tree.

 Hope this helps,
 david jencks


 Thanks in Advance,
 Lasantha Ranaweera





Conversion Tool

2007-01-19 Thread David Blevins
Keep your ejb related plan files intact or a copy of them at least.   
I'm going to try and write a conversion tool that will at least  
handle trivial apps.  A non-trivial app would be one with CMPs.  The  
new mapping.xml format for cmps is the jpa mapping.xml and converting  
that will be a little more work.


Nothing done yet, just announcing intentions.

-David



Re: EJB deployment error

2007-01-19 Thread Jarek Gawor

David,

It's a test case in Geronimo source code. See
testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb directory.

Jarek

On 1/19/07, David Blevins [EMAIL PROTECTED] wrote:

Jarek, if you can send me the app I can take a look.

-David

On Jan 19, 2007, at 9:48 AM, Jarek Gawor wrote:

 Dain,

 This is just a simple EJB that tires to use JAXB or StAX API. It is
 not exposed (or deployed) as a web service.

 Jarek

 On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
 Please take a look at the M2 Status - branch on Wednesday thread.
 It contains a list of what works and what doesn't.  The webservices
 integration doesn't work yet.

 -dain

 On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote:

  I get the following error after the openejb update:
 
  Deployer operation failed: org.apache.openejb.OpenEJBException:
  Cannot Load jar
  C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir
  \jaxb-ejb-2.0-SN
  APSHOT.jar.  The number of beans deployed (0) does not match the
  number of beans
  actually in the jar (1).  Please redeploy this jar.
 
  I see this error after updating the openejb-jar.xml
  (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml
  (http://java.sun.com/xml/ns/javaee) descriptors with right
 namespaces.
 
  I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb
  tests.
 
  The ejbs are very simple and do not use any annotations.
 
  Jarek







Extension pattern, i.e. *.do in security constraints

2007-01-19 Thread anita kulshreshtha
   We do not allow this combintaion of URL patterns in
web-resource-collection. This is in line with JACC
http://java.sun.com/j2ee/1.4/docs/api/javax/security/jacc/WebResourcePermission.html

   security-constraint
web-resource-collection
web-resource-nameAdmin Role/web-resource-name
url-pattern*.do/url-pattern
/web-resource-collection
auth-constraint
role-namecontent-administrator/role-name
/auth-constraint
/security-constraint

security-constraint
web-resource-collection
web-resource-nameUnrestricted ACCESS/web-resource-name
url-pattern/login.do/url-pattern
/web-resource-collection
/security-constraint

The following url-patterns are allowed with *.do - 
 -  /login/*, /login.do/* , i.e. path prefix patterns
 -  login.do, i.e. Exact patterns matching *.do
 - login.do/, login.do/* 
Does anyone know why the above web.xml fragment should or should
not be allowed? 

Thanks
Anita


 

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL


[jira] Updated: (GERONIMO-2746) use dependencymanagement for some axis2 dependent modules

2007-01-19 Thread Lin Sun (JIRA)

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lin Sun updated GERONIMO-2746:
--

Attachment: G2746-new.patch

 use dependencymanagement for some axis2 dependent modules 
 --

 Key: GERONIMO-2746
 URL: https://issues.apache.org/jira/browse/GERONIMO-2746
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0-M1
 Environment: winxp + sun jdk 1.5
Reporter: Lin Sun
Priority: Minor
 Attachments: G2746-new.patch, G2746.patch


 This patch is intended to use the dependencymanagement for the axis2 
 dependencies that have the same version specified in root pom.xml file.  
 I removed the following dependency as I dont see a need of it:
 -/dependency
 -groupIdcom.sun.xml.bind/groupId
 -artifactIdjaxb-xjc/artifactId
 -version2.0.2/version
 -/dependency
 Also, tried to correct the 202 typo.  The logic doesn't look right so I went 
 back to the code where I think this portion of code was copied from 
 (HTTPWorker.service), and it has 200 there.
 patch is created against rev 496844 and I was able to get jax-ws testing 
 running (both soap call + ?wsdl call), even tho I am not sure if the ?wsdl 
 call result looks completely correct.

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




  1   2   >