Re: Maven2... we are almost there!

[David Jencks]

I'm not seeing any log files in var/log when I start the m2 j2ee- 
jetty server is it just me?


thanks
david jencks


On Aug 4, 2006, at 5:25 PM, Jason Dillon wrote:

I have finished merging svkmerge/m2migration to trunk.  Now it is  
time for everyone to start using the m2 build... and avoid using  
the m1 build.


I updated the docs here which explain what you must do:

http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- 
maven-2.html


You should bootstrap at least once.  This is temporary and will be  
removed soon.


 * * *

Please, please, please start using the m2 build.  If for some  
reason you end up going back to m1 please let us know so we can fix  
it.


The last major issue left unresolved (that I am ware of) is the car  
plugins support for geronimo-plugin.xml fluff, which I am working  
on resolving.


--jason

Re: [Review] GERONIMO-2277 Remove TransactionContextManager

[David Jencks]

The notcm branch builds fine for me under m2 but the j2ee-jetty  
server does not start for me at the moment.  Apparently the  
TransactionManager doesn't start.  As noted in another post I don't  
get any log files which has so far inhibited me from investigating  
further.  Is this just my setup?


thanks
david jencks

On Aug 5, 2006, at 9:11 PM, Dain Sundstrom wrote:

I merged all changes from head back into notcm and fixed the m2  
build.  I also made a few changes noted below based on requests for  
David.  You I suggest you test the notcm branch directly.  If you  
want to try the merge, use the same command as before, and you'll  
have to resolve some conflicts (I have no idea why svn marks them  
as conflicts).  Here are the commands I used:


svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo
cd geronimo

svn merge -r 427246:HEAD https://svn.apache.org/repos/asf/geronimo/ 
branches/dain/notcm .


# resolve the conflicts by taking the files from notcm
mv bootstrap.merge-right* \
   bootstrap
svn resolved bootstrap
chmod u+x bootstrap

mv pom.xml.merge-right* \
   pom.xml
svn resolved pom.xml

mv m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/ 
security/keystores/geronimo-default.merge-right* \
   m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/ 
security/keystores/geronimo-default
svn resolved m2-assemblies/geronimo-boilerplate-j2ee/src/main/ 
resources/var/security/keystores/geronimo-default


mv m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/ 
var/security/keystores/geronimo-default.merge-right* \
   m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/ 
var/security/keystores/geronimo-default
svn resolved m2-assemblies/geronimo-boilerplate-minimal/src/main/ 
resources/var/security/keystores/geronimo-default


# run the m2 build or run the m1 build
./bootstrap
mvn clean install

# maven new

Sorry about the long instructions, but svn screwed me. more  
comments below...



On Aug 4, 2006, at 5:40 PM, David Jencks wrote:

I have a couple of concerns: most of these were probably present  
in the unmodified code.


1. TransactionManagerImpl.unassociate calls fireThreadAssociated  
instead of fireThreadUnassociated (dain is fixing this IIUC)


FIXED

2. ConnectorTransactionContext.managedConnections doesn't have any  
obvious synchronization.  When I wrote this code I think I had an  
argument why it wasn't needed, but I'd like to find the object  
that is in fact guarding it and document it.


I synchronized access.  It the data is effectively transaction  
local, and only thread can be associated with a tx at a time. But  
it is safer to synchronize.  It shouldn't hurt performance since  
there will be no contention.


3. Am I correct in thinking that you made the connection tracking  
work without needing instance contexts available?  I think this is  
a reasonable change, just


Based on my reading of the code, conection tracking need to be  
notified of context changes.  If it switches to a context without  
connector tx data, the tracker has nothing to do.



4. I wonder if the client still needs a tm since it is inaccessible.


I don't think it is requires, but we may want to start an  
unrecoverable one anyway.


-dain

[jira] Created: (SM-516) MessageUtil should support empty content when copying messages

[Guillaume Nodet (JIRA)]

MessageUtil should support empty content when copying messages
--

 Key: SM-516
 URL: https://issues.apache.org/activemq/browse/SM-516
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-eip
Affects Versions: 3.0-M2
Reporter: Guillaume Nodet
 Fix For: 3.0-M3




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

[jira] Created: (SM-515) StringSource should throw an NPE when built with a null string instead of throwing it when calling getInputStream

[Guillaume Nodet (JIRA)]

StringSource should throw an NPE when built with a null string instead of 
throwing it when calling getInputStream
-

 Key: SM-515
 URL: https://issues.apache.org/activemq/browse/SM-515
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.0-M2
Reporter: Guillaume Nodet
 Fix For: 3.0-M3




-- 
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: (SM-516) MessageUtil should support empty content when copying messages

[Guillaume Nodet (JIRA)]

 [ https://issues.apache.org/activemq/browse/SM-516?page=all ]

Guillaume Nodet resolved SM-516.


Resolution: Fixed
  Assignee: Guillaume Nodet

Author: gnodet
Date: Mon Aug  7 00:20:09 2006
New Revision: 429263

URL: http://svn.apache.org/viewvc?rev=429263&view=rev
Log:
SM-516: MessageUtil should support empty content when copying messages

Modified:

incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/MessageUtil.java



> MessageUtil should support empty content when copying messages
> --
>
> Key: SM-516
> URL: https://issues.apache.org/activemq/browse/SM-516
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-eip
>Affects Versions: 3.0-M2
>Reporter: Guillaume Nodet
> Assigned To: Guillaume Nodet
> Fix For: 3.0-M3
>
>


-- 
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

Openwire C++ APIs minus "JMSXUserID"

[Naveen Rawat]

Hi James, I regret this delayed feedback. 




On 8/1/06, Naveen Rawat <[EMAIL PROTECTED]> wrote:  



Hi all.  



I am using the binary version of ActiveMQ 4.0 broker and openwire cpp >>APIs to interface my cpp server with the broker. 
  [  Openwire APIs being taken from - 
  svn co 
https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/openwire-cpp]  

 

Please help in solving my queries :-  

1. Does the broker itself has the mechanism to support multiple senders >>to a receiver listening on the same queue? 



Yes  



2. Does openwire cpp APIs provides for maintaining Broker's >>Authentication Policy? If not what could be the alternative.  




You can send the userName and passsword to the broker when making a 
connection. The security is then performed by the broker.  



3. How can a sender be authenticated among a senders? 


The broker can authorize individual consumers or sends to determine if 
a user has the right to use a specific destination...  

http://incubator.apache.org/activemq/security.html  



My sender maintains a username and password for connecting to the >>broker and I have set the populateJMSXUserID option to "true" in >>activemq.xml. The 
broker tag reads like - 
   

My sender connection creating code is as - 
connection = factory->createConnection("naveen", "rawat") ;  

Am I missing anything here? 


No - you should receive the JMSXUserID header on messages received. 



Does this UserID fetched from the received message's header has to be set to 
the reply message header - so as to make reply in synch with the particular 
sender client? 



Also, I am not getting any function as such in my set of OpenWire APIs to 
retreive the JMSXUserID from the message header. There are functions for 
manipulating other header options but not for JMSXUserID. My openwire APIs 
are from above mentioned svn location. Am I missing on it or it is actually 
not there? 

Any other way please suggest. 



4. For the above created sender is it required for the consumer to 
authenticate sender or is it solely the ActiveMQ job?  

The broker does the authentication and authorization. The JMSXUserID 
is purely so a consumer can see the userName of the sender (and since 
the broker specifies this it can't be spoofed). 
--  

James 



Thanks and Regards, 


Naveen Rawat

[jira] Commented: (GERONIMO-1942) InPlace deployment does not work with EjbModules

[Manu T George (JIRA)]

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

Manu T George commented on GERONIMO-1942:
-

This problem occurs due to the following 

When you are deploying an exploded module in the createModule method of 
OpenEjbModuleBuilder shown below is used

createModule(File plan, JarFile moduleFile, Naming naming, ModuleIDBuilder 
idBuilder){
return createModule(plan, moduleFile, "ejb", null, null, null, naming, 
idBuilder);
}

Here ejb is hardcoded as the targetPath. This is not correct in the case of 
exploded deployment as the ejb file is not created. Instead we are going to 
used the exploded directory itself and so the target path should be "."

For this reason we can change the existing method to 

createModule(File plan, JarFile moduleFile, Naming naming, ModuleIDBuilder 
idBuilder,String targetPath){
return createModule(plan, moduleFile, targetPath, null, null, null, naming, 
idBuilder);
}

or you can straightaway use createModule(plan, moduleFile, targetPath, null, 
null, null, naming, idBuilder) in the EARConfigBuilder Class.

To determine the target path we need to add a boolean parameter to the 
getDeploymentPlan()  method of EARConfigBuilder.

If this approach is alright then I will post the patch. 



> InPlace deployment does not work with EjbModules
> 
>
> Key: GERONIMO-1942
> URL: http://issues.apache.org/jira/browse/GERONIMO-1942
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.1
>Reporter: Sachin Patel
>Priority: Critical
> Fix For: 1.1.x
>
>
> In place deployment fails with EJBModules.  When pointing to the exploded 
> ejbjar using the --inPlace option the classes to not resolve...
>  Error: Unable to distribute temp: Remote interface class not found:
> org.apache.test.My

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

Re: Maven2... we are almost there!

[Aaron Mulder]

On 8/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

On Aug 6, 2006, at 2:21 PM, Aaron Mulder wrote:
> * OpenEJB downloads specs instead of using the ones build during the
> prior spec build phase

The specs built from bootstrap are only for the JavaMail bits that
Rick added... and is again temporary until we get things published
regularly from CI.


So we have to build like 20 specs just to get JavaMail?  That's
bizarre -- why don't we just check out JavaMail?


> * One of the applications (I think it said Demo, but I'm not sure
> which that is) downloaded Servlet and JSP specs that weren't from the
> Geronimo specs project at all

Details Aaron please.  I can't possibly begin to do anything based on
this statement.


Really?  It was enough for me to grep my bootstrap.log:

[INFO] Building Geronimo Applications :: Demo
[INFO]task-segment: [install]
...
Downloading: 
http://people.apache.org/repo/m2-ibiblio-rsync-repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.pom
...
Downloading: 
http://people.apache.org/repo/m2-ibiblio-rsync-repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.pom
...
Downloading: 
http://repo.mergere.com/maven2/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
...
Downloading: 
http://repo.mergere.com/maven2/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
...


> * I swear I'm running everything under Java 1.4, and I did a whole
> new bootstrap build, and the OpenEJB compile worked, but the bootstrap
> ultimately failed with:
>
> [ERROR] BUILD ERROR
> [INFO]
> --
> --
> [INFO] java.io.IOException: Unable to serialize GBeanData for
> org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/car?
> ServiceModule=org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/
> car,j2eeType=CORBABean,name=UnprotectedServer
>
> org/omg/CSI/EstablishContext

I have not seen this.  Has anyone else?


> Maybe this isn't my fault?  Maybe someone push bad CORBA specs again?

No sure... what platform?  Did you have a clean repo, or did you
circumvent the repo cleaning?


Clean repo.

Thanks,
Aaron

[jira] Updated: (GERONIMO-1942) InPlace deployment does not work with EjbModules

[Sachin Patel (JIRA)]

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

Sachin Patel updated GERONIMO-1942:
---

Component/s: OpenEJB
 (was: deployment)

> InPlace deployment does not work with EjbModules
> 
>
> Key: GERONIMO-1942
> URL: http://issues.apache.org/jira/browse/GERONIMO-1942
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 1.1
>Reporter: Sachin Patel
>Priority: Critical
> Fix For: 1.1.x
>
>
> In place deployment fails with EJBModules.  When pointing to the exploded 
> ejbjar using the --inPlace option the classes to not resolve...
>  Error: Unable to distribute temp: Remote interface class not found:
> org.apache.test.My

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

Re: Multiple client in ActiveMQ useing openwire-cpp API's

[Arshad Ahamad]

Hi Bish,


//Receive  message
  while(1)
  {
  }
This while loop for receving the message without executing recever again 
and again. And in case of  the following code

while(1)
{
semaphore.wait(1) ;
} 

In this case also multiple client are not intrect with a single recever is 
there any other thing are missing. Pls guide me .
Plesae keep in touch, so that I can remove my problems.. 



Thanks in advance 





Thanks & Regards
Arashad Ahamad

Re: Multiple client in ActiveMQ useing openwire-cpp API's

[Arshad Ahamad]

Hi Bish, 

  Please guide me, How can I create multiple client(Sender) for the single 
client(Receiver) but they bust be communicate bi-directionaly. Pls do tell 
me the requered steps. 


Thanks in advance




Thanks & Regards
Arashad Ahamad

Re: BAm Component - Data configuration

[Guillaume Nodet]

I really think that XBean is the most flexible option, as it allow easy
extension (using spring syntax), validation using the xml schemas and it
would be more homegeneous with the remaining of ServiceMix.

For actions, you could define these properties on the BAMEndpoint:
 private Action[] actions;
 private Resource actionsResource;
with the appropriate getters / setters, where
  Action is an interface defined by the BAM component, and Resource is a
spring resource (org.springframework.core.io.Resouce).

Let's you have an Action implementation with the MyAction class, if you
annotate the javadoc with the @org.apache.xbean.XBean annotation, you would
have:

 
   
 
   
 

The actionsResource would be used if you want to split the actions
definition in another file.
  
Where the file would contain something like:
 
   
 

This would allow to easily extend the set of actions, either by adding a
predefined action in the
component, but also by embedding the class in the SU and use standard spring
syntax:
 
   
 
   
 


On 8/7/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:


Hi Guillaume/All

We are almost there with the BAMComponent, as discussed in the earlier
emails, we have used the maven archetype (which was uploaded by SM guys) for
developing the JBI component.

The next step is to figure out a proper way of feeding configuration
related data for the BAMComponent. As pointed out earlier the component in
question would require data for KPI-Key performance indicator (currently
xpath based), Actions and global configurations.

My idea was to use XMLBeans based on xsds for the same but am thinking
otherwise as it would introduce some maintenance going forward. The other
option is to use properties file but then again it would pose a challenge
when the elements get nested, it will become too convoluted to handle. So
the question is still open -> what to use or what could be an elegant
solution for this.

Thanks
Soumadeep








--
Cheers,
Guillaume Nodet

Re: Single Sign On with Geronimo 1.0

[Vamsavardhana Reddy]

I could get SSO Working on a server build with SSOValve GBean in the
tomcat plan.  In this case the application deployment plans needed
no change as mentioned in the post that Krish pointed to.

Here are some of my observations.

An SSOValve GBean created as part of the application needs to be
connected to TomcatEngine so that SSO works.  To do so, either the
FirstValve in TomcatEngine needs to be replaced with this SSOValve or a
"NextValve" attribute should be added to the FirstValve and it should
be made point to the SSOValve.  I guess there is only one
TomcatEngine GBean in the server and I don't think it should be
modified to suit the needs of two or more applications that need SSO.

Other way is to have multiple hosts defined in the tomcar plan and and
one of them could have an SSOValve in the chain.  All apps that
want SSO can use that host.

In either case, the server needs to built with SSOValve GBean.

With what G provides right now, there is noway that an SSOValve GBean
is created as part of an application and hooked to the TomcatEngine.

Comments?

Thanks,
VamsiOn 8/2/06, Krishnakumar B <[EMAIL PROTECTED]> wrote:
Hi Joe,I have also tried this and was able to get it to work by doing a buildwith SSOValve GBean open.Refer to earlier post :http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647
I was not able to get it to work by deploying a new Valve along with 2web applications that need SSO.RegardsKrish.On 8/1/06, Joe O'Pecko <[EMAIL PROTECTED]
> wrote:> I know this has been discussed in the past, and I> apologize for the lengthy inquiry, however, I have> been trying unsuccessfully to get SSO working with> Tomcat on Geronimo v1.0
 for some time. I am deploying> an application as an ear file with two war files> contained within. My geronimo-application.xml file> contains a definition for a JAAS Security Realm and> the two WAR file's 
geronimo-web.xml reference it via> security-realm-name elements. Once deployed each web> application challenges the user upon first access,> using the configured JAAS LoginModule. I'd like to> establish a SSO trust between the two web
> applications, if possible, so that a user is only> challenged once for both web applications.>> I've seen a previous post on this site entitled Single> Sign On : Tomcat in Geronimo
> (http://tinyurl.com/lkgjy) which seemed to provide> some information. Basically, it suggested the addition> of a SSOValve GBean to the geronimo-web.xml file. As
> suggested, I've added the SSOValve to each> geronimo-web.xml and confirmed that I could see them> running in the deploy-tool web application. However,> each application has its own SSOValve GBean running
> which leads me to believe that they do not share> anything between them.>> I've also seen Aaron Mulder's website which states> that Geronimo does not natively support web-based> single sign-on across web sites
> (http://tinyurl.com/qa9bl).>> So is it possible to provide Single Sign On accross> web applications? I've attached my config files below> if it helps.
>> Thanks in advance for any help and information you can> provide.>> Joe>> ---begin geronimo-application.xml---> 
>> >> xmlns="http://geronimo.apache.org/xml/ns/j2ee/application">> xmlns:sec="
http://geronimo.apache.org/xml/ns/security-1.1">configId="com/foo/test">parentId="geronimo/j2ee-server/1.0/car">>>>log4j
>log4j>1.2.8>>>>
>>> class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal">name="anonymous"/>>
>>>
>>>> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal">name="foo_admin"/>
>>>>>>> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal">name="foo_user"/>
>>>>>>>
> class="org.apache.geronimo.security.realm.GenericSecurityRealm">>>> name="realmName">foo-realm>>>>foo-login>>>
>> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=ServerInfo>>
>>> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=JaasLoginService,name=JaasLoginService
>>>>>> class="
org.apache.geronimo.security.jaas.JaasLoginModuleUse">>>> name="controlFlag">REQUIRED>
>>>foo-login>>
>>>> class="org.apache.geronimo.security.jaas.LoginModuleGBean">>
>com.foo.FooLoginModule>>true>> name="loginDomainName">foo-realm
>>>>   class="com.foo.FooServerGBean">> gbeanName="com.foo.fooserver:type=Server,name=GUIServer">
>> type="java.lang.String">>

Re: Geronimo site POC using Confluence & Autoexport

[Alan D. Cabrera]

Jason,

This is really great!


Regards,
Alan

Jason Dillon wrote:
FYI, I added an Activity section that shows recent JIRA issues 
resolved and opened:


http://cwiki.apache.org/GMOxSITE/

Need a few minor changes to the autoexport plugin to get this kept in 
sync on a regular basis... essentially we need a scheduled export on 
some pages that have more dynamic content.


--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main 
site... but have not fully converted them.  But now you can get a 
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Patches in RTC (Geronimo - August 4, 2006)

[Alan D. Cabrera]

This looks really great!


Regards,
Alan

[EMAIL PROTECTED] wrote:

Geronimo - August 4, 2006

  9 Patches in RTC

[XBEAN-33] [RTC] Add a new Wiki source generator that generates wiki markup 
so that reference docs can be pasted into confluence.
  - Assignee: Hiram Chirino
  - Reporter: Hiram Chirino
  - Created:  Tue, 1 Aug 2006 13:03:57 -0700 (PDT)
  - Updated:  Tue, 1 Aug 2006 13:13:56 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/XBEAN-33

[XBEAN-19] [RTC] Enable inverse classloading with the classpath element
  - Assignee: Guillaume Nodet
  - Reporter: Guillaume Nodet
  - Created:  Fri, 16 Jun 2006 14:13:24 -0700 (PDT)
  - Updated:  Tue, 1 Aug 2006 01:33:30 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/XBEAN-19

[GERONIMODEVTOOLS-93] Support for non-plugin archives for installable 
runtimes
  - Assignee: Sachin Patel
  - Reporter: Sachin Patel
  - Created:  Mon, 31 Jul 2006 07:22:56 -0700 (PDT)
  - Updated:  Thu, 3 Aug 2006 14:26:10 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93

[GERONIMO-2248] Applications portlets: List Parent and Child components 
against each component
  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Sun, 30 Jul 2006 08:15:34 -0700 (PDT)
  - Updated:  Tue, 1 Aug 2006 02:08:20 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2248

[GERONIMO-2224] Add a geronimo specific system property for controlling 
dom, sax, and transformer creation
  - Assignee: Dain Sundstrom
  - Reporter: Dain Sundstrom
  - Created:  Mon, 24 Jul 2006 14:02:56 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 12:12:30 -0700 (PDT)
  - Votes: 1
  1  Donald Woods
  - http://issues.apache.org/jira/browse/GERONIMO-2224

[GERONIMO-2163] WADI Integration for Jetty
  - Assignee: Gianny Damour
  - Reporter: Gianny Damour
  - Created:  Sun, 2 Jul 2006 14:16:35 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 12:03:16 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2163

[GERONIMO-2084] The transaction manager needs uncesseraly ties users to the 
TransactionContextManager implementation
  - Assignee: Unassigned
  - Reporter: Guillaume Nodet
  - Created:  Mon, 5 Jun 2006 14:47:20 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 12:01:23 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2084

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri, 12 May 2006 14:54:17 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 12:00:00 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMO-1563] [RTC] Make the JACC implementation pluggable
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed, 1 Feb 2006 02:26:12 -0800 (PST)
  - Updated:  Fri, 4 Aug 2006 12:02:25 -0700 (PDT)
  - Votes: 2
  1  Alan Cabrera
  2  Donald Woods
  - http://issues.apache.org/jira/browse/GERONIMO-1563


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the "Begin RTC Review"
link under the "Available Workflow Actions" of the JIRA page.

If you do not see your vote here, click the "Vote" link under the
"Operations" section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

  

Re: Patches in RTC (Geronimo - August 4, 2006)

[Alan D. Cabrera]

David Jencks wrote:


On Aug 4, 2006, at 12:25 PM, David Blevins wrote:


Thanks.

Since this report was just a demo, I've gone through some of the 
JIRAs that had patches and owners, clicked their "Begin RTC Review" 
buttons and am sending out a new report.


This looks very good.

I guess what we can do to determine the pmc-vote status of an issue is 
look at the names next to the votes and manually filter out the 
non-pmc votes?


I think it would be better to mark PMC votes with an asterisk rather 
than removing them all together.



Regards,
Alan

Re: Regarding Exploded Deployments

[Manu George]

Hi Gianny,
 Thanks for the explanation. Are ejb modules also auto
exploded? I saw that war's are exploded but ejb modules don't seem to
be auto exploded. Any reason for this?

Thanks
Manu

On 8/5/06, Gianny Damour <[EMAIL PROTECTED]> wrote:

Manu George wrote:

> Hi,
>   Does Geronimo support exploded deployments of ear's that
> contain wars and jars using --inPlace Argument? When I try to deploy
> daytrader by extracting it  to a directory and passing the path to the
> directory as an argument to deploy along with --inPlace it is giving
> an error
>
> java.lang.Error: Only local file jars are supported
> jar:file:/C:/1.1samples/samp
> 
les/applications/daytrader/target/test/daytrader-ear-1.1/web.war!/WEB-INF/lib/st
>
> andard-1.1.1.jar

There is a bug in the deployment of war module defining libraries within
WEB-INF/lib/ when this module is inside an ear module. I will fix this
problem.

> What is the correct format of an exploded EAR. Will it have the
> ejb-jar and webapp-war exploded as well? OR will geronimo support non
> exploded format as well?

In the case of an in-place deployment, nested modules are auto-exploded
upon deployment, if need be. For instance, if there is a non-exploded
war module mywar.war within an ear, then the war is renamed
mywar.war.saved, a sub-directory mywar.war is created and
mywar.war.saved is unjarred within it.

Thanks,
Gianny

>
> Regards
> Manu
>

[jira] Closed: (GERONIMODEVTOOLS-58) After Run->Run as Server get message "Could not find a client that is able to launch the selection"

[Sachin Patel (JIRA)]

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

Sachin Patel closed GERONIMODEVTOOLS-58.


Resolution: Cannot Reproduce
  Assignee: Sachin Patel

Cannot reproduce this.  If you Run As from and Ear, the expected behavior is 
the dialog box indicating that there is no client to launch the selection, 
however when selecting the web project, there is a client which launches the 
browser.

> After Run->Run as Server get message "Could not find a client that is able to 
> launch the selection"
> ---
>
> Key: GERONIMODEVTOOLS-58
> URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
> Environment: Win2K, JDK 1.4.2 or JDK 1.5.0, WTP 1.0.1 and before, 
> latest eclipse plugin (20060130-0958).
>Reporter: Edson Richter
> Assigned To: Sachin Patel
>Priority: Critical
>
> Just right click on Dynamic Web project and choose Run -> Run As Server, 
> select Geronimo. The app is apparently deployed (not sure), Geronimo isn't 
> started and message "Could not find a client that is able to launch the 
> selection".
> Expected behaviour is browser is open and application is run.

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

Re: Single Sign On with Geronimo 1.0

[Jeff Genender]

Why does the server need to be built with the SSOValve?

You should be able to connect the SSOValve to the TomcatEngine in the
config.xml.

Jeff

Vamsavardhana Reddy wrote:
> I could get SSO Working on a server build with SSOValve GBean in the
> tomcat plan.  In this case the application deployment plans needed no
> change as mentioned in the post that Krish pointed to.
> 
> Here are some of my observations.
> 
> An SSOValve GBean created as part of the application needs to be
> connected to TomcatEngine so that SSO works.  To do so, either the
> FirstValve in TomcatEngine needs to be replaced with this SSOValve or a
> "NextValve" attribute should be added to the FirstValve and it should be
> made point to the SSOValve.  I guess there is only one TomcatEngine
> GBean in the server and I don't think it should be modified to suit the
> needs of two or more applications that need SSO.
> 
> Other way is to have multiple hosts defined in the tomcar plan and and
> one of them could have an SSOValve in the chain.  All apps that want SSO
> can use that host.
> 
> In either case, the server needs to built with SSOValve GBean.
> 
> With what G provides right now, there is noway that an SSOValve GBean is
> created as part of an application and hooked to the TomcatEngine.
> 
> Comments?
> 
> Thanks,
> Vamsi
> 
> On 8/2/06, *Krishnakumar B* <[EMAIL PROTECTED]
> > wrote:
> 
> Hi Joe,
> 
> I have also tried this and was able to get it to work by doing a build
> with SSOValve GBean open.
> 
> Refer to earlier post :
> http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647
> 
> 
> I was not able to get it to work by deploying a new Valve along with 2
> web applications that need SSO.
> 
> Regards
> Krish.
> 
> On 8/1/06, Joe O'Pecko <[EMAIL PROTECTED]
> > wrote:
> > I know this has been discussed in the past, and I
> > apologize for the lengthy inquiry, however, I have
> > been trying unsuccessfully to get SSO working with
> > Tomcat on Geronimo v1.0 for some time. I am deploying
> > an application as an ear file with two war files
> > contained within. My geronimo-application.xml file
> > contains a definition for a JAAS Security Realm and
> > the two WAR file's geronimo-web.xml reference it via
> > security-realm-name elements. Once deployed each web
> > application challenges the user upon first access,
> > using the configured JAAS LoginModule. I'd like to
> > establish a SSO trust between the two web
> > applications, if possible, so that a user is only
> > challenged once for both web applications.
> >
> > I've seen a previous post on this site entitled Single
> > Sign On : Tomcat in Geronimo
> > (http://tinyurl.com/lkgjy) which seemed to provide
> > some information. Basically, it suggested the addition
> > of a SSOValve GBean to the geronimo-web.xml file. As
> > suggested, I've added the SSOValve to each
> > geronimo-web.xml and confirmed that I could see them
> > running in the deploy-tool web application. However,
> > each application has its own SSOValve GBean running
> > which leads me to believe that they do not share
> > anything between them.
> >
> > I've also seen Aaron Mulder's website which states
> > that Geronimo does not natively support web-based
> > single sign-on across web sites
> > (http://tinyurl.com/qa9bl).
> >
> > So is it possible to provide Single Sign On accross
> > web applications? I've attached my config files below
> > if it helps.
> >
> > Thanks in advance for any help and information you can
> > provide.
> >
> > Joe
> >
> > ---begin geronimo-application.xml---
> > 
> >
> >  >
> > xmlns="http://geronimo.apache.org/xml/ns/j2ee/application";
> >
> > xmlns:sec=" http://geronimo.apache.org/xml/ns/security-1.1";
> >configId="com/foo/test"
> >parentId="geronimo/j2ee-server/1.0/car">
> >
> >
> >log4j
> >log4j
> >1.2.8
> >
> >
> >
> >
> > >
> >
> class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"
> >name="anonymous"/>
> >
> >
> >
> >
> >
> > >
> >
> 
> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
> >name="foo_admin"/>
> >
> >
> >
> >
> > >
> >
> 
> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
> >name="foo_user"/>
> >
> 

[jira] Closed: (GERONIMODEVTOOLS-62) NPE in starting Geronimo server

[Sachin Patel (JIRA)]

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

Sachin Patel closed GERONIMODEVTOOLS-62.


Resolution: Invalid
  Assignee: Sachin Patel

As long as the geronimo plans exist, I cannot reproduce the exception based on 
these steps. As far as the error regarding the server-config.wsdd file, I don't 
think this is an error.  Does it cause an error when testing the ws?

> NPE in starting Geronimo server
> ---
>
> Key: GERONIMODEVTOOLS-62
> URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-62
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
> Environment: Windows XP
>Reporter: Kathy Chan
> Assigned To: Sachin Patel
>
> Driver:  WTP M200602070438 + Geronimo 0206_1658 plugins + Geronimo 1.0 server
> When going through bottom-up Web service scenario selecting to "generate 
> proxy" and "test Web service",  the Geronimo server comes up with the 
> following error in the console:
> Geronimo startup complete
> 11:27:42,031 ERROR [EngineConfigurationFactoryServlet] Unable to find config 
> file.  Creating new servlet engine config file: /WEB-INF/server-config.wsdd
> 11:28:08,879 ERROR [EngineConfigurationFactoryServlet] Unable to find config 
> file.  Creating new servlet engine config file: /WEB-INF/server-config.wsdd
> 11:28:55,627 ERROR [EngineConfigurationFactoryServlet] Unable to find config 
> file.  Creating new servlet engine config file: /WEB-INF/server-config.wsdd
> 11:28:55,787 ERROR [EngineConfigurationFactoryServlet] Unable to find config 
> file.  Creating new servlet engine config file: /WEB-INF/server-config.wsdd
> 11:29:03,798 WARN  [TomcatModuleBuilder] Web application does not contain a 
> WEB-INF/geronimo-web.xml deployment plan.  This may or may not be a problem, 
> depending on whether you have things like resource references that need to be 
> resolved.  You can also give the deployer a separate deployment plan file on 
> the command line.
> 11:29:04,119 DEBUG [GBeanSingleReference] Waiting to start 
> geronimo.server:J2EEApplication=Application_ID,J2EEServer=geronimo,j2eeType=WebModule,name=g2Client.war
>  because no targets are running for reference J2EEApplication matching the 
> patterns 
> geronimo.server:J2EEServer=geronimo,j2eeType=J2EEApplication,name=Application_ID
>  
> 11:29:04,129 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[/g2Client] has not been started
> 11:29:04,129 ERROR [GBeanInstance] Problem in doFail of 
> geronimo.server:J2EEApplication=Application_ID,J2EEServer=geronimo,j2eeType=WebModule,name=g2Client.war
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:305)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke()
>   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>   at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
>   at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>   at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$9f00ee94.removeContext()
>   at 
> org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:424)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:955)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127)
>   at 
> org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38)
>   at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleB

Re: Single Sign On with Geronimo 1.0

[Paul McMahan]

I looked at using the Tomcat SSOValve for GERONIMO-973 and had a
similar experience -- i.e. it works fine but may not be appropriate in
many situations.  As I recall, what it basically does is stores the
credentials in a cookie with higher level scope, making it visible to
all the applications in the server instead of just the one that was
originally authenticated.

Since logging into the admin console should not grant access to other
applications deployed in the server I ended up using a different
approach for GERONIMO-973, which was to send all requests through a
single context that acted as a proxy for the other context(s).  This
works for SSO across multiple WARs in an EAR but may not work for SSO
across EARs.  See the comments in to GERONIMO-973 for details.  Your
idea for defining multiple hosts might be a clever way to work around
that issue.

As Jeff points out, it should not be necessary to rebuild the server
to use the SSOValve (unless something has changed recently). I just
enabled it in var/config/config.xml.

Best wishes,
Paul

On 8/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:

Why does the server need to be built with the SSOValve?

You should be able to connect the SSOValve to the TomcatEngine in the
config.xml.

Jeff

Vamsavardhana Reddy wrote:
> I could get SSO Working on a server build with SSOValve GBean in the
> tomcat plan.  In this case the application deployment plans needed no
> change as mentioned in the post that Krish pointed to.
>
> Here are some of my observations.
>
> An SSOValve GBean created as part of the application needs to be
> connected to TomcatEngine so that SSO works.  To do so, either the
> FirstValve in TomcatEngine needs to be replaced with this SSOValve or a
> "NextValve" attribute should be added to the FirstValve and it should be
> made point to the SSOValve.  I guess there is only one TomcatEngine
> GBean in the server and I don't think it should be modified to suit the
> needs of two or more applications that need SSO.
>
> Other way is to have multiple hosts defined in the tomcar plan and and
> one of them could have an SSOValve in the chain.  All apps that want SSO
> can use that host.
>
> In either case, the server needs to built with SSOValve GBean.
>
> With what G provides right now, there is noway that an SSOValve GBean is
> created as part of an application and hooked to the TomcatEngine.
>
> Comments?
>
> Thanks,
> Vamsi
>
> On 8/2/06, *Krishnakumar B* <[EMAIL PROTECTED]
> > wrote:
>
> Hi Joe,
>
> I have also tried this and was able to get it to work by doing a build
> with SSOValve GBean open.
>
> Refer to earlier post :
> http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647
> 
>
> I was not able to get it to work by deploying a new Valve along with 2
> web applications that need SSO.
>
> Regards
> Krish.
>
> On 8/1/06, Joe O'Pecko <[EMAIL PROTECTED]
> > wrote:
> > I know this has been discussed in the past, and I
> > apologize for the lengthy inquiry, however, I have
> > been trying unsuccessfully to get SSO working with
> > Tomcat on Geronimo v1.0 for some time. I am deploying
> > an application as an ear file with two war files
> > contained within. My geronimo-application.xml file
> > contains a definition for a JAAS Security Realm and
> > the two WAR file's geronimo-web.xml reference it via
> > security-realm-name elements. Once deployed each web
> > application challenges the user upon first access,
> > using the configured JAAS LoginModule. I'd like to
> > establish a SSO trust between the two web
> > applications, if possible, so that a user is only
> > challenged once for both web applications.
> >
> > I've seen a previous post on this site entitled Single
> > Sign On : Tomcat in Geronimo
> > (http://tinyurl.com/lkgjy) which seemed to provide
> > some information. Basically, it suggested the addition
> > of a SSOValve GBean to the geronimo-web.xml file. As
> > suggested, I've added the SSOValve to each
> > geronimo-web.xml and confirmed that I could see them
> > running in the deploy-tool web application. However,
> > each application has its own SSOValve GBean running
> > which leads me to believe that they do not share
> > anything between them.
> >
> > I've also seen Aaron Mulder's website which states
> > that Geronimo does not natively support web-based
> > single sign-on across web sites
> > (http://tinyurl.com/qa9bl).
> >
> > So is it possible to provide Single Sign On accross
> > web applications? I've attached my config files below
> > if it helps.
> >
> > Thanks in advance for any help and information you can
> > provide.
> >
> > Joe
> >
> > ---begin geronimo-application.xml---
> > 
> >
>

Re: Single Sign On with Geronimo 1.0

[Vamsavardhana Reddy]

You are right.  By "server built with SSOValve", I meant to say it should be part of Tomcat configuration.

Thanks,
Vamsi
On 8/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Why does the server need to be built with the SSOValve?You should be able to connect the SSOValve to the TomcatEngine in theconfig.xml.JeffVamsavardhana Reddy wrote:> I could get SSO Working on a server build with SSOValve GBean in the
> tomcat plan.  In this case the application deployment plans needed no> change as mentioned in the post that Krish pointed to.>> Here are some of my observations.>> An SSOValve GBean created as part of the application needs to be
> connected to TomcatEngine so that SSO works.  To do so, either the> FirstValve in TomcatEngine needs to be replaced with this SSOValve or a> "NextValve" attribute should be added to the FirstValve and it should be
> made point to the SSOValve.  I guess there is only one TomcatEngine> GBean in the server and I don't think it should be modified to suit the> needs of two or more applications that need SSO.>
> Other way is to have multiple hosts defined in the tomcar plan and and> one of them could have an SSOValve in the chain.  All apps that want SSO> can use that host.>> In either case, the server needs to built with SSOValve GBean.
>> With what G provides right now, there is noway that an SSOValve GBean is> created as part of an application and hooked to the TomcatEngine.>> Comments?>> Thanks,> Vamsi
>> On 8/2/06, *Krishnakumar B* <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>> Hi Joe,
>> I have also tried this and was able to get it to work by doing a build> with SSOValve GBean open.>> Refer to earlier post :> 
http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647> 
>> I was not able to get it to work by deploying a new Valve along with 2> web applications that need SSO.>> Regards> Krish.>> On 8/1/06, Joe O'Pecko <
[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:> > I know this has been discussed in the past, and I
> > apologize for the lengthy inquiry, however, I have> > been trying unsuccessfully to get SSO working with> > Tomcat on Geronimo v1.0 for some time. I am deploying> > an application as an ear file with two war files
> > contained within. My geronimo-application.xml file> > contains a definition for a JAAS Security Realm and> > the two WAR file's geronimo-web.xml reference it via> > security-realm-name elements. Once deployed each web
> > application challenges the user upon first access,> > using the configured JAAS LoginModule. I'd like to> > establish a SSO trust between the two web> > applications, if possible, so that a user is only
> > challenged once for both web applications.> >> > I've seen a previous post on this site entitled Single> > Sign On : Tomcat in Geronimo> > (
http://tinyurl.com/lkgjy) which seemed to provide> > some information. Basically, it suggested the addition> > of a SSOValve GBean to the geronimo-web.xml file. As> > suggested, I've added the SSOValve to each
> > geronimo-web.xml and confirmed that I could see them> > running in the deploy-tool web application. However,> > each application has its own SSOValve GBean running> > which leads me to believe that they do not share
> > anything between them.> >> > I've also seen Aaron Mulder's website which states> > that Geronimo does not natively support web-based> > single sign-on across web sites
> > (http://tinyurl.com/qa9bl).> >> > So is it possible to provide Single Sign On accross> > web applications? I've attached my config files below
> > if it helps.> >> > Thanks in advance for any help and information you can> > provide.> >> > Joe> >> > ---begin 
geronimo-application.xml---> > > >> > > >> > xmlns="
http://geronimo.apache.org/xml/ns/j2ee/application"> >> > xmlns:sec=" http://geronimo.apache.org/xml/ns/security-1.1"
> >configId="com/foo/test"> >parentId="geronimo/j2ee-server/1.0/car">> >> >> >log4j
> >log4j> >1.2.8> >> >> >
>
>> >> >> >> class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal">
>name="anonymous"/>> >> >> >>
>>
>>
>> >> >> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal">
>name="foo_admin"/>>
>> >>
>>
>>
>> >> >> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal">
>name="foo_user"/>> 

[jira] Created: (SM-517) Re-structure the common/soap shared libraries

[Philip Dodds (JIRA)]

Re-structure the common/soap shared libraries
-

 Key: SM-517
 URL: https://issues.apache.org/activemq/browse/SM-517
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-common, servicemix-soap
Affects Versions: 3.0-M2
Reporter: Philip Dodds
 Fix For: 3.0-M3


Re-organize the common and soap libraries so they are normal jar packaging and 
then create a new shared library called servicemix-shared that will have both 
libraries embedded.  

This removes the dependency that soap has on common being an issue when soap is 
an SL.

-- 
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: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)

[Alan D. Cabrera]

Yeah, I'm kinda confused.  Why do we need to include the Derby NOTICE?


Regards,
Alan

James Strachan wrote:

I thought the NOTICE file for Derby was just that its ASF code? Or is
the specific Deby stuff that needs adding to the NOTICE file?

On 8/3/06, Kevan Miller <[EMAIL PROTECTED]> wrote:

Hi Hiram,
Is the NOTICE file correct? I believe you need a NOTICE for derby, at
least.

Also, the shell scripts in /bin are not marked executable when I
untar the tar distribution...

--kevan

On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote:

> Some LICENSE file issues were found in the first release candidate
> of the
> 4.0.2 build.  I have cut and RC 2 of the 4.0.2 build with the fixes
> and it's
> available here:
>
>
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/
> maven1/incubator-activemq/distributions/
>
> Maven 1 and Maven 2 repos for this release can be found at:
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2
>
> Here's the wiki page for the release notes (they should soon get
> mirrored to
> the activemq static website) :
> http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release
>
> Please vote to approve this release binary
>
> [ ] +1 Release the binary as Apache ActiveMQ  4.0.2
> [ ] -1 Veto the release (provide specific comments)
>
> If this vote passes, then we will then ask the Incubator PMC for their
> blessing to ship this release officially.
>
> Here's my +1
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com

Re: Single Sign On with Geronimo 1.0

[Vamsavardhana Reddy]

Seeing your reply, I have to add the following to my original comments.

I have tested SSO with two WebApps deployed as part of an EAR.  I
do not know if enabling SSO for Web Apps deployed independently
requires any changes in their deployment plans.

Thanks,
VamsiOn 8/7/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
I looked at using the Tomcat SSOValve for GERONIMO-973 and had asimilar experience -- i.e. it works fine but may not be appropriate inmany situations.  As I recall, what it basically does is stores thecredentials in a cookie with higher level scope, making it visible to
all the applications in the server instead of just the one that wasoriginally authenticated.Since logging into the admin console should not grant access to otherapplications deployed in the server I ended up using a different
approach for GERONIMO-973, which was to send all requests through asingle context that acted as a proxy for the other context(s).  Thisworks for SSO across multiple WARs in an EAR but may not work for SSOacross EARs.  See the comments in to GERONIMO-973 for details.  Your
idea for defining multiple hosts might be a clever way to work aroundthat issue.As Jeff points out, it should not be necessary to rebuild the serverto use the SSOValve (unless something has changed recently). I just
enabled it in var/config/config.xml.Best wishes,PaulOn 8/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:> Why does the server need to be built with the SSOValve?
>> You should be able to connect the SSOValve to the TomcatEngine in the> config.xml.>> Jeff>> Vamsavardhana Reddy wrote:> > I could get SSO Working on a server build with SSOValve GBean in the
> > tomcat plan.  In this case the application deployment plans needed no> > change as mentioned in the post that Krish pointed to.> >> > Here are some of my observations.> >
> > An SSOValve GBean created as part of the application needs to be> > connected to TomcatEngine so that SSO works.  To do so, either the> > FirstValve in TomcatEngine needs to be replaced with this SSOValve or a
> > "NextValve" attribute should be added to the FirstValve and it should be> > made point to the SSOValve.  I guess there is only one TomcatEngine> > GBean in the server and I don't think it should be modified to suit the
> > needs of two or more applications that need SSO.> >> > Other way is to have multiple hosts defined in the tomcar plan and and> > one of them could have an SSOValve in the chain.  All apps that want SSO
> > can use that host.> >> > In either case, the server needs to built with SSOValve GBean.> >> > With what G provides right now, there is noway that an SSOValve GBean is
> > created as part of an application and hooked to the TomcatEngine.> >> > Comments?> >> > Thanks,> > Vamsi> >> > On 8/2/06, *Krishnakumar B* <
[EMAIL PROTECTED]> > [EMAIL PROTECTED]>> wrote:> >> > Hi Joe,> >> > I have also tried this and was able to get it to work by doing a build
> > with SSOValve GBean open.> >> > Refer to earlier post :> > http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647
> > > >> > I was not able to get it to work by deploying a new Valve along with 2
> > web applications that need SSO.> >> > Regards> > Krish.> >> > On 8/1/06, Joe O'Pecko <[EMAIL PROTECTED]
> > [EMAIL PROTECTED]>> wrote:> > > I know this has been discussed in the past, and I> > > apologize for the lengthy inquiry, however, I have
> > > been trying unsuccessfully to get SSO working with> > > Tomcat on Geronimo v1.0 for some time. I am deploying> > > an application as an ear file with two war files
> > > contained within. My geronimo-application.xml file> > > contains a definition for a JAAS Security Realm and> > > the two WAR file's geronimo-web.xml reference it via
> > > security-realm-name elements. Once deployed each web> > > application challenges the user upon first access,> > > using the configured JAAS LoginModule. I'd like to
> > > establish a SSO trust between the two web> > > applications, if possible, so that a user is only> > > challenged once for both web applications.> > >
> > > I've seen a previous post on this site entitled Single> > > Sign On : Tomcat in Geronimo> > > (http://tinyurl.com/lkgjy) which seemed to provide
> > > some information. Basically, it suggested the addition> > > of a SSOValve GBean to the geronimo-web.xml file. As> > > suggested, I've added the SSOValve to each
> > > geronimo-web.xml and confirmed that I could see them> > > running in the deploy-tool web application. However,> > > each application has its own SSOValve GBean running
> > > which leads me to believe that they do not share> > > anything between them.> > >> > > I've also seen Aaron Mulder's website which states> > > that Geronimo does not natively support web-based
> > > single sign-on acro

Re: Maven2... we are almost there!

[Aaron Mulder]

On 8/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

On Aug 6, 2006, at 2:05 PM, Aaron Mulder wrote:
> * If a Geronimo server is running on the same machine, the bootstrap
> will fail due to test errors.  It failed before OpenEJB was checked
> out.

Is this specific to the m2 build?  What are the specific errors, in
which modules?


It happened in M1 build too, but there wasn't so much on the line in
the M1 build because it was easier to take up from where you left off,
whereas bootstrap (especially with tests) is more or less a giant
all-or-nothing.  The problem, the first problem anyway, is in the
security module tests, and I don't know the specific errors but it
connects to the running Geronimo server instead of a test instance and
gets hosed up.


Bootstrap is not meant to get everything up and running as quickly as
possible... it only exists as a temporary measure to help ensure that
the team can build and get predictable results while minimizing user
error.


Hmm.  But we only recommend running bootstrap once right?  Not every
time you build?

Are we planning to get rid of bootstrap relatively quickly or is that
always going to be part of the "first build" procedure?

Thanks,
   Aaron

Re: Single Sign On with Geronimo 1.0

[Jeff Genender]

It shouldn't... if you apply the SSOValve at the host or engine levels,
then all web apps underneath will then be using the SSOValve via
inheritance.

Jeff

Vamsavardhana Reddy wrote:
> Seeing your reply, I have to add the following to my original comments.
> 
> I have tested SSO with two WebApps deployed as part of an EAR.  I do not
> know if enabling SSO for Web Apps deployed independently requires any
> changes in their deployment plans.
> 
> Thanks,
> Vamsi
> 
> On 8/7/06, *Paul McMahan* <[EMAIL PROTECTED]
> > wrote:
> 
> I looked at using the Tomcat SSOValve for GERONIMO-973 and had a
> similar experience -- i.e. it works fine but may not be appropriate in
> many situations.  As I recall, what it basically does is stores the
> credentials in a cookie with higher level scope, making it visible to
> all the applications in the server instead of just the one that was
> originally authenticated.
> 
> Since logging into the admin console should not grant access to other
> applications deployed in the server I ended up using a different
> approach for GERONIMO-973, which was to send all requests through a
> single context that acted as a proxy for the other context(s).  This
> works for SSO across multiple WARs in an EAR but may not work for SSO
> across EARs.  See the comments in to GERONIMO-973 for details.  Your
> idea for defining multiple hosts might be a clever way to work around
> that issue.
> 
> As Jeff points out, it should not be necessary to rebuild the server
> to use the SSOValve (unless something has changed recently). I just
> enabled it in var/config/config.xml.
> 
> Best wishes,
> Paul
> 
> On 8/7/06, Jeff Genender <[EMAIL PROTECTED]
> > wrote:
> > Why does the server need to be built with the SSOValve?
> >
> > You should be able to connect the SSOValve to the TomcatEngine in the
> > config.xml.
> >
> > Jeff
> >
> > Vamsavardhana Reddy wrote:
> > > I could get SSO Working on a server build with SSOValve GBean in
> the
> > > tomcat plan.  In this case the application deployment plans
> needed no
> > > change as mentioned in the post that Krish pointed to.
> > >
> > > Here are some of my observations.
> > >
> > > An SSOValve GBean created as part of the application needs to be
> > > connected to TomcatEngine so that SSO works.  To do so, either the
> > > FirstValve in TomcatEngine needs to be replaced with this
> SSOValve or a
> > > "NextValve" attribute should be added to the FirstValve and it
> should be
> > > made point to the SSOValve.  I guess there is only one TomcatEngine
> > > GBean in the server and I don't think it should be modified to
> suit the
> > > needs of two or more applications that need SSO.
> > >
> > > Other way is to have multiple hosts defined in the tomcar plan
> and and
> > > one of them could have an SSOValve in the chain.  All apps that
> want SSO
> > > can use that host.
> > >
> > > In either case, the server needs to built with SSOValve GBean.
> > >
> > > With what G provides right now, there is noway that an SSOValve
> GBean is
> > > created as part of an application and hooked to the TomcatEngine.
> > >
> > > Comments?
> > >
> > > Thanks,
> > > Vamsi
> > >
> > > On 8/2/06, *Krishnakumar B* < [EMAIL PROTECTED]
> 
> > > >> wrote:
> > >
> > > Hi Joe,
> > >
> > > I have also tried this and was able to get it to work by
> doing a build
> > > with SSOValve GBean open.
> > >
> > > Refer to earlier post :
> > > http://www.nabble.com/SSO-in-Tomcat-tf1478623.html#a4001647
> 
> > > 
> > >
> > > I was not able to get it to work by deploying a new Valve
> along with 2
> > > web applications that need SSO.
> > >
> > > Regards
> > > Krish.
> > >
> > > On 8/1/06, Joe O'Pecko <[EMAIL PROTECTED]
> 
> > > >> wrote:
> > > > I know this has been discussed in the past, and I
> > > > apologize for the lengthy inquiry, however, I have
> > > > been trying unsuccessfully to get SSO working with
> > > > Tomcat on Geronimo v1.0 for some time. I am deploying
> > > > an application as an ear file with two war files
> > > > contained within. My geronimo-application.xml file
> > > > contains a definition for a JAAS Security Realm and
> > > > the two WAR file's geronimo-web.xml reference it via
> > >   

Geronimo RTC Workflow Scheme v2

[Alan D. Cabrera]

Previously, this was set up so that only new features and improvements 
followed the RTC flow.  Now, this new scheme includes all issue types.  
Does anyone know why this was changed?



Regards,
Alan

[jira] Assigned: (GERONIMO-2268) Security Realm with more than one LoginModule does not function as expected

[Alan Cabrera (JIRA)]

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

Alan Cabrera reassigned GERONIMO-2268:
--

Assignee: Alan Cabrera

> Security Realm with more than one LoginModule does not function as expected
> ---
>
> Key: GERONIMO-2268
> URL: http://issues.apache.org/jira/browse/GERONIMO-2268
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 1.1, 1.1.1, 1.1.x
> Environment: Win XP, G1.1.1-SNAPSHOT, Tomact
>Reporter: Vamsavardhana Reddy
> Assigned To: Alan Cabrera
> Fix For: 1.1.x, 1.2
>
>
> I have created a security realm consisting two login modules.  I have set the 
> control-flag as "REQUIRED" on both the login modules.  The second login 
> module is supposed to be invoked whether or not the first one succeeds. But 
> the second login module is not invoked when the first one fails.

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

[jira] Created: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly

[Aaron Mulder (JIRA)]

Abstract/Maven repositories install modules incorrectly
---

 Key: GERONIMO-2288
 URL: http://issues.apache.org/jira/browse/GERONIMO-2288
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: kernel, Plugins
Affects Versions: 1.1
Reporter: Aaron Mulder
 Assigned To: Aaron Mulder
 Fix For: 1.2, 1.1.1


The repository unpacks a JAR when it installs it only if the Artifact type is 
"car".  That is incorrect -- it should unpack any module with 
META-INF/config.ser (which is the logic that we use in other places, such as 
RepositoryConfigurationStore).  This breaks plugins that don't have the type 
"car" (such as copying a database pool from server to server).

The currently handling attempts to be generic by associating a behavior with 
each file type, though in practice this is only used for type=car.  In the 1.1 
branch, I am going to put in a workaround to look up the "car" handler any time 
we find a META-INF/config.ser (a pretty minimal workaround).

In trunk, I think we should remove the behavior/type association and instead 
have a boolean for whether configurations should be unpacked, or an 
"ArtifactTypeHandler" property specifically for configurations and another one 
for non-configurations.  I don't see any reason to distinguish based on module 
type.  Input would be appreciated for the 1.2 resolution.

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

[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2288:
---

Fix Version/s: (was: 1.1.1)

> Abstract/Maven repositories install modules incorrectly
> ---
>
> Key: GERONIMO-2288
> URL: http://issues.apache.org/jira/browse/GERONIMO-2288
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel, Plugins
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
> Fix For: 1.2
>
>
> The repository unpacks a JAR when it installs it only if the Artifact type is 
> "car".  That is incorrect -- it should unpack any module with 
> META-INF/config.ser (which is the logic that we use in other places, such as 
> RepositoryConfigurationStore).  This breaks plugins that don't have the type 
> "car" (such as copying a database pool from server to server).
> The currently handling attempts to be generic by associating a behavior with 
> each file type, though in practice this is only used for type=car.  In the 
> 1.1 branch, I am going to put in a workaround to look up the "car" handler 
> any time we find a META-INF/config.ser (a pretty minimal workaround).
> In trunk, I think we should remove the behavior/type association and instead 
> have a boolean for whether configurations should be unpacked, or an 
> "ArtifactTypeHandler" property specifically for configurations and another 
> one for non-configurations.  I don't see any reason to distinguish based on 
> module type.  Input would be appreciated for the 1.2 resolution.

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

[jira] Commented: (GERONIMODEVTOOLS-73) Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get to the server's publish directory

[Sachin Patel (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73?page=comments#action_12426241
 ] 

Sachin Patel commented on GERONIMODEVTOOLS-73:
--

Kathy, is what I've provided you suffient? Do your scenarios pass? If so can I 
mark this as fixed?

> Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get 
> to the server's publish directory
> -
>
> Key: GERONIMODEVTOOLS-73
> URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 1.0.0
> Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
>Reporter: Kathy Chan
> Assigned To: Sachin Patel
>
> After creating a Web service using the Web service wizard on a Web project 
> targetting Geronimo server, the file server-config.wsdd is generated in the 
> server installation config-store directory under /WEB-INF.  
> However, if I change something in the EAR and republish, the 
> server-config.wsdd file is gone.  Note that the server-config.wsdd file is 
> not in the workspace. 
> I am relying on the IModulePublishHelper.getPublishDirectory() API in the 
> org.eclipse.wst.server.core plugin to get the server's publish directory in 
> order to copy the server-config.wsdd file into the workspace so that next 
> time the WAR/EAR is re-published, the information of what was deployed to the 
> Axis servlet is persisted.
> Tomcat is currently implementing that and Geronimo needs to implement 
> IModulePublishHelper.getPublishDirectory() as well.
> Here's the current implementation in TomcatBehaviour.getPublishDirectory():
> /**
>* Returns the path that the module is
>* published to when in test environment mode.
>* 
>* @param module a module on the server 
>* @return the path that the module is published to when in test 
> environment mode,
>*or null if not running as a test environment or the module is not 
> a web module
>*/
>   public IPath getPublishDirectory(IModule[] module) {
>   if (!getTomcatServer().isTestEnvironment() || module == null || 
> module.length != 1)
>   return null;
>   
>   return 
> getTempDirectory().append("webapps").append(module[0].getName());
>   }
> This solution would solve the problem for getting to server-config.wsdd for 
> Axis Web service but there is still a bigger general problem with files 
> created in the config-store directory not mirrored in the workspace.  
> Hopefully this will be addressed in the next release of the Geronimo plugin.

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

[jira] Closed: (GERONIMO-2258) Abstract/Maven repositories install modules incorrectly

[Aaron Mulder (JIRA)]

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

Aaron Mulder closed GERONIMO-2258.
--

Fix Version/s: (was: 1.2)
   Resolution: Fixed

Closing as fixed in 1.1.1.  Created a separate issue for 1.2.

> Abstract/Maven repositories install modules incorrectly
> ---
>
> Key: GERONIMO-2258
> URL: http://issues.apache.org/jira/browse/GERONIMO-2258
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel, Plugins
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
> Fix For: 1.1.1
>
>
> The repository unpacks a JAR when it installs it only if the Artifact type is 
> "car".  That is incorrect -- it should unpack any module with 
> META-INF/config.ser (which is the logic that we use in other places, such as 
> RepositoryConfigurationStore).  This breaks plugins that don't have the type 
> "car" (such as copying a database pool from server to server).
> The currently handling attempts to be generic by associating a behavior with 
> each file type, though in practice this is only used for type=car.  In the 
> 1.1 branch, I am going to put in a workaround to look up the "car" handler 
> any time we find a META-INF/config.ser (a pretty minimal workaround).
> In trunk, I think we should remove the behavior/type association and instead 
> have a boolean for whether configurations should be unpacked, or an 
> "ArtifactTypeHandler" property specifically for configurations and another 
> one for non-configurations.  I don't see any reason to distinguish based on 
> module type.  Input would be appreciated for the 1.2 resolution.

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

Re: Regarding Exploded Deployments

[Gianny Damour]

Hi Manu,

Thanks for having a look at this piece of code. EJB modules do not need 
to be auto-exploded as they are JAR modules and the classloader used to 
load EJB classes (a MulitParentClassLoader) can directly load classes 
from JARs. In the case of WEB modules, they need to be exploded as, 
AFAIK, Jetty and Tomcat do not support packed WAR modules.


Also, while re-reading my email, I spotted a potential 
mis-interpretation. The problem you are raising only happens when an EAR 
module contains a non-exploded WAR module. In other words, if you unjar 
web.war within a web.war sub-folder, then everything should be OK.


Thanks,
Gianny

Manu George wrote:


Hi Gianny,
 Thanks for the explanation. Are ejb modules also auto
exploded? I saw that war's are exploded but ejb modules don't seem to
be auto exploded. Any reason for this?

Thanks
Manu

On 8/5/06, Gianny Damour <[EMAIL PROTECTED]> wrote:


Manu George wrote:

> Hi,
>   Does Geronimo support exploded deployments of ear's that
> contain wars and jars using --inPlace Argument? When I try to deploy
> daytrader by extracting it  to a directory and passing the path to the
> directory as an argument to deploy along with --inPlace it is giving
> an error
>
> java.lang.Error: Only local file jars are supported
> jar:file:/C:/1.1samples/samp
> 
les/applications/daytrader/target/test/daytrader-ear-1.1/web.war!/WEB-INF/lib/st 


>
> andard-1.1.1.jar

There is a bug in the deployment of war module defining libraries within
WEB-INF/lib/ when this module is inside an ear module. I will fix this
problem.

> What is the correct format of an exploded EAR. Will it have the
> ejb-jar and webapp-war exploded as well? OR will geronimo support non
> exploded format as well?

In the case of an in-place deployment, nested modules are auto-exploded
upon deployment, if need be. For instance, if there is a non-exploded
war module mywar.war within an ear, then the war is renamed
mywar.war.saved, a sub-directory mywar.war is created and
mywar.war.saved is unjarred within it.

Thanks,
Gianny

>
> Regards
> Manu
>

[jira] Created: (GERONIMO-2289) GeronimoAsMavenServlet.java generates wrong default-repository element

[Aaron Mulder (JIRA)]

GeronimoAsMavenServlet.java generates wrong default-repository element
--

 Key: GERONIMO-2289
 URL: http://issues.apache.org/jira/browse/GERONIMO-2289
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Plugins
Affects Versions: 1.1
Reporter: Aaron Mulder
 Assigned To: Aaron Mulder
 Fix For: 1.2, 1.1.1


The GeronimoAsMavenServlet generates a XML document which contains an element 
called 'default-repository' (see 
http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The 
value of this element looks like:

--- 8< ---
...

   HTTP/1.1://localhost:8081/console-standard/maven-repo/


--- 8< ---

With this issue it isn't possible to import a plugin from a Geronimo Server 
running somewhere.

This should be:

--- 8< ---
...

   http://localhost:8081/console-standard/maven-repo/


--- 8< ---

The attached patch resolves this issue.

Kristian




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

[jira] Updated: (GERONIMO-2289) GeronimoAsMavenServlet.java generates wrong default-repository element

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2289:
---

Fix Version/s: (was: 1.1.1)

Changes are applied to trunk, but there's still a problem (with copying modules 
with types other than "car") in trunk until GERONIMO-2288 is fixed in trunk too.

> GeronimoAsMavenServlet.java generates wrong default-repository element
> --
>
> Key: GERONIMO-2289
> URL: http://issues.apache.org/jira/browse/GERONIMO-2289
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
> Fix For: 1.2
>
>
> The GeronimoAsMavenServlet generates a XML document which contains an element 
> called 'default-repository' (see 
> http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The 
> value of this element looks like:
> --- 8< ---
> ...
> 
>HTTP/1.1://localhost:8081/console-standard/maven-repo/
> 
> --- 8< ---
> With this issue it isn't possible to import a plugin from a Geronimo Server 
> running somewhere.
> This should be:
> --- 8< ---
> ...
> 
>http://localhost:8081/console-standard/maven-repo/
> 
> --- 8< ---
> The attached patch resolves this issue.
> Kristian

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

[jira] Created: (GERONIMO-2290) Percent complete goes over 100% when installing configurations

[Aaron Mulder (JIRA)]

Percent complete goes over 100% when installing configurations
--

 Key: GERONIMO-2290
 URL: http://issues.apache.org/jira/browse/GERONIMO-2290
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: core, console
Affects Versions: 1.1
Reporter: Aaron Mulder
Priority: Critical
 Fix For: 1.1.x


Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, 
whereas the % is based on the content size returned by the server for the 
download (the "compressed" byte count).

Probably should use an InputStream between the download stream and the ZIP 
stream that performs the count on read(byte[],int,int) and them use that count 
instead of the uncompressed count.

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

[jira] Updated: (GERONIMO-2290) Percent complete goes over 100% when installing configurations

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2290:
---

Fix Version/s: 1.2
   (was: 1.1.x)

Someone applied a fix to always count the unnpacked bytes of a JAR but...

We have yet another problem with this issue, which is that packed artifacts 
should used the file size, whereas artifacts that are going to be unpacked 
should use the size of the contents.  We currently unpack CARs but leave JARs 
packed.

Workaround applied to 1.1 but not applying to trunk because this really ought 
to be reconsidered in light of GERONIMO-2288 (if we're going to change the way 
we decide whether to unpack, we should also change when we do the size 
calculation so we only do it if we're going to unpack the artifact anyway).


> Percent complete goes over 100% when installing configurations
> --
>
> Key: GERONIMO-2290
> URL: http://issues.apache.org/jira/browse/GERONIMO-2290
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, console
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Priority: Critical
> Fix For: 1.2
>
>
> Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, 
> whereas the % is based on the content size returned by the server for the 
> download (the "compressed" byte count).
> Probably should use an InputStream between the download stream and the ZIP 
> stream that performs the count on read(byte[],int,int) and them use that 
> count instead of the uncompressed count.

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

Re: [Review] Support per property PropertyEditors

[Hiram Chirino]

Thanks for the votes guys.

On 8/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote:



David Jencks wrote:
> I've also voted, with matt's you have 3.
>
> Jeff, I think it would be clearer if we not only voted but commented
> that it's a RTC +1 vote.  Do we have a policy on this?  I think I saw it
> discussed somewhere

Yep...good point...I needed to do that.  I have been *really* busy
lately, so it slipped by...sorry about that.

I will update it now.

Jeff



>
>
> thanks
> david jencks
>
> On Aug 5, 2006, at 4:27 PM, Jeff Genender wrote:
>
>> I gave you one...
>>
>> Hiram Chirino wrote:
>>> Hi Everybody,
>>>
>>> I'm looking for 3 PMC +1s so that I can commit the patch attached to:
>>> http://issues.apache.org/jira/browse/XBEAN-36
>>>
>>> It basically allows us to do things like:
>>>
>>>  
>>>  
>>>  
>>>
>>> By annotating the property with a custom property editor that
>>> understands the "bytes", "k", "Megs" suffixes and knows how to create
>>> the right value.
>>>
>>> This would come in very handy in a couple of spots in the ActiveMQ
>>> configuration.
>>>




--
Regards,
Hiram

Blog: http://hiramchirino.com

[jira] Closed: (GERONIMO-2228) GeronimoAsMavenServlet.java generates wrong default-repository element

[Aaron Mulder (JIRA)]

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

Aaron Mulder closed GERONIMO-2228.
--

Fix Version/s: (was: 1.2)
   Resolution: Fixed

Closing as fixed in 1.1.1 -- separate issue created for trunk

> GeronimoAsMavenServlet.java generates wrong default-repository element
> --
>
> Key: GERONIMO-2228
> URL: http://issues.apache.org/jira/browse/GERONIMO-2228
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 1.1
>Reporter: Kristian Koehler
> Assigned To: Aaron Mulder
> Fix For: 1.1.1
>
> Attachments: diff.patch
>
>
> The GeronimoAsMavenServlet generates a XML document which contains an element 
> called 'default-repository' (see 
> http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The 
> value of this element looks like:
> --- 8< ---
> ...
> 
>HTTP/1.1://localhost:8081/console-standard/maven-repo/
> 
> --- 8< ---
> With this issue it isn't possible to import a plugin from a Geronimo Server 
> running somewhere.
> This should be:
> --- 8< ---
> ...
> 
>http://localhost:8081/console-standard/maven-repo/
> 
> --- 8< ---
> The attached patch resolves this issue.
> Kristian

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

[jira] Closed: (GERONIMO-1869) Percent complete goes over 100% when installing configurations

[Aaron Mulder (JIRA)]

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

Aaron Mulder closed GERONIMO-1869.
--

Fix Version/s: 1.1.1
   (was: 1.1.x)
   Resolution: Fixed
 Assignee: Aaron Mulder

Closing as fixed in 1.1.1.  Created a copy of this issue to track it in trunk.

> Percent complete goes over 100% when installing configurations
> --
>
> Key: GERONIMO-1869
> URL: http://issues.apache.org/jira/browse/GERONIMO-1869
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, console
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
>Priority: Critical
> Fix For: 1.1.1
>
>
> Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, 
> whereas the % is based on the content size returned by the server for the 
> download (the "compressed" byte count).
> Probably should use an InputStream between the download stream and the ZIP 
> stream that performs the count on read(byte[],int,int) and them use that 
> count instead of the uncompressed count.

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

Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)

[Kevan Miller]

The NOTICE file needs to contain the ASF Notice plus any notice  
information required by software included in your release. Look at  
the NOTICE file that Derby distributes (I sent it in response to  
Hiram). You include Derby in your release. So, you need to include  
the additional Derby notice information in your NOTICE file.


--kevan

On Aug 7, 2006, at 10:46 AM, Alan D. Cabrera wrote:


Yeah, I'm kinda confused.  Why do we need to include the Derby NOTICE?


Regards,
Alan

James Strachan wrote:

I thought the NOTICE file for Derby was just that its ASF code? Or is
the specific Deby stuff that needs adding to the NOTICE file?

On 8/3/06, Kevan Miller <[EMAIL PROTECTED]> wrote:

Hi Hiram,
Is the NOTICE file correct? I believe you need a NOTICE for  
derby, at

least.

Also, the shell scripts in /bin are not marked executable when I
untar the tar distribution...

--kevan

On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote:

> Some LICENSE file issues were found in the first release candidate
> of the
> 4.0.2 build.  I have cut and RC 2 of the 4.0.2 build with the  
fixes

> and it's
> available here:
>
>
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/
> maven1/incubator-activemq/distributions/
>
> Maven 1 and Maven 2 repos for this release can be found at:
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2
>
> Here's the wiki page for the release notes (they should soon get
> mirrored to
> the activemq static website) :
> http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2 
+Release

>
> Please vote to approve this release binary
>
> [ ] +1 Release the binary as Apache ActiveMQ  4.0.2
> [ ] -1 Veto the release (provide specific comments)
>
> If this vote passes, then we will then ask the Incubator PMC  
for their

> blessing to ship this release officially.
>
> Here's my +1
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com

[jira] Created: (GERONIMO-2291) Allow WebServiceBuilder determine if there are WebServices to be deployed

[Aaron Mulder (JIRA)]

Allow WebServiceBuilder determine if there are WebServices to be deployed
-

 Key: GERONIMO-2291
 URL: http://issues.apache.org/jira/browse/GERONIMO-2291
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: webservices
Affects Versions: 1.1
 Environment: all
Reporter: Aaron Mulder
 Assigned To: David Jencks
 Fix For: 1.1.1, 1.2


Each J2EE module deployer (EJB, Tomcat, Jetty) must decide if the module being 
deployed has a WebService endpoint.  Currently, this requires the deployer to 
check for the presence of a webservices.xml file.  This makes it awkward to add 
support for JAXWS style web services to Geronimo.  

A better solution is to push the WS endpoint check into the webservice 
deployer.  This simplifies the logic of webservice deployment and also allows 
for more flexible options (such as introducing a module that use JSE 5 features 
without polluting the existing deployers).

A patch for this attached.

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

[jira] Commented: (GERONIMO-2237) Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears

[Aaron Mulder (JIRA)]

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

Aaron Mulder commented on GERONIMO-2237:


If the fix was applied to 1.1.1, why is this issue still open?  Jeff, are you 
waiting for something before closing it?

> Filtering of springframework.org in TomcatDeployer plan creates CNF 
> Exceptions in Ears
> --
>
> Key: GERONIMO-2237
> URL: http://issues.apache.org/jira/browse/GERONIMO-2237
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1
>Reporter: Jeff Genender
>Priority: Blocker
> Fix For: 1.1.1
>
>
> Filtering of springframework.org in TomcatDeployer plan creates ClassNotFound 
> Exceptions in Ears when it tries to use a component that uses Spring in the 
> EAR.  We originally filtered this to automatically prevent Spring clashing 
> with a server based Spring (from 1.0).  This was fine for wars but when used 
> iun an ear, the web container is blocked from using the EAR version.  I 
> recommend we remove these filters as SPrin is not usable in an EAR.  
> Recommended patch for configs/tomcat-deployer:
> Index: src/plan/plan.xml
> ===
> --- src/plan/plan.xml   (revision 426203)
> +++ src/plan/plan.xml   (working copy)
> @@ -46,10 +46,7 @@
>  car
>  
>  
> -
> -antlr.
> -org.springframework.
> -
> +
>  
>  java.
>  javax.

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

Patches in RTC (Geronimo - August 7, 2006)

[dblevins]

Geronimo - August 7, 2006

  8 Patches in RTC

[XBEAN-33] [RTC] Add a new Wiki source generator that generates wiki markup 
so that reference docs can be pasted into confluence.
  - Assignee: Hiram Chirino
  - Reporter: Hiram Chirino
  - Created:  Tue, 1 Aug 2006 13:03:57 -0700 (PDT)
  - Updated:  Sat, 5 Aug 2006 17:53:19 -0700 (PDT)
  - Votes: 4
  1  Dain Sundstrom
  2  Guillaume Nodet
  3  Jeff Genender
  4  Matt Hogstrom
  - http://issues.apache.org/jira/browse/XBEAN-33

[XBEAN-31] [RTC] it would be great if the m2 plugin would automatically add 
the XSD and .xsd.html files as artifacts into the build
  - Assignee: Guillaume Nodet
  - Reporter: james strachan
  - Created:  Tue, 1 Aug 2006 03:37:03 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 16:00:52 -0700 (PDT)
  - Votes: 3
  1  Dain Sundstrom
  2  Guillaume Nodet
  3  Jeff Genender
  - http://issues.apache.org/jira/browse/XBEAN-31

[XBEAN-19] [RTC] Enable inverse classloading with the classpath element
  - Assignee: Guillaume Nodet
  - Reporter: Guillaume Nodet
  - Created:  Fri, 16 Jun 2006 14:13:24 -0700 (PDT)
  - Updated:  Tue, 1 Aug 2006 01:33:30 -0700 (PDT)
  - Votes: 2
  1  Dain Sundstrom
  2  Jeff Genender
  - http://issues.apache.org/jira/browse/XBEAN-19

[GERONIMO-2277] Remove TransactionContextManager
  - Assignee: Dain Sundstrom
  - Reporter: Dain Sundstrom
  - Created:  Fri, 4 Aug 2006 15:26:22 -0700 (PDT)
  - Updated:  Sat, 5 Aug 2006 21:17:04 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2277

[GERONIMO-2248] Applications portlets: List Parent and Child components 
against each component
  - Assignee: Unassigned
  - Reporter: Vamsavardhana Reddy
  - Created:  Sun, 30 Jul 2006 08:15:34 -0700 (PDT)
  - Updated:  Tue, 1 Aug 2006 02:08:20 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2248

[GERONIMO-2163] WADI Integration for Jetty
  - Assignee: Gianny Damour
  - Reporter: Gianny Damour
  - Created:  Sun, 2 Jul 2006 14:16:35 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 12:03:16 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2163

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri, 12 May 2006 14:54:17 -0700 (PDT)
  - Updated:  Fri, 4 Aug 2006 13:51:35 -0700 (PDT)
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMO-1563] [RTC] Make the JACC implementation pluggable
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed, 1 Feb 2006 02:26:12 -0800 (PST)
  - Updated:  Fri, 4 Aug 2006 12:02:25 -0700 (PDT)
  - Votes: 4
  1  Alan Cabrera
  2  Donald Woods
  3  Gianny Damour
  4  Jeff Genender
  - http://issues.apache.org/jira/browse/GERONIMO-1563


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the "Begin RTC Review"
link under the "Available Workflow Actions" of the JIRA page.

If you do not see your vote here, click the "Vote" link under the
"Operations" section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

[jira] Updated: (GERONIMO-2291) Allow WebServiceBuilder determine if there are WebServices to be deployed

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2291:
---

Fix Version/s: (was: 1.1.1)

This issue is a copy of GERONIMO-2030 that will track the changes to be applied 
to trunk.  See that issue for the discussion and patch.  Based on the last 
comment, David Jencks is scheduled to apply that patch to trunk.

> Allow WebServiceBuilder determine if there are WebServices to be deployed
> -
>
> Key: GERONIMO-2291
> URL: http://issues.apache.org/jira/browse/GERONIMO-2291
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 1.1
> Environment: all
>Reporter: Aaron Mulder
> Assigned To: David Jencks
> Fix For: 1.2
>
>
> Each J2EE module deployer (EJB, Tomcat, Jetty) must decide if the module 
> being deployed has a WebService endpoint.  Currently, this requires the 
> deployer to check for the presence of a webservices.xml file.  This makes it 
> awkward to add support for JAXWS style web services to Geronimo.  
> A better solution is to push the WS endpoint check into the webservice 
> deployer.  This simplifies the logic of webservice deployment and also allows 
> for more flexible options (such as introducing a module that use JSE 5 
> features without polluting the existing deployers).
> A patch for this attached.

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

[jira] Closed: (GERONIMO-2030) Allow WebServiceBuilder determine if there are WebServices to be deployed

[Aaron Mulder (JIRA)]

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

Aaron Mulder closed GERONIMO-2030.
--

Fix Version/s: (was: 1.2)
   Resolution: Fixed

Closing this as applied to 1.1.1 -- copied the issue to track the status in 
trunk.

> Allow WebServiceBuilder determine if there are WebServices to be deployed
> -
>
> Key: GERONIMO-2030
> URL: http://issues.apache.org/jira/browse/GERONIMO-2030
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 1.1
> Environment: all
>Reporter: Conrad O'Dea
> Assigned To: David Jencks
> Fix For: 1.1.1
>
> Attachments: find-web-services.patch, geronimo_ws_builder_change.patch
>
>
> Each J2EE module deployer (EJB, Tomcat, Jetty) must decide if the module 
> being deployed has a WebService endpoint.  Currently, this requires the 
> deployer to check for the presence of a webservices.xml file.  This makes it 
> awkward to add support for JAXWS style web services to Geronimo.  
> A better solution is to push the WS endpoint check into the webservice 
> deployer.  This simplifies the logic of webservice deployment and also allows 
> for more flexible options (such as introducing a module that use JSE 5 
> features without polluting the existing deployers).
> A patch for this attached.

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

[jira] Commented: (GERONIMO-2277) Remove TransactionContextManager

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-2277:
-

+1...this will be good to have.

> Remove TransactionContextManager
> 
>
> Key: GERONIMO-2277
> URL: http://issues.apache.org/jira/browse/GERONIMO-2277
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Reporter: Dain Sundstrom
> Assigned To: Dain Sundstrom
> Fix For: 1.2
>
> Attachments: GERONIMO-2277.patch
>
>
> If you use the  Geronimo TransactionContextManager,  you can't use the 
> TransactionManager interface directly since the TCM needs to know about all 
> TM calls.  Additionally, to use the TCM you must demarcate all changes in 
> "component context" by starting an unspecified transaction context.  This is 
> all quite invasive and makes it hard to use our code in third part 
> environments such as Spring or plain old Tomcat.
> I propose we remove the TransactionContextManager and replaced all uses with 
> a plain old TransactionManager.  This will also allow us to removed all code 
> from web containers, app client and timer that was simply demarcating an 
> unspecified transaction context, which is no longer needed.  

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

[jira] Closed: (GERONIMO-2237) Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-2237.
---

Fix Version/s: 1.2
   Resolution: Fixed

Was left open for discussion.  Will close as it seems to have been fine.

> Filtering of springframework.org in TomcatDeployer plan creates CNF 
> Exceptions in Ears
> --
>
> Key: GERONIMO-2237
> URL: http://issues.apache.org/jira/browse/GERONIMO-2237
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1
>Reporter: Jeff Genender
>Priority: Blocker
> Fix For: 1.1.1, 1.2
>
>
> Filtering of springframework.org in TomcatDeployer plan creates ClassNotFound 
> Exceptions in Ears when it tries to use a component that uses Spring in the 
> EAR.  We originally filtered this to automatically prevent Spring clashing 
> with a server based Spring (from 1.0).  This was fine for wars but when used 
> iun an ear, the web container is blocked from using the EAR version.  I 
> recommend we remove these filters as SPrin is not usable in an EAR.  
> Recommended patch for configs/tomcat-deployer:
> Index: src/plan/plan.xml
> ===
> --- src/plan/plan.xml   (revision 426203)
> +++ src/plan/plan.xml   (working copy)
> @@ -46,10 +46,7 @@
>  car
>  
>  
> -
> -antlr.
> -org.springframework.
> -
> +
>  
>  java.
>  javax.

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

Re: Geronimo RTC Workflow Scheme v2

[Guillaume Nodet]

I think that dblevins changed that, because in XBean, I had a "Wish" for which i provided a patch but was unableto put it in RTC mode.  RTC should also be applied to documentation, so why were these issue types excluded
from the workflow ?I think the main problem is that you can not easily recategorize issues if they do not have the same workflow.On 8/7/06, Alan D. Cabrera
 <[EMAIL PROTECTED]> wrote:Previously, this was set up so that only new features and improvements
followed the RTC flow.  Now, this new scheme includes all issue types.Does anyone know why this was changed?Regards,Alan-- Cheers,Guillaume Nodet

[jira] Created: (GERONIMO-2292) Investigate unused targetModuleId parameter in EJB refs

[Aaron Mulder (JIRA)]

Investigate unused targetModuleId parameter in EJB refs
---

 Key: GERONIMO-2292
 URL: http://issues.apache.org/jira/browse/GERONIMO-2292
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment, OpenEJB
Affects Versions: 1.1
Reporter: Aaron Mulder
 Assigned To: David Jencks
 Fix For: 1.1.1


In OpenEJBReferenceBuilder:

createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument.

Then they often call getMatch or getImplicitMatch and don't use the 
targetConfigId.  As a result, the current module's ID is always used as the 
targetConfigId:

context.findGBeans(new AbstractNameQuery(context.getId(), ...

This means that the query will never match EJBs in a parent of the current 
configuration.  It should be changed to use the targetConfigId instead of the 
current module's ID.

This does not come up if a pattern element is used in the mapping, though that 
mapping strategy runs into a different 1.1 bug (ClassCastException on 
org.openejb.proxy.ProxyInfo)

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

[jira] Updated: (GERONIMO-2292) Investigate unused targetConfigId parameter in EJB refs

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2292:
---

  Summary: Investigate unused targetConfigId parameter in EJB refs  
(was: Investigate unused targetModuleId parameter in EJB refs)
Fix Version/s: 1.1.2
   (was: 1.1.1)

David Jencks fixed the main problem in G 1.1.1 with this comment:

Fix in openejb 2.1.1 rev 2823. Still needs review of unused targetConfigId 
parameter.

This is a copy of the issue opened to track the "review of unused 
targetConfigId" parameter int he post-1.1.1 timeframe.

> Investigate unused targetConfigId parameter in EJB refs
> ---
>
> Key: GERONIMO-2292
> URL: http://issues.apache.org/jira/browse/GERONIMO-2292
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, OpenEJB
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: David Jencks
> Fix For: 1.1.2
>
>
> In OpenEJBReferenceBuilder:
> createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument.
> Then they often call getMatch or getImplicitMatch and don't use the 
> targetConfigId.  As a result, the current module's ID is always used as the 
> targetConfigId:
> context.findGBeans(new AbstractNameQuery(context.getId(), ...
> This means that the query will never match EJBs in a parent of the current 
> configuration.  It should be changed to use the targetConfigId instead of the 
> current module's ID.
> This does not come up if a pattern element is used in the mapping, though 
> that mapping strategy runs into a different 1.1 bug (ClassCastException on 
> org.openejb.proxy.ProxyInfo)

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

[jira] Resolved: (GERONIMO-2142) EJB Refs to EJB in parent module often fail

[Aaron Mulder (JIRA)]

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

Aaron Mulder resolved GERONIMO-2142.


Resolution: Fixed

Closing as resolved in 1.1.1.   Copied the issue for investigating the 
targetConfigId parameter.

> EJB Refs to EJB in parent module often fail
> ---
>
> Key: GERONIMO-2142
> URL: http://issues.apache.org/jira/browse/GERONIMO-2142
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB, deployment
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: David Jencks
> Fix For: 1.1.1
>
> Attachments: ejbref-itests.jar
>
>
> In OpenEJBReferenceBuilder:
> createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument.
> Then they often call getMatch or getImplicitMatch and don't use the 
> targetConfigId.  As a result, the current module's ID is always used as the 
> targetConfigId:
> context.findGBeans(new AbstractNameQuery(context.getId(), ...
> This means that the query will never match EJBs in a parent of the current 
> configuration.  It should be changed to use the targetConfigId instead of the 
> current module's ID.
> This does not come up if a pattern element is used in the mapping, though 
> that mapping strategy runs into a different 1.1 bug (ClassCastException on 
> org.openejb.proxy.ProxyInfo)

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

[jira] Updated: (GERONIMO-2238) Can't copy a MultiParentClassLoader

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2238:
---

Fix Version/s: 1.1.x
   (was: 1.1.1)

> Can't copy a MultiParentClassLoader
> ---
>
> Key: GERONIMO-2238
> URL: http://issues.apache.org/jira/browse/GERONIMO-2238
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
> Fix For: 1.1.x
>
>
> MultiParentClassLoader does not expose properties like inverseClassLoading 
> and hiddenClasses so you can't get all the properties you would need in order 
> to make a duplicate.

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

[jira] Updated: (GERONIMO-2280) FileKeystoreInstance.getKeyManager() fails when there is more than one privatekey in the store

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2280:
---

Fix Version/s: (was: 1.1.1)
   (was: 1.1.x)
Affects Version/s: (was: 1.1.1)

> FileKeystoreInstance.getKeyManager() fails when there is more than one 
> privatekey in the store
> --
>
> Key: GERONIMO-2280
> URL: http://issues.apache.org/jira/browse/GERONIMO-2280
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 1.1
>Reporter: Vamsavardhana Reddy
> Fix For: 1.2, 1.1.2
>
> Attachments: GERONIMO-2280.patch
>
>
> FileKeystoreInstance.getKeyManager() fails when there is more than one 
> privatekey in the store.
> Scenario 1:  The method will throw UnrecoverableKeyException if the all the 
> private key entries in the keystore do not have the same password (as the 
> entry of our interest).
> Scenario 2: Even if all the private key entries have the same password and 
> the method returns a KeyManager, there is no control on which enrty will be 
> used.
> To overcome this, a temporary keystore (I call it a SubKeystore) can be 
> generated and initialized with the entry corresponding to the alias and used 
> to init the KeyManagerFactory.

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

[jira] Updated: (GERONIMO-2279) FileKeyStoreInstance: Does not save keyPasswords after removing an entry

[Aaron Mulder (JIRA)]

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

Aaron Mulder updated GERONIMO-2279:
---

Fix Version/s: 1.1.2
   (was: 1.1.1)
   (was: 1.1.x)
Affects Version/s: 1.1
   (was: 1.1.1)

> FileKeyStoreInstance: Does not save keyPasswords after removing an entry
> 
>
> Key: GERONIMO-2279
> URL: http://issues.apache.org/jira/browse/GERONIMO-2279
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 1.1
>Reporter: Vamsavardhana Reddy
>Priority: Minor
> Fix For: 1.2, 1.1.2
>
> Attachments: GERONIMO-2279.patch
>
>
> keyPasswords are not saved after the password of deleted entry is removed 
> from the HashMap.

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

Re: Geronimo RTC Workflow Scheme v2

[Alan D. Cabrera]

Issues can be moved to new types, e.g. Wish -> Improvement, IIUC. 
Does RTC really cover documentation?  I thought that it was for
improvements and new features.


Regards,
Alan

Guillaume Nodet wrote:
I think that dblevins changed that, because in XBean, I
had a "Wish" for which i provided a patch but was unable
to put it in RTC mode.  RTC should also be applied to documentation, so
why were these issue types excluded
  
from the workflow ?
I think the main problem is that you can not easily recategorize issues
if they do not have the same workflow.
  
  On 8/7/06, Alan
D. Cabrera
   <[EMAIL PROTECTED]>
wrote:
  Previously,
this was set up so that only new features and improvements

followed the RTC flow.  Now, this new scheme includes all issue types.
Does anyone know why this was changed?


Regards,
Alan


  
  
  
  
  
-- 
Cheers,
Guillaume Nodet

Re: Maven2... we are almost there!

[anita kulshreshtha]

The conversion work was started on 04/Aug/05 by Jacek Laskowski. For an
 overview of how it progressed please see:

http://issues.apache.org/jira/browse/GERONIMO-851
http://issues.apache.org/jira/browse/GERONIMO-2071
http://issues.apache.org/jira/browse/GERONIMO-2219
   I hope this is helpful.

Thanks
Anita

--- Jason Dillon <[EMAIL PROTECTED]> wrote:

> I'm not sure how long that this effort has been going on before I  
> started actively working on it (for about 3 weeks or so I think).
> 
> --jason
> 
> 
> On Aug 6, 2006, at 3:58 PM, Jason van Zyl wrote:
> 
> > Hey,
> >
> > How long in total has it taken you to do the whole conversion?
> >
> > Jason.
> >
> > On 4 Aug 06, at 8:25 PM 4 Aug 06, Jason Dillon wrote:
> >
> >> I have finished merging svkmerge/m2migration to trunk.  Now it is 
> 
> >> time for everyone to start using the m2 build... and avoid using  
> >> the m1 build.
> >>

> > Jason van Zyl
> > [EMAIL PROTECTED]
> >
> >
> >
> 
> 


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

Re: Geronimo RTC Workflow Scheme v2

[Guillaume Nodet]

They can be moved, unless they do not have the same workflow afaik.On 8/7/06, Alan D. Cabrera <[EMAIL PROTECTED]
> wrote:


  
  


Issues can be moved to new types, e.g. Wish -> Improvement, IIUC. 
Does RTC really cover documentation?  I thought that it was for
improvements and new features.


Regards,
Alan

Guillaume Nodet wrote:
I think that dblevins changed that, because in XBean, I
had a "Wish" for which i provided a patch but was unable
to put it in RTC mode.  RTC should also be applied to documentation, so
why were these issue types excluded
  
from the workflow ?
I think the main problem is that you can not easily recategorize issues
if they do not have the same workflow.
  
  On 8/7/06, Alan
D. Cabrera
   <[EMAIL PROTECTED]>
wrote:
  Previously,
this was set up so that only new features and improvements

followed the RTC flow.  Now, this new scheme includes all issue types.
Does anyone know why this was changed?


Regards,
Alan


  
  
  
  
  
-- 
Cheers,
Guillaume Nodet





-- Cheers,Guillaume Nodet

[jira] Created: (SM-518) MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl exchange) check for null

[Jeremy (JIRA)]

MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl exchange) check for 
null
---

 Key: SM-518
 URL: https://issues.apache.org/activemq/browse/SM-518
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-core
Affects Versions: 3.0-M2
Reporter: Jeremy


Around line 260 in MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl 
exchange), need to check for a null after calling getContext when setting the 
Marshaller. In reference to thread: 
http://www.nabble.com/MessageExchangeFactoryImpl-NullPointerException-tf2064194.html

if (getContext() != null) {
PojoMarshaler marshaler = getContext().getActivationSpec().getMarshaler();
 if (marshaler != null) {
 exchange.setMarshaler(marshaler);
 }
} 

-- 
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: Maven2... we are almost there!

[Prasad Kashyap]

Platform : Windows XP

rm -rf  ~/.m2/repository
svn co trunk
m2 -Dstage=bootstrap

Build Error in geronimo/modules/activation
Reason: Unable to download the artifact from any repository
 org.apache.geronimo.specs:specs:pom:1.2-SNAPSHOT

Reason: in geronimo/pom.xml

 org.apache.geronimo.specs
 geronimo-javamail_1.3.1_spec
 1.2-SNAPSHOT


This version was 1.1 in m2migration branch.


Cheers
Prasad



On 8/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

I have finished merging svkmerge/m2migration to trunk.  Now it is
time for everyone to start using the m2 build... and avoid using the
m1 build.

I updated the docs here which explain what you must do:

 http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-
maven-2.html

You should bootstrap at least once.  This is temporary and will be
removed soon.

  * * *

Please, please, please start using the m2 build.  If for some reason
you end up going back to m1 please let us know so we can fix it.

The last major issue left unresolved (that I am ware of) is the car
plugins support for geronimo-plugin.xml fluff, which I am working on
resolving.

--jason

Re: Geronimo RTC Workflow Scheme v2

[Hernan Cunico]

Howdy, AFAIK documentation is not affected by RTC.

Cheers!
Hernan

Alan D. Cabrera wrote:
Issues can be moved to new types, e.g. Wish -> Improvement, IIUC.  Does 
RTC really cover documentation?  I thought that it was for improvements 
and new features.



Regards,
Alan

Guillaume Nodet wrote:
I think that dblevins changed that, because in XBean, I had a "Wish" 
for which i provided a patch but was unable
to put it in RTC mode.  RTC should also be applied to documentation, 
so why were these issue types excluded

from the workflow ?
I think the main problem is that you can not easily recategorize 
issues if they do not have the same workflow.


On 8/7/06, *Alan D. Cabrera * <[EMAIL PROTECTED] 
> wrote:


Previously, this was set up so that only new features and
improvements
followed the RTC flow.  Now, this new scheme includes all issue types.
Does anyone know why this was changed?


Regards,
Alan





--
Cheers,
Guillaume Nodet 

[jira] Resolved: (SM-518) MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl exchange) check for null

[Guillaume Nodet (JIRA)]

 [ https://issues.apache.org/activemq/browse/SM-518?page=all ]

Guillaume Nodet resolved SM-518.


Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Guillaume Nodet

Author: gnodet
Date: Mon Aug  7 09:00:48 2006
New Revision: 429375

URL: http://svn.apache.org/viewvc?rev=429375&view=rev
Log:
SM-518: MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl exchange) 
check for null 

Modified:

incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/messaging/MessageExchangeFactoryImpl.java



> MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl exchange) check 
> for null
> ---
>
> Key: SM-518
> URL: https://issues.apache.org/activemq/browse/SM-518
> Project: ServiceMix
>  Issue Type: Improvement
>  Components: servicemix-core
>Affects Versions: 3.0-M2
>Reporter: Jeremy
> Assigned To: Guillaume Nodet
> Fix For: 3.0-M3
>
>
> Around line 260 in MessageExchangeFactoryImpl.setDefaults(MessageExchangeImpl 
> exchange), need to check for a null after calling getContext when setting the 
> Marshaller. In reference to thread: 
> http://www.nabble.com/MessageExchangeFactoryImpl-NullPointerException-tf2064194.html
> if (getContext() != null) {
> PojoMarshaler marshaler = getContext().getActivationSpec().getMarshaler();
>  if (marshaler != null) {
>  exchange.setMarshaler(marshaler);
>  }
> } 

-- 
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] Commented: (SM-512) sendsync from a service to another service seems to cause a deadlock under load

[Guillaume Nodet (JIRA)]

[ 
https://issues.apache.org/activemq/browse/SM-512?page=comments#action_36698 ] 

Guillaume Nodet commented on SM-512:


I' ve been thinking about that a bit.
The main problem is that as soon as components use sendSync, this can lead to 
deadlocks, unless
you have an unbounded number of threads.

Let' s take the worst possible example.  We have a component that implements 
the factorial of an integer using
recursive sendSync.  The number of threads needed for this very component is 
unbounded.  Of course, I hope that
nobody will ever implement it that way.

So, in your case, you have a jms queue with thousands of pending messages, but 
I think this is the same problem.
The jms component will use its thread pool to process incoming jms messages.  
If you have more jms messages
than threads, each thread of the pool will be used to process one jms message.  
If the jms component use
sendSync, and if the exchange ever need to come back to the jms component, 
there will be a deadlock.

I really don't see any solutions here, other than using asynchonous send, or an 
unbounded thread pool.
The workaround is to use throttling, as defined in the jmx mbeans for the 
component.

We need a way to easily configure all these parameters (queue capacity for seda 
/ delivery channel, thread pool, throttling).




> sendsync from a service to another service seems to cause a deadlock under 
> load
> ---
>
> Key: SM-512
> URL: https://issues.apache.org/activemq/browse/SM-512
> Project: ServiceMix
>  Issue Type: Bug
>Affects Versions: 3.0-M2
> Environment: Windows 2003, Intel 2.8 xeon processor. Java 1.5 3.0-M2
>Reporter: anand somani
> Fix For: 3.0-M3
>
> Attachments: test.zip
>
>
> We have 2 services A and B. A makes sync requests to B. We have a JMS client 
> that feeds requests to A and that triggers a sync request to B. We are trying 
> to push some 5000 requests (not sequential). Now
>  With st flow - A gets all the responses from B and we are good
>  with Seda flow -  A gets some responses from B (sometimes none) and then 
> all the threads are blocked (seen using JMX) on syncsend(), looks like B has 
> no threads to service requests.
>  with JMS flow ( A and B on different VMs), we see the similar behavior 
> as with seda flow
> With async requests everything works just fine. We have tried increasing seda 
> capacity and workmanager thread count, that did not help.  I am attaching 
> service A and B code along with configuration files
> Also it would be nice to have all the tunable features documented with some 
> explaination somewhere ( I could not find it anywhere)

-- 
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: Maven2... we are almost there!

[anita kulshreshtha]

inline..

--- Aaron Mulder <[EMAIL PROTECTED]> wrote:

> On 8/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> > On Aug 6, 2006, at 2:21 PM, Aaron Mulder wrote:
> > > * OpenEJB downloads specs instead of using the ones build during
> the
> > > prior spec build phase
   
   This is because openejb uses different version of specs than
geronimo. I do not understand why this is so but it explains why
openejb downloads the specs. Here are the versions used by openejb rev
2835:

1.0 
  1.0-SNAPSHOT
1.1-SNAPSHOT

(Geronimo uses 1.0.1 for the following specs)
1.0   
   
1.0
 
1.0
1.0 
  
1.0
  
1.1-SNAPSHOT
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0

> >
> > The specs built from bootstrap are only for the JavaMail bits that
> > Rick added... and is again temporary until we get things published
> > regularly from CI.
> 
> So we have to build like 20 specs just to get JavaMail?  That's
> bizarre -- why don't we just check out JavaMail?
  
This is a good point. Only JavaMail spec uses a SNAPSHOT version,
hence this is the only one that could possibly get out of sync.

Thanks
Anita


> 
> > > * One of the applications (I think it said Demo, but I'm not sure
> > > which that is) downloaded Servlet and JSP specs that weren't from
> the
> > > Geronimo specs project at all
> >
> > Details Aaron please.  I can't possibly begin to do anything based
> on
> > this statement.
> 
> Really?  It was enough for me to grep my bootstrap.log:
> 
> [INFO] Building Geronimo Applications :: Demo
> [INFO]task-segment: [install]
> ...
> Downloading:
>
http://people.apache.org/repo/m2-ibiblio-rsync-repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.pom
> ...
> Downloading:
>
http://people.apache.org/repo/m2-ibiblio-rsync-repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.pom
> ...
> Downloading:
>
http://repo.mergere.com/maven2/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
> ...
> Downloading:
>
http://repo.mergere.com/maven2/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
> ...
> 
> > > * I swear I'm running everything under Java 1.4, and I did a
> whole
> > > new bootstrap build, and the OpenEJB compile worked, but the
> bootstrap
> > > ultimately failed with:
> > >
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >
>
--
> > > --
> > > [INFO] java.io.IOException: Unable to serialize GBeanData for
> > > org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/car?
> > >
> ServiceModule=org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/
> > > car,j2eeType=CORBABean,name=UnprotectedServer
> > >
> > > org/omg/CSI/EstablishContext
> >
> > I have not seen this.  Has anyone else?
> >
> >
> > > Maybe this isn't my fault?  Maybe someone push bad CORBA specs
> again?
> >
> > No sure... what platform?  Did you have a clean repo, or did you
> > circumvent the repo cleaning?
> 
> Clean repo.
> 
> Thanks,
>  Aaron
> 


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

Re: Remove server-environment from app client

[Dain Sundstrom]

On Aug 6, 2006, at 11:31 PM, David Jencks wrote:



On Aug 6, 2006, at 4:40 PM, Dain Sundstrom wrote:


On Aug 6, 2006, at 12:04 PM, David Jencks wrote:

How do we install the required yet idiotic jsr-77 gbean that  
represents the app client without a module to put it in?


Easy, just toss it into the parent ear configuration.


ok, but that won't work for a standalone app client.  For  
consistency I think we should generate a server side moduleId from  
the supplied client side moduleId e.g. by appending "_server" to  
the artifactId.


To start with, I am totally cool with the solution above, but I would  
like to point out this is exactly what we do for ejb and rar  
modules.  In those cases, we don't generate a module for the beans  
and just put the 77 services into the ear module.  When they are  
standalone we generate a standalone module.


Aaron pointed out the inconstancy between the handling of web and ejb  
modules when we were finishing the 1.1 work.  I still think it would  
be best to generate a module for each nested deployment, but I think  
it would be a lot of work.  Before we do this I think we need to  
introduce the concept of shared and private child modules.  Shared  
child modules would add their class path entries to the shared (e.g.,  
ear) class loader, and their services would become part of the shared  
(e.g., ear) service registry.  Private modules would operate like web  
modules do today meaning they have a private class loader and private  
service registry.


Anyway, it would be a lot of work, and I'm not planning on doing it :)

-dain 

Re: [Review] GERONIMO-2277 Remove TransactionContextManager

[Dain Sundstrom]

On Aug 7, 2006, at 12:09 AM, David Jencks wrote:

The notcm branch builds fine for me under m2 but the j2ee-jetty  
server does not start for me at the moment.  Apparently the  
TransactionManager doesn't start.  As noted in another post I don't  
get any log files which has so far inhibited me from investigating  
further.  Is this just my setup?


Don't know.  I'll take a look

-dain

[jira] Resolved: (SM-517) Re-structure the common/soap shared libraries

[Philip Dodds (JIRA)]

 [ https://issues.apache.org/activemq/browse/SM-517?page=all ]

Philip Dodds resolved SM-517.
-

Resolution: Fixed

Implemented new servicemix-shared library

> Re-structure the common/soap shared libraries
> -
>
> Key: SM-517
> URL: https://issues.apache.org/activemq/browse/SM-517
> Project: ServiceMix
>  Issue Type: Improvement
>  Components: servicemix-common, servicemix-soap
>Affects Versions: 3.0-M2
>Reporter: Philip Dodds
> Fix For: 3.0-M3
>
>
> Re-organize the common and soap libraries so they are normal jar packaging 
> and then create a new shared library called servicemix-shared that will have 
> both libraries embedded.  
> This removes the dependency that soap has on common being an issue when soap 
> is an SL.

-- 
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: Maven2... we are almost there!

[Jason Dillon]

Logging is busted.  I do not know how to fix it.  I think Dain might  
be taking a look...


--jason


On Aug 7, 2006, at 12:06 AM, David Jencks wrote:

I'm not seeing any log files in var/log when I start the m2 j2ee- 
jetty server is it just me?


thanks
david jencks


On Aug 4, 2006, at 5:25 PM, Jason Dillon wrote:

I have finished merging svkmerge/m2migration to trunk.  Now it is  
time for everyone to start using the m2 build... and avoid using  
the m1 build.


I updated the docs here which explain what you must do:

http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- 
maven-2.html


You should bootstrap at least once.  This is temporary and will be  
removed soon.


 * * *

Please, please, please start using the m2 build.  If for some  
reason you end up going back to m1 please let us know so we can  
fix it.


The last major issue left unresolved (that I am ware of) is the  
car plugins support for geronimo-plugin.xml fluff, which I am  
working on resolving.


--jason

Re: Maven2... we are almost there!

[Jason Dillon]

On Aug 7, 2006, at 7:48 AM, Aaron Mulder wrote:

Bootstrap is not meant to get everything up and running as quickly as
possible... it only exists as a temporary measure to help ensure that
the team can build and get predictable results while minimizing user
error.


Hmm.  But we only recommend running bootstrap once right?  Not every
time you build?

Are we planning to get rid of bootstrap relatively quickly or is that
always going to be part of the "first build" procedure?


I hope to do away with it soon.

It only needs to exist during the initial transition, once we have CI  
deploying SNAPSHOT artifacts for trunk, specs and OpenEJB2, then you  
can just use `build`... and once that maven bug is fixed you can just  
use `mvn`.


--jason

Branching 2.1.1

[Matt Hogstrom]

We've gotten through the initial TCK tests.  I am going to branch OEJB branches/v2_1 to 
branches/2.1.1 and remove the SNAPSHOT.  I will then build and update Geronimo.  One we have the 
final run I'll do a move to tags.  This is all being done at codehaus but I'm copying here as an FYI.


Thanks

Re: Maven2... we are almost there!

[Jason Dillon]

I just did a clean bootstrap on trunk and I do not see any spec  
related problems.


Have you run bootstrap since this was merged to trunk?

I have commented on this a few times... due to the JavaMail changes I  
added specs to bootstrap, to be checked out and run, since Rick's  
change was using these new versions and also since we have not  
published those snaps anywhere yet.


--jason


On Aug 7, 2006, at 8:59 AM, Prasad Kashyap wrote:


Platform : Windows XP

rm -rf  ~/.m2/repository
svn co trunk
m2 -Dstage=bootstrap

Build Error in geronimo/modules/activation
Reason: Unable to download the artifact from any repository
 org.apache.geronimo.specs:specs:pom:1.2-SNAPSHOT

Reason: in geronimo/pom.xml

 org.apache.geronimo.specs
 geronimo-javamail_1.3.1_spec
 1.2-SNAPSHOT


This version was 1.1 in m2migration branch.


Cheers
Prasad



On 8/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

I have finished merging svkmerge/m2migration to trunk.  Now it is
time for everyone to start using the m2 build... and avoid using the
m1 build.

I updated the docs here which explain what you must do:

 http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-
maven-2.html

You should bootstrap at least once.  This is temporary and will be
removed soon.

  * * *

Please, please, please start using the m2 build.  If for some reason
you end up going back to m1 please let us know so we can fix it.

The last major issue left unresolved (that I am ware of) is the car
plugins support for geronimo-plugin.xml fluff, which I am working on
resolving.

--jason

Re: Maven2... we are almost there!

[Jason Dillon]

Unfortunately it is not very easy to see how much actual time was  
spent working on this.


I certainly don't believe that it took a year to perform the migration.

--jason


On Aug 7, 2006, at 8:49 AM, anita kulshreshtha wrote:

The conversion work was started on 04/Aug/05 by Jacek Laskowski.  
For an

 overview of how it progressed please see:

http://issues.apache.org/jira/browse/GERONIMO-851
http://issues.apache.org/jira/browse/GERONIMO-2071
http://issues.apache.org/jira/browse/GERONIMO-2219
   I hope this is helpful.

Thanks
Anita

--- Jason Dillon <[EMAIL PROTECTED]> wrote:


I'm not sure how long that this effort has been going on before I
started actively working on it (for about 3 weeks or so I think).

--jason


On Aug 6, 2006, at 3:58 PM, Jason van Zyl wrote:


Hey,

How long in total has it taken you to do the whole conversion?

Jason.

On 4 Aug 06, at 8:25 PM 4 Aug 06, Jason Dillon wrote:


I have finished merging svkmerge/m2migration to trunk.  Now it is



time for everyone to start using the m2 build... and avoid using
the m1 build.




Jason van Zyl
[EMAIL PROTECTED]









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

Re: Maven2... we are almost there!

[Jason Dillon]

On Aug 7, 2006, at 4:59 AM, Aaron Mulder wrote:

On 8/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

On Aug 6, 2006, at 2:21 PM, Aaron Mulder wrote:
> * OpenEJB downloads specs instead of using the ones build during  
the

> prior spec build phase

The specs built from bootstrap are only for the JavaMail bits that
Rick added... and is again temporary until we get things published
regularly from CI.


So we have to build like 20 specs just to get JavaMail?  That's
bizarre -- why don't we just check out JavaMail?


Should not need to build any of the specs... or openejb2... but non  
of that is published anywhere, so for the very short-term we just  
build them here.




Really?  It was enough for me to grep my bootstrap.log:

[INFO] Building Geronimo Applications :: Demo
[INFO]task-segment: [install]
...
Downloading: http://people.apache.org/repo/m2-ibiblio-rsync- 
repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.pom

...
Downloading: http://people.apache.org/repo/m2-ibiblio-rsync- 
repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.pom

...
Downloading: http://repo.mergere.com/maven2/javax/servlet/jsp-api/ 
2.0/jsp-api-2.0.jar

...
Downloading: http://repo.mergere.com/maven2/javax/servlet/servlet- 
api/2.4/servlet-api-2.4.jar

...


This could be due to the jspc plugin, or the jasper-runtime.



> * I swear I'm running everything under Java 1.4, and I did a whole
> new bootstrap build, and the OpenEJB compile worked, but the  
bootstrap

> ultimately failed with:
>
> [ERROR] BUILD ERROR
> [INFO]
>  
- 
-

> --
> [INFO] java.io.IOException: Unable to serialize GBeanData for
> org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/car?
> ServiceModule=org.apache.geronimo.configs/j2ee-corba/1.2-SNAPSHOT/
> car,j2eeType=CORBABean,name=UnprotectedServer
>
> org/omg/CSI/EstablishContext

I have not seen this.  Has anyone else?


> Maybe this isn't my fault?  Maybe someone push bad CORBA specs  
again?


No sure... what platform?  Did you have a clean repo, or did you
circumvent the repo cleaning?


Clean repo.


Dunno... sounds like an environment problem.

--jason

[jira] Resolved: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)

[Jason Dillon (JIRA)]

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

Jason Dillon resolved GERONIMO-2281.


Resolution: Fixed

Applied.  There was actually a {{geronimo-j2ee-deployment}} listed below, but 
its artifactId had changed, so I fixed it.

Please verify :-)

> Deploy tool does not work (built from new m2 build)
> ---
>
> Key: GERONIMO-2281
> URL: http://issues.apache.org/jira/browse/GERONIMO-2281
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2
>Reporter: Bill Dudney
> Assigned To: Jason Dillon
> Attachments: 2281-online-deployer.patch
>
>
> A fresh build of geronimo from trunk (with m2) does not have a working 
> deployer.
> Tested only with the tomcat install but its likely a bug in all.
> To recreate;
> build with m2 (follow directions on wiki)
> install the g-tomcat-1.2-S.tar.gz 
> start the server with bin/startup.sh
> deploy something with bin/deploy.sh
> fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class
> patch adds to the manifest class path of deployer.jar

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

[jira] Commented: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)

[Bill Dudney (JIRA)]

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

Bill Dudney commented on GERONIMO-2281:
---

Verifyed fixed

Thanks Jason

> Deploy tool does not work (built from new m2 build)
> ---
>
> Key: GERONIMO-2281
> URL: http://issues.apache.org/jira/browse/GERONIMO-2281
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2
>Reporter: Bill Dudney
> Assigned To: Jason Dillon
> Attachments: 2281-online-deployer.patch
>
>
> A fresh build of geronimo from trunk (with m2) does not have a working 
> deployer.
> Tested only with the tomcat install but its likely a bug in all.
> To recreate;
> build with m2 (follow directions on wiki)
> install the g-tomcat-1.2-S.tar.gz 
> start the server with bin/startup.sh
> deploy something with bin/deploy.sh
> fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class
> patch adds to the manifest class path of deployer.jar

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

Drop the m1 build

[Dain Sundstrom]

I propose we remove the m1 build.  It has been broken for several  
days now and no one has noticed.  Here is my vote:


+1 to remove the m1 build

-dain

Re: Drop the m1 build

[Aaron Mulder]

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

I propose we remove the m1 build.  It has been broken for several
days now and no one has noticed.  Here is my vote:

+1 to remove the m1 build


I'm in favor of removing the M1 build from trunk.

Thanks,
Aaron

Re: Drop the m1 build

[Paul McMahan]

+1 to remove the m1 build

Paul

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

I propose we remove the m1 build.  It has been broken for several
days now and no one has noticed.  Here is my vote:

+1 to remove the m1 build

-dain

[jira] Updated: (GERONIMO-2131) "Installed Configuration" message written using System.out.println(..) instead of using the log

[Jason Dillon (JIRA)]

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

Jason Dillon updated GERONIMO-2131:
---

Description: 
I went to the http://jslap:8080/ page and clicked on the "Servlet Examples" and 
"LDAP Demo" and found that messages were written to system.out when I installed 
the configurations for those examples.  This information should be logged 
rather than printed to System.out.  See output below.

{noformat}
D:\reltest\geronimo-1.1>bin\geronimo.bat run
Using GERONIMO_BASE:   D:\reltest\geronimo-1.1
Using GERONIMO_HOME:   D:\reltest\geronimo-1.1
Using GERONIMO_TMPDIR: D:\reltest\geronimo-1.1\var\temp
Using JRE_HOME:C:\j2sdk1.4.2_10
Booting Geronimo Kernel (in Java 1.4.2_10)...
Starting Geronimo Application Server v1.1
[**] 100%  37s Startup complete
  Listening on Ports:
1099 0.0.0.0 RMI Naming
1527 0.0.0.0 Derby Connector
4201 0.0.0.0 ActiveIO Connector EJB
4242 0.0.0.0 Remote Login Listener
8009 0.0.0.0 Tomcat Connector AJP
8080 0.0.0.0 Tomcat Connector HTTP
8443 0.0.0.0 Tomcat Connector HTTPS
 0.0.0.0 JMX Remoting Connector
   61616 0.0.0.0 ActiveMQ Message Broker Connector

  Started Application Modules:
EAR: geronimo/webconsole-tomcat/1.1/car
RAR: geronimo/activemq/1.1/car
RAR: geronimo/system-database/1.1/car
WAR: geronimo/remote-deploy-tomcat/1.1/car
WAR: geronimo/welcome-tomcat/1.1/car

  Web Applications:
http://JSLAP:8080/
http://JSLAP:8080/console
http://JSLAP:8080/console-standard
http://JSLAP:8080/remote-deploy

Geronimo Application Server started

# Installed configuration
#   id = geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car
#   location = 
D:\reltest\geronimo-1.1\repository\geronimo\servlets-examples-tomcat\1.1-SNAPSHOT\servlets-examples-tomcat-1.1-SNAPSH
OT.car


# Installed configuration
#   id = geronimo/ldap-demo-tomcat/1.1-SNAPSHOT/car
#   location = 
D:\reltest\geronimo-1.1\repository\geronimo\ldap-demo-tomcat\1.1-SNAPSHOT\ldap-demo-tomcat-1.1-SNAPSHOT.car

{noformat}

  was:
I went to the http://jslap:8080/ page and clicked on the "Servlet Examples" and 
"LDAP Demo" and found that messages were written to system.out when I installed 
the configurations for those examples.  This information should be logged 
rather than printed to System.out.  See output below.

D:\reltest\geronimo-1.1>bin\geronimo.bat run
Using GERONIMO_BASE:   D:\reltest\geronimo-1.1
Using GERONIMO_HOME:   D:\reltest\geronimo-1.1
Using GERONIMO_TMPDIR: D:\reltest\geronimo-1.1\var\temp
Using JRE_HOME:C:\j2sdk1.4.2_10
Booting Geronimo Kernel (in Java 1.4.2_10)...
Starting Geronimo Application Server v1.1
[**] 100%  37s Startup complete
  Listening on Ports:
1099 0.0.0.0 RMI Naming
1527 0.0.0.0 Derby Connector
4201 0.0.0.0 ActiveIO Connector EJB
4242 0.0.0.0 Remote Login Listener
8009 0.0.0.0 Tomcat Connector AJP
8080 0.0.0.0 Tomcat Connector HTTP
8443 0.0.0.0 Tomcat Connector HTTPS
 0.0.0.0 JMX Remoting Connector
   61616 0.0.0.0 ActiveMQ Message Broker Connector

  Started Application Modules:
EAR: geronimo/webconsole-tomcat/1.1/car
RAR: geronimo/activemq/1.1/car
RAR: geronimo/system-database/1.1/car
WAR: geronimo/remote-deploy-tomcat/1.1/car
WAR: geronimo/welcome-tomcat/1.1/car

  Web Applications:
http://JSLAP:8080/
http://JSLAP:8080/console
http://JSLAP:8080/console-standard
http://JSLAP:8080/remote-deploy

Geronimo Application Server started

# Installed configuration
#   id = geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car
#   location = 
D:\reltest\geronimo-1.1\repository\geronimo\servlets-examples-tomcat\1.1-SNAPSHOT\servlets-examples-tomcat-1.1-SNAPSH
OT.car


# Installed configuration
#   id = geronimo/ldap-demo-tomcat/1.1-SNAPSHOT/car
#   location = 
D:\reltest\geronimo-1.1\repository\geronimo\ldap-demo-tomcat\1.1-SNAPSHOT\ldap-demo-tomcat-1.1-SNAPSHOT.car



> "Installed Configuration" message written using System.out.println(..) 
> instead of using the log
> ---
>
> Key: GERONIMO-2131
> URL: http://issues.apache.org/jira/browse/GERONIMO-2131
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 1.1
>Reporter: John Sisson
> Assigned To:

Re: Drop the m1 build

[Sachin Patel]

+1On Aug 7, 2006, at 3:41 PM, Dain Sundstrom wrote:ken for several days now and no one has noticed.  Here is my v  -sachin 

[jira] Closed: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)

[Jason Dillon (JIRA)]

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

Jason Dillon closed GERONIMO-2281.
--


> Deploy tool does not work (built from new m2 build)
> ---
>
> Key: GERONIMO-2281
> URL: http://issues.apache.org/jira/browse/GERONIMO-2281
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2
>Reporter: Bill Dudney
> Assigned To: Jason Dillon
> Attachments: 2281-online-deployer.patch
>
>
> A fresh build of geronimo from trunk (with m2) does not have a working 
> deployer.
> Tested only with the tomcat install but its likely a bug in all.
> To recreate;
> build with m2 (follow directions on wiki)
> install the g-tomcat-1.2-S.tar.gz 
> start the server with bin/startup.sh
> deploy something with bin/deploy.sh
> fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class
> patch adds to the manifest class path of deployer.jar

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

[jira] Closed: (GERONIMO-2131) "Installed Configuration" message written using System.out.println(..) instead of using the log

[Jason Dillon (JIRA)]

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

Jason Dillon closed GERONIMO-2131.
--

Resolution: Fixed

Done, this is now logged (minus the fancy text boxing)

> "Installed Configuration" message written using System.out.println(..) 
> instead of using the log
> ---
>
> Key: GERONIMO-2131
> URL: http://issues.apache.org/jira/browse/GERONIMO-2131
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 1.1
>Reporter: John Sisson
> Assigned To: Jason Dillon
>Priority: Trivial
> Fix For: 1.2
>
>
> I went to the http://jslap:8080/ page and clicked on the "Servlet Examples" 
> and "LDAP Demo" and found that messages were written to system.out when I 
> installed the configurations for those examples.  This information should be 
> logged rather than printed to System.out.  See output below.
> {noformat}
> D:\reltest\geronimo-1.1>bin\geronimo.bat run
> Using GERONIMO_BASE:   D:\reltest\geronimo-1.1
> Using GERONIMO_HOME:   D:\reltest\geronimo-1.1
> Using GERONIMO_TMPDIR: D:\reltest\geronimo-1.1\var\temp
> Using JRE_HOME:C:\j2sdk1.4.2_10
> Booting Geronimo Kernel (in Java 1.4.2_10)...
> Starting Geronimo Application Server v1.1
> [**] 100%  37s Startup complete
>   Listening on Ports:
> 1099 0.0.0.0 RMI Naming
> 1527 0.0.0.0 Derby Connector
> 4201 0.0.0.0 ActiveIO Connector EJB
> 4242 0.0.0.0 Remote Login Listener
> 8009 0.0.0.0 Tomcat Connector AJP
> 8080 0.0.0.0 Tomcat Connector HTTP
> 8443 0.0.0.0 Tomcat Connector HTTPS
>  0.0.0.0 JMX Remoting Connector
>61616 0.0.0.0 ActiveMQ Message Broker Connector
>   Started Application Modules:
> EAR: geronimo/webconsole-tomcat/1.1/car
> RAR: geronimo/activemq/1.1/car
> RAR: geronimo/system-database/1.1/car
> WAR: geronimo/remote-deploy-tomcat/1.1/car
> WAR: geronimo/welcome-tomcat/1.1/car
>   Web Applications:
> http://JSLAP:8080/
> http://JSLAP:8080/console
> http://JSLAP:8080/console-standard
> http://JSLAP:8080/remote-deploy
> Geronimo Application Server started
> 
> # Installed configuration
> #   id = geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car
> #   location = 
> D:\reltest\geronimo-1.1\repository\geronimo\servlets-examples-tomcat\1.1-SNAPSHOT\servlets-examples-tomcat-1.1-SNAPSH
> OT.car
> 
> 
> # Installed configuration
> #   id = geronimo/ldap-demo-tomcat/1.1-SNAPSHOT/car
> #   location = 
> D:\reltest\geronimo-1.1\repository\geronimo\ldap-demo-tomcat\1.1-SNAPSHOT\ldap-demo-tomcat-1.1-SNAPSHOT.car
> 
> {noformat}

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

Re: [jira] Commented: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)

[Jason Dillon]

Cool.  In the future, if you open an issue, and someone marks it as  
resolved, you should verify and close the issue, or reopen if it is  
still busted.


:-]

--jason


On Aug 7, 2006, at 12:35 PM, Bill Dudney (JIRA) wrote:

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


Bill Dudney commented on GERONIMO-2281:
---

Verifyed fixed

Thanks Jason


Deploy tool does not work (built from new m2 build)
---

Key: GERONIMO-2281
URL: http://issues.apache.org/jira/browse/ 
GERONIMO-2281

Project: Geronimo
 Issue Type: Bug
 Security Level: public(Regular issues)
 Components: deployment
   Affects Versions: 1.2
   Reporter: Bill Dudney
Assigned To: Jason Dillon
Attachments: 2281-online-deployer.patch


A fresh build of geronimo from trunk (with m2) does not have a  
working deployer.

Tested only with the tomcat install but its likely a bug in all.
To recreate;
build with m2 (follow directions on wiki)
install the g-tomcat-1.2-S.tar.gz
start the server with bin/startup.sh
deploy something with bin/deploy.sh
fails to find class javax/enterprise/deploy/spi/status/ 
ProgressListener.class

patch adds to the manifest class path of deployer.jar


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the  
administrators: http://issues.apache.org/jira/secure/ 
Administrators.jspa

-
For more information on JIRA, see: http://www.atlassian.com/ 
software/jira

Re: Drop the m1 build

[Jason Dillon]

+1

--jason


On Aug 7, 2006, at 12:41 PM, Dain Sundstrom wrote:

I propose we remove the m1 build.  It has been broken for several  
days now and no one has noticed.  Here is my vote:


+1 to remove the m1 build

-dain

[jira] Closed: (GERONIMO-1710) Geronimo timestamp plugin for Maven2

[Jason Dillon (JIRA)]

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

Jason Dillon closed GERONIMO-1710.
--

Resolution: Won't Fix

> Geronimo timestamp plugin for Maven2
> 
>
> Key: GERONIMO-1710
> URL: http://issues.apache.org/jira/browse/GERONIMO-1710
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
>Priority: Minor
>
> This is a contribution of Anders to create the geronimo-version.properties 
> file with timestamp information during Geronimo's build. It should eventually 
> end up as an Maven2 official plugin since there're not much reason to keep it 
> here.

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

[jira] Assigned: (GERONIMO-1722) Module migration to Maven 2: activemq-embedded-rar

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1722:
--

Assignee: Jason Dillon  (was: Andrew Steeley)

> Module migration to Maven 2: activemq-embedded-rar
> --
>
> Key: GERONIMO-1722
> URL: http://issues.apache.org/jira/browse/GERONIMO-1722
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
> Attachments: GERONIMO-1722.patch
>
>
> It's a task to help keep track of the progress of the module build migration 
> to Maven2

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

[jira] Assigned: (GERONIMO-1728) Module migration to Maven 2: installer-processing

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1728:
--

Assignee: Jason Dillon  (was: Prasad Kashyap)

> Module migration to Maven 2: installer-processing
> -
>
> Key: GERONIMO-1728
> URL: http://issues.apache.org/jira/browse/GERONIMO-1728
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
> Attachments: pom.xml
>
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

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

[jira] Assigned: (GERONIMO-1730) Module migration to Maven 2: interop

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1730:
--

Assignee: Jason Dillon  (was: Jacek Laskowski)

> Module migration to Maven 2: interop
> 
>
> Key: GERONIMO-1730
> URL: http://issues.apache.org/jira/browse/GERONIMO-1730
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

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

[jira] Assigned: (GERONIMO-1727) Module migration to Maven2: connector

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1727:
--

Assignee: Jason Dillon

> Module migration to Maven2: connector
> -
>
> Key: GERONIMO-1727
> URL: http://issues.apache.org/jira/browse/GERONIMO-1727
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

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

[jira] Assigned: (GERONIMO-1729) Module migration to Maven 2: installer-support

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1729:
--

Assignee: Jason Dillon  (was: Prasad Kashyap)

> Module migration to Maven 2: installer-support
> --
>
> Key: GERONIMO-1729
> URL: http://issues.apache.org/jira/browse/GERONIMO-1729
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
> Attachments: pom.xml, setup.xml
>
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

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

[jira] Assigned: (GERONIMO-1739) Plugin migration to Maven 2: geronimo-izpack-plugin

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1739:
--

Assignee: Jason Dillon

> Plugin migration to Maven 2: geronimo-izpack-plugin
> ---
>
> Key: GERONIMO-1739
> URL: http://issues.apache.org/jira/browse/GERONIMO-1739
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
>
> It's a task to keep track of the progress of the plugin build migration to 
> Maven2

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

[jira] Assigned: (GERONIMO-1736) Module migration to Maven 2: web-builder

[Jason Dillon (JIRA)]

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

Jason Dillon reassigned GERONIMO-1736:
--

Assignee: Jason Dillon

> Module migration to Maven 2: web-builder
> 
>
> Key: GERONIMO-1736
> URL: http://issues.apache.org/jira/browse/GERONIMO-1736
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 1.x
>Reporter: Jacek Laskowski
> Assigned To: Jason Dillon
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

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

Re: Branching 2.1.1

[Kevan Miller]

+1
On Aug 7, 2006, at 1:28 PM, Matt Hogstrom wrote:

We've gotten through the initial TCK tests.  I am going to branch  
OEJB branches/v2_1 to branches/2.1.1 and remove the SNAPSHOT.  I  
will then build and update Geronimo.  One we have the final run  
I'll do a move to tags.  This is all being done at codehaus but I'm  
copying here as an FYI.


Thanks

Re: Drop the m1 build

[David Jencks]

+1

david jencks

On Aug 7, 2006, at 12:41 PM, Dain Sundstrom wrote:

I propose we remove the m1 build.  It has been broken for several  
days now and no one has noticed.  Here is my vote:


+1 to remove the m1 build

-dain

Re: Geronimo RTC Workflow Scheme v2

[David Blevins]

I didn't figure there wasn't any harm in allowing the RTC system to  
be used for more than what is currently required by PMC mandate.  I  
mean if someone really wants to have their work reviewed, more power  
to them.


We can change it back if you prefer.

-David

On Aug 7, 2006, at 8:24 AM, Guillaume Nodet wrote:

I think that dblevins changed that, because in XBean, I had a  
"Wish" for which i provided a patch but was unable
to put it in RTC mode.  RTC should also be applied to  
documentation, so why were these issue types excluded

from the workflow ?
I think the main problem is that you can not easily recategorize  
issues if they do not have the same workflow.


On 8/7/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:Previously,  
this was set up so that only new features and improvements

followed the RTC flow.  Now, this new scheme includes all issue types.
Does anyone know why this was changed?


Regards,
Alan





--
Cheers,
Guillaume Nodet

Re: Drop the m1 build

[David Blevins]

+1

-David

On Aug 7, 2006, at 12:41 PM, Dain Sundstrom wrote:

I propose we remove the m1 build.  It has been broken for several  
days now and no one has noticed.  Here is my vote:


+1 to remove the m1 build

-dain

Re: BAm Component - Data configuration

[soumadeep sen]

Awesome idea... let me get this working.

Soumadeep


On 8/7/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:


I really think that XBean is the most flexible option, as it allow easy
extension (using spring syntax), validation using the xml schemas and it
would be more homegeneous with the remaining of ServiceMix.

For actions, you could define these properties on the BAMEndpoint:
private Action[] actions;
private Resource actionsResource;
with the appropriate getters / setters, where
  Action is an interface defined by the BAM component, and Resource is a
spring resource (org.springframework.core.io.Resouce).

Let's you have an Action implementation with the MyAction class, if you
annotate the javadoc with the @org.apache.xbean.XBean annotation, you
would
have:


   
 
   


The actionsResource would be used if you want to split the actions
definition in another file.
  
Where the file would contain something like:

   


This would allow to easily extend the set of actions, either by adding a
predefined action in the
component, but also by embedding the class in the SU and use standard
spring
syntax:

   
 
   



On 8/7/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:
>
> Hi Guillaume/All
>
> We are almost there with the BAMComponent, as discussed in the earlier
> emails, we have used the maven archetype (which was uploaded by SM guys)
for
> developing the JBI component.
>
> The next step is to figure out a proper way of feeding configuration
> related data for the BAMComponent. As pointed out earlier the component
in
> question would require data for KPI-Key performance indicator (currently
> xpath based), Actions and global configurations.
>
> My idea was to use XMLBeans based on xsds for the same but am thinking
> otherwise as it would introduce some maintenance going forward. The
other
> option is to use properties file but then again it would pose a
challenge
> when the elements get nested, it will become too convoluted to handle.
So
> the question is still open -> what to use or what could be an elegant
> solution for this.
>
> Thanks
> Soumadeep
>
>
>
>
>


--
Cheers,
Guillaume Nodet

Re: Maven2... we are almost there!

[Prasad Kashyap]

M2 and bootstrap works smoothly. Please disregard the specs problem
reported earlier. But hopefully soon we can eliminate the bootstrap
script.

Other very minor issues -
We should also regenerate the site again.
http://geronimo.apache.org/maven/source-repository.html is out of date.

Can't navigate back from links like the one below -
http://geronimo.apache.org/maven/modules/geronimo-axis/project-info.html

Cheers
Prasad

On 8/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

I just did a clean bootstrap on trunk and I do not see any spec
related problems.

Have you run bootstrap since this was merged to trunk?

I have commented on this a few times... due to the JavaMail changes I
added specs to bootstrap, to be checked out and run, since Rick's
change was using these new versions and also since we have not
published those snaps anywhere yet.

--jason


On Aug 7, 2006, at 8:59 AM, Prasad Kashyap wrote:

> Platform : Windows XP
>
> rm -rf  ~/.m2/repository
> svn co trunk
> m2 -Dstage=bootstrap
>
> Build Error in geronimo/modules/activation
> Reason: Unable to download the artifact from any repository
>  org.apache.geronimo.specs:specs:pom:1.2-SNAPSHOT
>
> Reason: in geronimo/pom.xml
> 
>  org.apache.geronimo.specs
>  geronimo-javamail_1.3.1_spec
>  1.2-SNAPSHOT
> 
>
> This version was 1.1 in m2migration branch.
>
>
> Cheers
> Prasad
>
>
>
> On 8/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
>> I have finished merging svkmerge/m2migration to trunk.  Now it is
>> time for everyone to start using the m2 build... and avoid using the
>> m1 build.
>>
>> I updated the docs here which explain what you must do:
>>
>>  http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-
>> maven-2.html
>>
>> You should bootstrap at least once.  This is temporary and will be
>> removed soon.
>>
>>   * * *
>>
>> Please, please, please start using the m2 build.  If for some reason
>> you end up going back to m1 please let us know so we can fix it.
>>
>> The last major issue left unresolved (that I am ware of) is the car
>> plugins support for geronimo-plugin.xml fluff, which I am working on
>> resolving.
>>
>> --jason
>>

Re: Drop the m1 build

[Prasad Kashyap]

+1

Cheers
Prasad

On 8/7/06, David Blevins <[EMAIL PROTECTED]> wrote:

+1

-David

On Aug 7, 2006, at 12:41 PM, Dain Sundstrom wrote:

> I propose we remove the m1 build.  It has been broken for several
> days now and no one has noticed.  Here is my vote:
>
> +1 to remove the m1 build
>
> -dain
>