[jira] Commented: (GERONIMO-3317) "has not been enhanced" error when invoking an EJB 2.1 Entity Bean

[YunFeng Ma (JIRA)]

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

YunFeng Ma commented on GERONIMO-3317:
--

I retested my sample using latest geronimo and the "has not been enhanced" 
error had gone, but get a new error:

13:33:22,859 ERROR [OpenEJB] The bean instances business method encountered a sy
stem exception: org.apache.openejb.core.cmp.cmp2.Cmp2Entity
java.lang.NoClassDefFoundError: org.apache.openejb.core.cmp.cmp2.Cmp2Entity
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:223)
at java.lang.ClassLoader.defineClass(ClassLoader.java:162)
at serp.bytecode.BCClassLoader.findClass(BCClassLoader.java:73)
at java.lang.ClassLoader.loadClass(ClassLoader.java:602)
at java.lang.ClassLoader.loadClass(ClassLoader.java:568)
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:223)
at java.lang.ClassLoader.defineClass(ClassLoader.java:162)
at serp.bytecode.BCClassLoader.findClass(BCClassLoader.java:73)
at java.lang.ClassLoader.loadClass(ClassLoader.java:602)
at java.lang.ClassLoader.loadClass(ClassLoader.java:568)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:160)
at 
org.apache.openjpa.util.GeneratedClasses.loadBCClass(GeneratedClasses.java:68)
at 
org.apache.openjpa.enhance.ManagedClassSubclasser.write(ManagedClassSubclasser.java:193)
at 
org.apache.openjpa.enhance.ManagedClassSubclasser.access$000(ManagedClassSubclasser.java:48)
at 
org.apache.openjpa.enhance.ManagedClassSubclasser$1.write(ManagedClassSubclasser.java:96)
at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:522)
at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:510)
at 
org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(AbstractBrokerFactory.java:286)
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:196)
at 
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:190)
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:55)
at 
org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createEntityManager(CMPEntityManagerTxScoped.java:74)
at 
org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getEntityManager(CMPEntityManagerTxScoped.java:55)
at 
org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getDelegate(CMPEntityManagerTxScoped.java:315)
at 
org.apache.openejb.core.cmp.jpa.JpaCmpEngine.registerListener(JpaCmpEngine.java:128)
at 
org.apache.openejb.core.cmp.jpa.JpaCmpEngine.getEntityManager(JpaCmpEngine.java:109)
at 
org.apache.openejb.core.cmp.jpa.JpaCmpEngine.loadBean(JpaCmpEngine.java:170)
at 
org.apache.openejb.core.cmp.CmpContainer.findByPrimaryKey(CmpContainer.java:687)
at 
org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:284)
at 
org.apache.openejb.core.entity.EntityEjbHomeHandler.findX(EntityEjbHomeHandler.java:57)
at 
org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:160)
at 
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:229)
at 
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
at $Proxy35.findByPrimaryKey(Unknown Source)
at javaUtility.EjbUtility.getUser(EjbUtility.java:105)
at servlets.WelcomeServlet.doPost(WelcomeServlet.java:71)
at servlets.GVTServlet.service(GVTServlet.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.val

Re: State of branches 2.0.0

[Jason Dillon]

I think I missed some discussion or something... but what is the  
difference between these 2 branches:


server/branches/2.0
server/branches/2.0.0

?

--jason


On Aug 5, 2007, at 7:48 PM, Matt Hogstrom wrote:

I updated the version number to 2.0 from 2.0-SNAPSHOT.   These  
artifacts should not be deployed as they have the official 2.0  
version number.


Also, updated the versions of many released artifacts to they're  
appropriate released version numbers.


We should be about ready to build and start TCK.

Re: Changes to server started messages

[Jason Dillon]

I think it makes more sense w/o the full url bits, since those are  
highly dependent on how you configured the connectors.


--jason


On Aug 2, 2007, at 6:25 PM, Jeff Genender wrote:


Yup...

The old messages made no sense at all...because Web application !=
connector and therefore its not fair to determine that the web
applications actually listen on http.  In long discussions with David
Jencks, we agreed the slapping of http in from of the URL was purely a
hack and was not correct for complex cases...i.e. the applications you
listed also are running on https *and* ajp.  In otherwords, the web
application is independent of the scheme (http) and it shouldn't know
its own scheme.

It *is* correct for the web application to know it's identified by the
context, and thats why you see them listed.

I hope this made sense.

Jeff


Kevan Miller wrote:
I noticed that the server started messages have changed. The  
started Web

Applications are now of the following form:

  Web Applications:
/
/console
/console-standard
/dojo
/remote-deploy

Geronimo Application Server started

Where they used to be:

  Web Applications:
http://coltrane:8080/
http://coltrane:8080/console
http://coltrane:8080/console-standard
http://coltrane:8080/dojo
http://coltrane:8080/remote-deploy

Geronimo Application Server started

I'm assuming that this is associated with the recent Connector
changes... I preferred the old messages, but I doubt I'll lose  
very much

sleep... Apologies if I missed discussion about this. Even more
apologies if the network config on my machine has gone bonkers... ;-)

--kevan

[jira] Commented: (GERONIMO-2401) Upgrade commons-logging to 1.1

[Jason Dillon (JIRA)]

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

Jason Dillon commented on GERONIMO-2401:


I really think that we should really think about using slf4j instead of 
commons-logging... and perhaps even change our logging instance strategy a 
little.

Right now we have static loggers per class (for most things), and what I am 
starting to think is that instance loggers are better, so that logging for 
multiple instances of bits that are bound under different contexts can be 
effectively controlled and managed better.

For example, we might want all logs for a particular application to end up in a 
specific file, but none of the other bits from other apps.  This isn't very 
easy to do right now with the static loggers, though it can be done.  I suggest 
we re-think this and other logging aspects for 2.1 and make that release one 
with really solid, flexible and reliable logging, which IMO is one of the most 
important facilities which an application server can provide.  Logging is 
helpful for development, qa, staging and production, it impacts every aspect of 
the life-cycle of an app deployed in an application server... and IMO we really 
need to do a *much better* job in the logging scene. 

> Upgrade commons-logging to 1.1
> --
>
> Key: GERONIMO-2401
> URL: https://issues.apache.org/jira/browse/GERONIMO-2401
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: dependencies, Logging
>Affects Versions: 1.2, 2.0-M5
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 2.1
>
>
> Upgrade commons-logging to the latest release 1.1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component

[Freeman Fang (JIRA)]

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

Freeman Fang updated SM-939:


Attachment: patch0806.txt

> CXF based Service Engine and Bnding Component
> -
>
> Key: SM-939
> URL: https://issues.apache.org/activemq/browse/SM-939
> Project: ServiceMix
>  Issue Type: New Feature
>Reporter: Guillaume Nodet
>Assignee: Freeman Fang
>Priority: Critical
> Fix For: 3.2
>
> Attachments: patch.txt, patch0627.txt, patch0702.txt, patch0720.txt, 
> patch0806.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-1761) Change geronimo-util module to geronimo-crypto, give credit where credit is due

[Jason Dillon (JIRA)]

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

Jason Dillon commented on GERONIMO-1761:


Um, why not just {{geronmo-crypto}}, it may contain some wrapper bits, but also 
some handy utils and other much related to cryptographic mumbo jumbo.

Lets just rename the beast...

> Change geronimo-util module to geronimo-crypto, give credit where credit is 
> due
> ---
>
> Key: GERONIMO-1761
> URL: https://issues.apache.org/jira/browse/GERONIMO-1761
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core
>Affects Versions: 1.0
>Reporter: Aaron Mulder
>Assignee: Jason Dillon
> Fix For: 2.1
>
>
> The util module holds a bunch of crypto-related stuff.  Speculation is that 
> it's the non-encumbered code from bouncycastle.  It should be in a more 
> accurately named module and package, since it's not just generic "util" code. 
>  It would also be nice to put a note in every file header saying where it's 
> from, or at least in NOTICE.txt perhaps.  There may be improvements we want 
> to track?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Splitting up the server into a few more chunks

[Jason Dillon]

Hiya, I've mentioned this before... and now that we have a 2.0 branch  
and trunk has moved on to 2.1 work, I think its time we really make a  
decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the  
server/trunk tree just in better locations organized by functionality  
and feature not by artifact type.  But, now I'm thinking we should  
really do one step more than that, and split up the server/trunk  
project into several smaller and more manageable chunks of modules.   
I still think that the basic grouping that we kinda talked about  
before should work fine, but instead of having them share a project  
namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder

And then we can group some of the related components up into shared  
projects, or just go out and give each component its own project, and/ 
or think about maybe using the same style that the maven/plugins/ 
trunk tree uses, a shared project, but each component is related  
individually... still not sure I like that, kinda messy.


I don't want to end up with a ton of projects either, and I certainly  
don't want to get up using SNAPSHOT versions of these puppies if we  
can help it.  So, maybe to start out we could do these:


server-support
server-framework
server-components
server-assembly

BTW, I'm using "dash" here so that the names don't collide with what  
is there now, but really we could user server/support/trunk, server/ 
framework/trunk, etc (which is better IMO for the longer run).


And in the process of making this split up, we can re-arrange modules  
by feature and function instead of by type... and actually we have to  
do that to make the components bits work.


 * * *

I really believe this will help improve the support and  
maintainability of the server's code-base and it will help the  
project scale better as new components are added too.  For developers  
that are only interested in working on a specific component, it  
reduces the amount of other sources they need to check out and  
reduces the time to build too, so that they can build a clean server  
assembly faster and developer their features sooner and hopefully  
have less hair-pulling and more relaxed beer drinking as they pat  
themselves on the back for doing such a speedy job.


I really, really... really, really, really ( :-P ) think that we  
*must* move along these lines for the longer term health of the  
project...


Comments?  Suggestions?

--jason

Re: State of branches 2.0.0

[Vamsavardhana Reddy]

2.0 release will be based on branches/2.0.0 (and I guess, will be tagged
tags\2.0 later on).  branches\2.0 is now 2.0.1-SNAPSHOT.

--vamsi

On 8/6/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
>
> I think I missed some discussion or something... but what is the
> difference between these 2 branches:
>
>  server/branches/2.0
>  server/branches/2.0.0
>
> ?
>
> --jason
>
>
> On Aug 5, 2007, at 7:48 PM, Matt Hogstrom wrote:
>
> > I updated the version number to 2.0 from 2.0-SNAPSHOT.   These
> > artifacts should not be deployed as they have the official 2.0
> > version number.
> >
> > Also, updated the versions of many released artifacts to they're
> > appropriate released version numbers.
> >
> > We should be about ready to build and start TCK.
>
>

[jira] Commented: (SM-939) CXF based Service Engine and Bnding Component

[Guillaume Nodet (JIRA)]

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

Guillaume Nodet commented on SM-939:


New patch applied.

> CXF based Service Engine and Bnding Component
> -
>
> Key: SM-939
> URL: https://issues.apache.org/activemq/browse/SM-939
> Project: ServiceMix
>  Issue Type: New Feature
>Reporter: Guillaume Nodet
>Assignee: Freeman Fang
>Priority: Critical
> Fix For: 3.2
>
> Attachments: patch.txt, patch0627.txt, patch0702.txt, patch0720.txt, 
> patch0806.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: State of branches 2.0.0

[Jason Dillon]

Aighty... still seems weird, but okay :-)

--jason


On Aug 6, 2007, at 2:04 AM, Vamsavardhana Reddy wrote:

2.0 release will be based on branches/2.0.0 (and I guess, will be  
tagged tags\2.0 later on).  branches\2.0 is now 2.0.1-SNAPSHOT.


--vamsi

On 8/6/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
I think I missed some discussion or something... but what is the
difference between these 2 branches:

 server/branches/2.0
 server/branches/2.0.0

?

--jason


On Aug 5, 2007, at 7:48 PM, Matt Hogstrom wrote:

> I updated the version number to 2.0 from 2.0-SNAPSHOT.   These
> artifacts should not be deployed as they have the official 2.0
> version number.
>
> Also, updated the versions of many released artifacts to they're
> appropriate released version numbers.
>
> We should be about ready to build and start TCK.

Re: 2.0-M4 is still under branches

[Vamsavardhana Reddy]

I guess branches\2.0-M4 can be deleted now.

--vamsi


On 5/8/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>
> I concur...if there are no objections by the end of the week I'll
> delete it.
>
>
> On May 3, 2007, at 2:41 AM, Jason Dillon wrote:
>
> > m4 never got cooked fully, which is why the branch is still there.
> > it was decided to just move on to m5 due to problems with the m4
> > branch.  The branch should probably be removed.
> >
> > --jason
> >
> >
> > On May 3, 2007, at 2:35 AM, Vamsavardhana Reddy wrote:
> >
> >> This may not be a big or important (??) thing...  G 2.0-M4 is still
> >> under branches.
> >> https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M4/ .
> >> We should tag the release as we have done for other milestone
> >> releases.
> >>
> >> Vamsi
> >
> >
>
>

Re: 2.0-M4 is still under branches

[Vamsavardhana Reddy]

Removed in Revision: 563088

--vamsi

On 5/8/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>
> I concur...if there are no objections by the end of the week I'll
> delete it.
>
>
> On May 3, 2007, at 2:41 AM, Jason Dillon wrote:
>
> > m4 never got cooked fully, which is why the branch is still there.
> > it was decided to just move on to m5 due to problems with the m4
> > branch.  The branch should probably be removed.
> >
> > --jason
> >
> >
> > On May 3, 2007, at 2:35 AM, Vamsavardhana Reddy wrote:
> >
> >> This may not be a big or important (??) thing...  G 2.0-M4 is still
> >> under branches.
> >> https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M4/ .
> >> We should tag the release as we have done for other milestone
> >> releases.
> >>
> >> Vamsi
> >
> >
>
>

Re: 2.0-M4 is still under branches

[Jason Dillon]

Yay, doesn't cleaning up feel good, all nice and shinny :-P

--jason


On Aug 6, 2007, at 3:15 AM, Vamsavardhana Reddy wrote:


Removed in Revision: 563088

--vamsi

On 5/8/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
I concur...if there are no objections by the end of the week I'll
delete it.


On May 3, 2007, at 2:41 AM, Jason Dillon wrote:

> m4 never got cooked fully, which is why the branch is still there.
> it was decided to just move on to m5 due to problems with the m4
> branch.  The branch should probably be removed.
>
> --jason
>
>
> On May 3, 2007, at 2:35 AM, Vamsavardhana Reddy wrote:
>
>> This may not be a big or important (??) thing...  G 2.0-M4 is still
>> under branches.
>> https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M4/ .
>> We should tag the release as we have done for other milestone
>> releases.
>>
>> Vamsi
>
>

Re: State of branches 2.0.0

[Matt Hogstrom]

Branches 2.0 is now 2.0.1-SNAPSHOT.


2.0.0 is the release branch  and is considered stable if there is  
such a thing.  The final bits and moving of stuff to prepare for a  
release makes it easier to have it separate.


On Aug 6, 2007, at 4:22 AM, Jason Dillon wrote:

I think I missed some discussion or something... but what is the  
difference between these 2 branches:


server/branches/2.0
server/branches/2.0.0

?

--jason


On Aug 5, 2007, at 7:48 PM, Matt Hogstrom wrote:

I updated the version number to 2.0 from 2.0-SNAPSHOT.   These  
artifacts should not be deployed as they have the official 2.0  
version number.


Also, updated the versions of many released artifacts to they're  
appropriate released version numbers.


We should be about ready to build and start TCK.

Re: Changes to server started messages

[Kevan Miller]

On Aug 6, 2007, at 4:24 AM, Jason Dillon wrote:

I think it makes more sense w/o the full url bits, since those are  
highly dependent on how you configured the connectors.


Ya. I understood that when I asked. And don't necessarily disagree  
with where we end up. We might consider tweaking the startup message  
a bit. Two points:


1) Discuss/document the decision on [EMAIL PROTECTED] If it was discussed/ 
documented on dev@, then my apologies...
2) Note that http:// works just perfectly for umpity  
percent of users.


So, we've sacrificed some usability for some accuracy. We're accurate  
for more complex cases where users know how to change our default  
connectors (most of whom would understand the relativity of the app  
contexts, anyway). And we're less usable for naive users (e.g. ones  
who just downloaded Geronimo for the first time).


--kevan

Re: 2.0-M4 is still under branches

[Vamsavardhana Reddy]

Yes, it does :o)

Vamsi

On 8/6/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
>
> Yay, doesn't cleaning up feel good, all nice and shinny :-P
> --jason
>
>
> On Aug 6, 2007, at 3:15 AM, Vamsavardhana Reddy wrote:
>
> Removed in Revision: 563088
>
> --vamsi
>
> On 5/8/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> >
> > I concur...if there are no objections by the end of the week I'll
> > delete it.
> >
> >
> > On May 3, 2007, at 2:41 AM, Jason Dillon wrote:
> >
> > > m4 never got cooked fully, which is why the branch is still there.
> > > it was decided to just move on to m5 due to problems with the m4
> > > branch.  The branch should probably be removed.
> > >
> > > --jason
> > >
> > >
> > > On May 3, 2007, at 2:35 AM, Vamsavardhana Reddy wrote:
> > >
> > >> This may not be a big or important (??) thing...  G 2.0-M4 is still
> > >> under branches.
> > >> https://svn.apache.org/repos/asf/geronimo/server/branches/2.0-M4/ .
> > >> We should tag the release as we have done for other milestone
> > >> releases.
> > >>
> > >> Vamsi
> > >
> > >
> >
> >
>
>

Re: Changes to server started messages

[Vamsavardhana Reddy]

I guess the startup screen need not list all possible URLs to access each
application.  One per app should be good enough for the user to quick
start.  "Easy to use" is our first guiding principle.  We will not want a
user to struggle finding out the URL of welcome app!!!

Vamsi

On 8/6/07, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
>
> On Aug 6, 2007, at 4:24 AM, Jason Dillon wrote:
>
> > I think it makes more sense w/o the full url bits, since those are
> > highly dependent on how you configured the connectors.
>
> Ya. I understood that when I asked. And don't necessarily disagree
> with where we end up. We might consider tweaking the startup message
> a bit. Two points:
>
> 1) Discuss/document the decision on [EMAIL PROTECTED] If it was discussed/
> documented on dev@, then my apologies...
> 2) Note that http:// works just perfectly for umpity
> percent of users.
>
> So, we've sacrificed some usability for some accuracy. We're accurate
> for more complex cases where users know how to change our default
> connectors (most of whom would understand the relativity of the app
> contexts, anyway). And we're less usable for naive users (e.g. ones
> who just downloaded Geronimo for the first time).
>
> --kevan
>

Re: svn commit: r562816 - /geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java

[Lin Sun]

Yes I made a comment in the JIRA 3378- I was not able to build 
branches/2.0 on Sat. nite.  I'll try build it today.


Lin

Donald Woods wrote:

Are you going to include this in branches/2.0 for a 2.0.1 release?

-Donald

[EMAIL PROTECTED] wrote:

Author: linsun
Date: Sat Aug  4 21:03:38 2007
New Revision: 562816

URL: http://svn.apache.org/viewvc?view=rev&rev=562816
Log:
oops missed two spots on formatting

Modified:

geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java 



Modified: 
geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java 

URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java?view=diff&rev=562816&r1=562815&r2=562816 

== 

--- 
geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java 
(original)
+++ 
geronimo/server/trunk/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/factories/BaseDeploymentFactory.java 
Sat Aug  4 21:03:38 2007

@@ -70,8 +70,9 @@
 
 private ConnectParams parseURI(String uri) {

 uri = uri.trim();
-if (log.isDebugEnabled())
+if (log.isDebugEnabled()) {
 log.debug("Parsing URI=" + uri);
+}
 if(!uri.startsWith(URI_PREFIX)) {
 return null;
 }
@@ -127,8 +128,9 @@
 if (params == null) {
 return null;
 }
-if (log.isDebugEnabled())
+if (log.isDebugEnabled()) {
 log.debug("Using protocol=" + params.getProtocol() + ", 
host=" + params.getHost() + ", port=" + params.getPort());

+}
 
 try {

 if (params.getProtocol().equals("jmx")) {

[jira] Commented: (GERONIMO-3340) Take apache directory plugin out of the main build, put it in plugins.

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-3340:
---

Do we need the directory related code in branches\2.0.0?  We may actually get 
rid of the commented out lines in pom.xml and remove directories under modules 
and configs in branches\2.0.0.

> Take apache directory plugin out of the main build, put it in plugins.
> --
>
> Key: GERONIMO-3340
> URL: https://issues.apache.org/jira/browse/GERONIMO-3340
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 2.0-M6
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1
>
>
> I'm not sure updating the directory plugin to 1.0 or 1.5 will happen before 
> 2.0 is cut and shipping the current version is pretty useless.  This way we 
> can decouple the releases a bit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Cleanup of directory server code in branches\2.0 and branches\2.0.0

[Vamsavardhana Reddy]

As part of "GERONIMO-3340 Take apache directory plugin out of the main
build, put it in plugins.", the directory server code has been disabled from
the main build in rev 558213 (prior to creating branches\2.0), by commenting
out the entries in pom.xml, but the code has been left in the trunk as it
has not been moved to plugins.  Now that the code is in trunk, the copy of
this unused code is not required in branches\2.0 and branches\2.0.0.  I
thought I would cleanup this code from the branches.  I checked with Matt
and he is ok with it.  But, he asked me to check on the dev-list.  If there
are no objections, I propose to knock this unused code from branches (from
branches\2.0.0 only if an RC has not been spun already).  Here is an excerpt
from geronimo IRC.


hogstrom: just wanted to findout if some unused directories in
modules and configs can be removed from branches\2.0.0. The directory server
related suff.
not that it is a big thing... but just some cleanup...
hogstrom: Removing those dirs won't make a difference because the
build is not touching those directories anyway as the corresponding entries
have been commented out in pom.xml files
>if you want to clean it
up that's ok with me...however, we're dealing fall out from some other
little changes :)
>ask on the dev list ... I
gotta run ... got a plane to catch

hogstrom has left #geronimo 
>vamsic007: what are the dirs?
hogstrom: that's why I didn't propose any thing new to add at
this stage :)
the directory server related stuff that has been disabled in the
build for now...
hogstrom: ttyl
kevan: https://issues.apache.org/jira/browse/GERONIMO-3340
keavn: the directory server related stuff that has been disabled
in the build for now...
kevan: the directory server related stuff that has been disabled
in the build for now...
kevan: modules\geronimo-directory configs\ldap-realm
configs\ldap-demo-jetty configs\ldap-demo-tomcat
kevan: The JIRA is on "Take apache directory plugin out of the
main build, put it in plugins"
kevan: djencks disabled these in the main build in rev 558213 by
commenting out the pom.xml entries, but left the code in there as it has not
been moved to plugins.
kevan: now that a copy of the code is in trunk, we may not need
it in branches\2.0 and branches\2.0.0


--vamsi

2.0 release status

[Kevan Miller]

Here's where things stand at the moment

Specs
We have a vote on 3 spec releases that have been held up by a CDDL  
licensing issue. After reviewing the issues, I don't think these  
specs have a problem. They are not built with CDDL licensed  
materials. We  start to rebase our specs on CDDL licensed  
materials. I think this would make things cleaner. However, I don't  
think that it is necessary to do that now.


Schemas
We have an outstanding vote on two schema releases. These releases  
are built from CDDL licensed materials. At the moment, the license  
and notice files for the schema releases are not correct. I think we  
should do the following: move the schema source directories from our  
tck svn repository to our public repository, fix our license and  
notice files, and build schema releases from there. Note that both  
the schema source directories and the resultant schema binaries will  
have CDDL licensed elements. The current guidance that we have  
received from legal-discuss is that both source and binary CDDL is ok  
for us to release. We will need to be sure that our schemas follow  
all CDDL requirements.


TX-Manager and Connector components
The recently released 2.0 version of geronimo-connector has a  
problem. The geronimo-connector-2.0-tests.jar does not contain any  
classes. So, server builds fail when running tests. Matt has created  
a 2.0.1 release. We'll need to vote on this new release.


2.0 Release
Matt and I have been working on updating branches/2.0.0 in  
preparation for a release. At the moment, the build is failing  
because of an xmlbeans version incompatibility. I haven't worked out  
the cause of this problem, yet. Once we're able to build, we can  
start testing and get a release vote started. This vote either cover  
the above specs/schemas/components releases or the vote would be  
dependent on separate release votes.


--kevan 

[jira] Updated: (GERONIMO-3317) "has not been enhanced" error when invoking an EJB 2.1 Entity Bean

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3317:
---

   Patch Info:   (was: [Patch Available])
Affects Version/s: (was: 2.0-M7)
   2.0
Fix Version/s: 2.0.x

> "has not been enhanced" error when invoking an EJB 2.1 Entity Bean
> --
>
> Key: GERONIMO-3317
> URL: https://issues.apache.org/jira/browse/GERONIMO-3317
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0
>Reporter: Song
>Assignee: Kevan Miller
>Priority: Critical
> Fix For: 2.0.x, 2.1
>
> Attachments: GERONIMO-3317.patch, gvtlibTable.ddl
>
>
> My application could be deployed successfully. 
> But when launching an Entity Bean, "has not been enhanced" error is thrown:
> 17:07:58,593 ERROR [OpenEJB] The bean instances business method encountered a 
> system exception: The type "class openejb.gvtlibrary.EJBUser" has not been 
> enhanced.
> <1.0.0-SNAPSHOT-SNAPSHOT fatal user error> 
> org.apache.openjpa.persistence.ArgumentException: The type "class 
> openejb.gvtlibrary.EJBUser" has not been enhanced.
> at 
> org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1610)
> at 
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1584)
> at 
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:663)
> at 
> org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:563)
> at 
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:488)
> at 
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:290)
> at 
> org.apache.openjpa.kernel.BrokerImpl.newObjectId(BrokerImpl.java:1089)
> at 
> org.apache.openjpa.kernel.DelegatingBroker.newObjectId(DelegatingBroker.java:257)
> at 
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:348)
> at 
> org.apache.geronimo.persistence.CMPEntityManagerTxScoped.find(CMPEntityManagerTxScoped.java:125)
> at 
> org.apache.openejb.core.cmp.jpa.JpaCmpEngine.loadBean(JpaCmpEngine.java:171)
> at 
> org.apache.openejb.core.cmp.CmpContainer.findByPrimaryKey(CmpContainer.java:687)
> at 
> org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:284)
> at 
> org.apache.openejb.core.entity.EntityEjbHomeHandler.findX(EntityEjbHomeHandler.java:57)
> at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:160)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:230)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy51.findByPrimaryKey(Unknown Source)
> at javaUtility.EjbUtility.getUser(EjbUtility.java:105)
> at servlets.WelcomeServlet.doPost(WelcomeServlet.java:71)
> at servlets.GVTServlet.service(GVTServlet.java:89)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:801)
> or

[jira] Created: (GERONIMO-3379) j2g: stalls in the middle of parsing a jbosscmp-jdbc.xml

[Viet Hung Nguyen (JIRA)]

j2g: stalls in the middle of parsing a jbosscmp-jdbc.xml


 Key: GERONIMO-3379
 URL: https://issues.apache.org/jira/browse/GERONIMO-3379
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: J2G
 Environment: windows xp
Reporter: Viet Hung Nguyen
 Attachments: geronimo-3379.patch

when the tool is parsing a jbosscmp-jdbc.xml it halts because the root of the 
problem is that it cannot get the needed information out of it. The xpath is 
incorrect. I am going to attach a patch to get the correct elements from this 
xml doc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3379) j2g: stalls in the middle of parsing a jbosscmp-jdbc.xml

[Viet Hung Nguyen (JIRA)]

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

Viet Hung Nguyen updated GERONIMO-3379:
---

Attachment: geronimo-3379.patch

> j2g: stalls in the middle of parsing a jbosscmp-jdbc.xml
> 
>
> Key: GERONIMO-3379
> URL: https://issues.apache.org/jira/browse/GERONIMO-3379
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: J2G
> Environment: windows xp
>Reporter: Viet Hung Nguyen
> Attachments: geronimo-3379.patch
>
>
> when the tool is parsing a jbosscmp-jdbc.xml it halts because the root of the 
> problem is that it cannot get the needed information out of it. The xpath is 
> incorrect. I am going to attach a patch to get the correct elements from this 
> xml doc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3380) Derby embedded database pool created from console doesn't work

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R updated GERONIMO-3380:
--

Attachment: geronimo-web.xml
WebAppJDBCAccess.war
BankDB.sql

> Derby embedded database pool created from console doesn't work
> --
>
> Key: GERONIMO-3380
> URL: https://issues.apache.org/jira/browse/GERONIMO-3380
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Shiva Kumar H R
>Priority: Critical
> Attachments: BankDB.sql, geronimo-web.xml, WebAppJDBCAccess.war
>
>
> Steps to reproduce:
> 1) From Admin Console's "DB Manager" portlet create a database by name 
> "BankDB" and populate it with the contents of "BankDB.sql". 
> 2) From "Database Pools" portlet, create a new database pool using the 
> Geronimo database pool wizard, with the below information:
> Name of Database Pool: BankDBPool
> Database Type: Derby embedded
> Driver JAR: org.apache.derby/derby/10.2.2.0/jar
> Database: BankDB
> 3) From "Deploy New" portlet, deploy "WebAppJDBCAccess.war" using 
> "geronimo-web.xml".
> 4) Open http://localhost:8080/WebAppJDBCAccess/ and click on "Click here to 
> list Customers". Server will fail to show database contents by throwing 
> following errors at command prompt:
> 19:10:59,555 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedCon
> nection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connec
> tion to jdbc:derby:BankDB
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDri
> verMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCD
> riverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo
> nnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterc
> eptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
> r.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn
> terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto
> r.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.
> getConnection(TransactionCachingInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge
> tConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(
> TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.
> getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo
> cateConnection(AbstractConnectionManager.java:87)
> at 
> org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56
> )
> at myPackage.ListCustomers.doGet(ListCustomers.java:41)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav

[jira] Created: (GERONIMO-3380) Derby embedded database pool created from console doesn't work

[Shiva Kumar H R (JIRA)]

Derby embedded database pool created from console doesn't work
--

 Key: GERONIMO-3380
 URL: https://issues.apache.org/jira/browse/GERONIMO-3380
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 2.1
Reporter: Shiva Kumar H R
Priority: Critical


Steps to reproduce:
1) From Admin Console's "DB Manager" portlet create a database by name "BankDB" 
and populate it with the contents of "BankDB.sql". 

2) From "Database Pools" portlet, create a new database pool using the Geronimo 
database pool wizard, with the below information:
Name of Database Pool: BankDBPool
Database Type: Derby embedded
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
Database: BankDB

3) From "Deploy New" portlet, deploy "WebAppJDBCAccess.war" using 
"geronimo-web.xml".

4) Open http://localhost:8080/WebAppJDBCAccess/ and click on "Click here to 
list Customers". Server will fail to show database contents by throwing 
following errors at command prompt:

19:10:59,555 ERROR [MCFConnectionInterceptor] Error occurred creating ManagedCon
nection for [EMAIL PROTECTED]
javax.resource.spi.ResourceAllocationException: Unable to obtain physical connec
tion to jdbc:derby:BankDB
at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDri
verMCF.java:98)
at org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCD
riverMCF.java:73)
at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo
nnection(MCFConnectionInterceptor.java:48)
at org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterc
eptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
r.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn
terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
at org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto
r.getConnection(TransactionEnlistingInterceptor.java:46)
at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.
getConnection(TransactionCachingInterceptor.java:96)
at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge
tConnection(ConnectionHandleInterceptor.java:43)
at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(
TCCLInterceptor.java:39)
at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.
getConnection(ConnectionTrackingInterceptor.java:66)
at org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo
cateConnection(AbstractConnectionManager.java:87)
at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56
)
at myPackage.ListCustomers.doGet(ListCustomers.java:41)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
bjectValve.java:56)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
invoke(GeronimoStandardContext.java:351)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
nimoBeforeAfterValve.java:47)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:104)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
563)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:261)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:581)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.sql.SQLException: Database 'BankDB' not found.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknow
n Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.ne

[jira] Commented: (GERONIMO-3380) Derby embedded database pool created from console doesn't work

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R commented on GERONIMO-3380:
---

The wizard generated deployment plan for database pool is shown below:


http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";>
http://geronimo.apache.org/xml/ns/deployment-1.2";>

console.dbpool
BankDBPool
1.0
rar



org.apache.derby
derby
10.2.2.0
jar







javax.sql.DataSource

BankDBPool
org.apache.derby.jdbc.EmbeddedDriver
jdbc:derby:BankDB



10
0









Note that it lists a dependency on "org.apache.derby/derby/10.2.2.0/jar". This 
earlier used to be a dependency on 
"org.apache.geronimo.configs/system-database".

"BankDBPool2.xml" has the above dependency changed back to "system-database". 
Deploy this new database pool as below:
cd GERONIMO_HOME
java -jar bin/deployer.jar deploy changedDBPoolPlan.xml \
\repository\org\tranql\tranql-connector-ra\1.3\tranql-connector-ra-1.3.rar

Now deploy test web-app "WebAppJDBCAccess.war" with the new plan 
"geronimo-web2.xml" that uses the new database pool "BankDBPool2". Running the 
new web-app http://localhost:8080/WebAppJDBCAccess2 shows that it is now able 
to successfully connect to the database and fetch its data.

> Derby embedded database pool created from console doesn't work
> --
>
> Key: GERONIMO-3380
> URL: https://issues.apache.org/jira/browse/GERONIMO-3380
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Shiva Kumar H R
>Priority: Critical
> Attachments: BankDB.sql, geronimo-web.xml, WebAppJDBCAccess.war
>
>
> Steps to reproduce:
> 1) From Admin Console's "DB Manager" portlet create a database by name 
> "BankDB" and populate it with the contents of "BankDB.sql". 
> 2) From "Database Pools" portlet, create a new database pool using the 
> Geronimo database pool wizard, with the below information:
> Name of Database Pool: BankDBPool
> Database Type: Derby embedded
> Driver JAR: org.apache.derby/derby/10.2.2.0/jar
> Database: BankDB
> 3) From "Deploy New" portlet, deploy "WebAppJDBCAccess.war" using 
> "geronimo-web.xml".
> 4) Open http://localhost:8080/WebAppJDBCAccess/ and click on "Click here to 
> list Customers". Server will fail to show database contents by throwing 
> following errors at command prompt:
> 19:10:59,555 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedCon
> nection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connec
> tion to jdbc:derby:BankDB
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDri
> verMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCD
> riverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo
> nnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterc
> eptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
> r.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn
> terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto
> r.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.
> getConnection(TransactionCachingInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge
> tConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(
> TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.
> getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo
> cateConnection(AbstractConnectionManager.java:87)
> at 

[jira] Updated: (GERONIMO-3380) Derby embedded database pool created from console doesn't work

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R updated GERONIMO-3380:
--

Attachment: geronimo-web2.xml
BankDBPool2.xml

> Derby embedded database pool created from console doesn't work
> --
>
> Key: GERONIMO-3380
> URL: https://issues.apache.org/jira/browse/GERONIMO-3380
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Shiva Kumar H R
>Priority: Critical
> Attachments: BankDB.sql, BankDBPool2.xml, geronimo-web.xml, 
> geronimo-web2.xml, WebAppJDBCAccess.war
>
>
> Steps to reproduce:
> 1) From Admin Console's "DB Manager" portlet create a database by name 
> "BankDB" and populate it with the contents of "BankDB.sql". 
> 2) From "Database Pools" portlet, create a new database pool using the 
> Geronimo database pool wizard, with the below information:
> Name of Database Pool: BankDBPool
> Database Type: Derby embedded
> Driver JAR: org.apache.derby/derby/10.2.2.0/jar
> Database: BankDB
> 3) From "Deploy New" portlet, deploy "WebAppJDBCAccess.war" using 
> "geronimo-web.xml".
> 4) Open http://localhost:8080/WebAppJDBCAccess/ and click on "Click here to 
> list Customers". Server will fail to show database contents by throwing 
> following errors at command prompt:
> 19:10:59,555 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedCon
> nection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connec
> tion to jdbc:derby:BankDB
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDri
> verMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCD
> riverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo
> nnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterc
> eptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
> r.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn
> terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto
> r.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.
> getConnection(TransactionCachingInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge
> tConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(
> TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.
> getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo
> cateConnection(AbstractConnectionManager.java:87)
> at 
> org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56
> )
> at myPackage.ListCustomers.doGet(ListCustomers.java:41)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap

[jira] Updated: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment

[Erik B. Craig (JIRA)]

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

Erik B. Craig updated GERONIMO-3342:


Attachment: (was: geronimo-3342update3.patch)

> Provide a way to launch J2G components from within Eclipse IDE environment
> --
>
> Key: GERONIMO-3342
> URL: https://issues.apache.org/jira/browse/GERONIMO-3342
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: J2G
> Environment: All
>Reporter: Erik B. Craig
>Assignee: Paul McMahan
> Attachments: geronimo-3342.patch, geronimo-3342fix.patch, 
> geronimo-3342update.patch, geronimo-3342update2.patch
>
>
> In order to be more user friendly, j2g should provide a method to launch the 
> components from within the Eclipse IDE environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3381) Error launching jsrc2g from within eclipse if no jsp sources are selected

[Erik B. Craig (JIRA)]

Error launching jsrc2g from within eclipse if no jsp sources are selected
-

 Key: GERONIMO-3381
 URL: https://issues.apache.org/jira/browse/GERONIMO-3381
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: J2G
 Environment: All
Reporter: Erik B. Craig
Assignee: Erik B. Craig


Slight error in the jsrc2g launcher that flips when attempted to be ran without 
selecting jsp sources.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3381) Error launching jsrc2g from within eclipse if no jsp sources are selected

[Erik B. Craig (JIRA)]

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

Erik B. Craig updated GERONIMO-3381:


Attachment: geronimo-3381.patch

Corrected very small missing character (read: typo) in code, everything is okay 
now.

> Error launching jsrc2g from within eclipse if no jsp sources are selected
> -
>
> Key: GERONIMO-3381
> URL: https://issues.apache.org/jira/browse/GERONIMO-3381
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: J2G
> Environment: All
>Reporter: Erik B. Craig
>Assignee: Erik B. Craig
> Attachments: geronimo-3381.patch
>
>
> Slight error in the jsrc2g launcher that flips when attempted to be ran 
> without selecting jsp sources.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Splitting up the server into a few more chunks

[David Jencks]

I certainly agree with your goal but am less sure about your proposed  
naming and organization.  Also from looking at your list it took me a  
couple minutes to figure out what is removed from "server"


I've been thinking that we could proceed by turning bits of the  
server into plugins.  For instance I was planning to turn the  
directory bits I commented out recently into a plugin this week.  I  
think we could fairly easiiy turn jetty, tomcat, and openejb into  
plugins.  I wonder if, after turning the "easy stuff" into plugins  
what we will think about reorganizing the remaining stuff.


So then the question might be how to organize the plugins?

thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0  
branch and trunk has moved on to 2.1 work, I think its time we  
really make a decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the  
server/trunk tree just in better locations organized by  
functionality and feature not by artifact type.  But, now I'm  
thinking we should really do one step more than that, and split up  
the server/trunk project into several smaller and more manageable  
chunks of modules.  I still think that the basic grouping that we  
kinda talked about before should work fine, but instead of having  
them share a project namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder

And then we can group some of the related components up into shared  
projects, or just go out and give each component its own project,  
and/or think about maybe using the same style that the maven/ 
plugins/trunk tree uses, a shared project, but each component is  
related individually... still not sure I like that, kinda messy.


I don't want to end up with a ton of projects either, and I  
certainly don't want to get up using SNAPSHOT versions of these  
puppies if we can help it.  So, maybe to start out we could do these:


server-support
server-framework
server-components
server-assembly

BTW, I'm using "dash" here so that the names don't collide with  
what is there now, but really we could user server/support/trunk,  
server/framework/trunk, etc (which is better IMO for the longer run).


And in the process of making this split up, we can re-arrange  
modules by feature and function instead of by type... and actually  
we have to do that to make the components bits work.


 * * *

I really believe this will help improve the support and  
maintainability of the server's code-base and it will help the  
project scale better as new components are added too.  For  
developers that are only interested in working on a specific  
component, it reduces the amount of other sources they need to  
check out and reduces the time to build too, so that they can build  
a clean server assembly faster and developer their features sooner  
and hopefully have less hair-pulling and more relaxed beer drinking  
as they pat themselves on the back for doing such a speedy job.


I really, really... really, really, really ( :-P ) think that we  
*must* move along these lines for the longer term health of the  
project...


Comments?  Suggestions?

--jason

Re: Cleanup of directory server code in branches\2.0 and branches\2.0.0

[David Jencks]

I was hoping to get to this today.  I need to move the commented out  
stuff to the plugins area and I'd like to make it so the code removal  
on all branches is linked in svn.


thanks
david jencks

On Aug 6, 2007, at 5:46 AM, Vamsavardhana Reddy wrote:

As part of "GERONIMO-3340 Take apache directory plugin out of the  
main build, put it in plugins.", the directory server code has been  
disabled from the main build in rev 558213 (prior to creating  
branches\2.0), by commenting out the entries in pom.xml, but the  
code has been left in the trunk as it has not been moved to  
plugins.  Now that the code is in trunk, the copy of this unused  
code is not required in branches\2.0 and branches\2.0.0.  I thought  
I would cleanup this code from the branches.  I checked with Matt  
and he is ok with it.  But, he asked me to check on the dev-list.   
If there are no objections, I propose to knock this unused code  
from branches (from branches\2.0.0 only if an RC has not been spun  
already).  Here is an excerpt from geronimo IRC.



	hogstrom: just wanted to findout if some unused  
directories in modules and configs can be removed from branches 
\2.0.0. The directory server related suff.


not that it is a big thing... but just some cleanup...

	hogstrom: Removing those dirs won't make a difference  
because the build is not touching those directories anyway as the  
corresponding entries have been commented out in pom.xml files


	if you want to clean it up that's ok with me...however,  
we're dealing fall out from some other little changes :)


< hogstrom>	ask on the dev list ... I gotta run ... got a plane to  
catch



hogstrom has left #geronimo

   vamsic007: what are the dirs?

 	hogstrom: that's why I didn't propose any thing new to  
add at this stage :)


	the directory server related stuff that has been  
disabled in the build for now...


< vamsic007>  hogstrom: ttyl

   kevan: https://issues.apache.org/jira/browse/GERONIMO-3340

	keavn: the directory server related stuff that has been  
disabled in the build for now...


< vamsic007>	kevan: the directory server related stuff that has  
been disabled in the build for now...


	kevan: modules\geronimo-directory configs\ldap-realm  
configs\ldap-demo-jetty configs\ldap-demo-tomcat


	 kevan: The JIRA is on "Take apache directory plugin  
out of the main build, put it in plugins"


	kevan: djencks disabled these in the main build in rev  
558213 by commenting out the pom.xml entries, but left the code in  
there as it has not been moved to plugins.


	 kevan: now that a copy of the code is in trunk, we may  
not need it in branches\2.0 and branches\2.0.0




--vamsi

Re: Splitting up the server into a few more chunks

[Jason Dillon]

Um, I just took a blind stab in the dark...

But, what I was thinking was that we have  the core modules which are  
the bare minimum to boot up a functional Geronimo server w/o any  
JavaEE muck, then slice up the other components into plugins, though  
they don't really need to be G plugins, they just need to hold groups  
of modules to provide a components functionality and configuration.


I also split up the support bits, as those should be common across  
the core framework bits and components/plugins...


I'm certainly open to ideas and discussion on this.  I think we  
really need to move in this direction.


--jason


On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

I certainly agree with your goal but am less sure about your  
proposed naming and organization.  Also from looking at your list  
it took me a couple minutes to figure out what is removed from  
"server"


I've been thinking that we could proceed by turning bits of the  
server into plugins.  For instance I was planning to turn the  
directory bits I commented out recently into a plugin this week.  I  
think we could fairly easiiy turn jetty, tomcat, and openejb into  
plugins.  I wonder if, after turning the "easy stuff" into plugins  
what we will think about reorganizing the remaining stuff.


So then the question might be how to organize the plugins?

thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0  
branch and trunk has moved on to 2.1 work, I think its time we  
really make a decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the  
server/trunk tree just in better locations organized by  
functionality and feature not by artifact type.  But, now I'm  
thinking we should really do one step more than that, and split up  
the server/trunk project into several smaller and more manageable  
chunks of modules.  I still think that the basic grouping that we  
kinda talked about before should work fine, but instead of having  
them share a project namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder

And then we can group some of the related components up into  
shared projects, or just go out and give each component its own  
project, and/or think about maybe using the same style that the  
maven/plugins/trunk tree uses, a shared project, but each  
component is related individually... still not sure I like that,  
kinda messy.


I don't want to end up with a ton of projects either, and I  
certainly don't want to get up using SNAPSHOT versions of these  
puppies if we can help it.  So, maybe to start out we could do these:


server-support
server-framework
server-components
server-assembly

BTW, I'm using "dash" here so that the names don't collide with  
what is there now, but really we could user server/support/trunk,  
server/framework/trunk, etc (which is better IMO for the longer run).


And in the process of making this split up, we can re-arrange  
modules by feature and function instead of by type... and actually  
we have to do that to make the components bits work.


 * * *

I really believe this will help improve the support and  
maintainability of the server's code-base and it will help the  
project scale better as new components are added too.  For  
developers that are only interested in working on a specific  
component, it reduces the amount of other sources they need to  
check out and reduces the time to build too, so that they can  
build a clean server assembly faster and developer their features  
sooner and hopefully have less hair-pulling and more relaxed beer  
drinking as they pat themselves on the back for doing such a  
speedy job.


I really, really... really, really, really ( :-P ) think that we  
*must* move along these lines for the longer term health of the  
project...


Comments?  Suggestions?

--jason

Re: Cleanup of directory server code in branches\2.0 and branches\2.0.0

[Vamsavardhana Reddy]

Even better if the code is moved to plugins and removed from server tree at
the same time.

--vamsi


On 8/6/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> I was hoping to get to this today.  I need to move the commented out stuff
> to the plugins area and I'd like to make it so the code removal on all
> branches is linked in svn.
> thanks
> david jencks
>
> On Aug 6, 2007, at 5:46 AM, Vamsavardhana Reddy wrote:
>
> As part of "GERONIMO-3340 Take apache directory plugin out of the main
> build, put it in plugins.", the directory server code has been disabled from
> the main build in rev 558213 (prior to creating branches\2.0), by commenting
> out the entries in pom.xml, but the code has been left in the trunk as it
> has not been moved to plugins.  Now that the code is in trunk, the copy of
> this unused code is not required in branches\2.0 and branches\2.0.0.  I
> thought I would cleanup this code from the branches.  I checked with Matt
> and he is ok with it.  But, he asked me to check on the dev-list.  If there
> are no objections, I propose to knock this unused code from branches (from
> branches\2.0.0 only if an RC has not been spun already).  Here is an excerpt
> from geronimo IRC.
>
>
> hogstrom: just wanted to findout if some unused directories in
> modules and configs can be removed from branches\2.0.0. The directory server
> related suff.
>  not that it is a big thing... but just some cleanup...
> hogstrom: Removing those dirs won't make a difference because
> the build is not touching those directories anyway as the corresponding
> entries have been commented out in pom.xml files
> if you want to clean it up that's ok with me...however, we're
> dealing fall out from some other little changes :)
> < hogstrom>ask on the dev list ... I gotta run ... got a plane to catch
>
> hogstrom has left #geronimo
>  vamsic007: what are the dirs?
>  hogstrom: that's why I didn't propose any thing new to add at
> this stage :)
>  the directory server related stuff that has been disabled in
> the build for now...
> < vamsic007>hogstrom: ttyl
> kevan: https://issues.apache.org/jira/browse/GERONIMO-3340
>  keavn: the directory server related stuff that has been
> disabled in the build for now...
> < vamsic007>kevan: the directory server related stuff that has been
> disabled in the build for now...
> kevan: modules\geronimo-directory configs\ldap-realm
> configs\ldap-demo-jetty configs\ldap-demo-tomcat
>  kevan: The JIRA is on "Take apache directory plugin out of the
> main build, put it in plugins"
> kevan: djencks disabled these in the main build in rev 558213
> by commenting out the pom.xml entries, but left the code in there as it
> has not been moved to plugins.
>  kevan: now that a copy of the code is in trunk, we may not
> need it in branches\2.0 and branches\2.0.0
>
>
> --vamsi
>
>
>

Re: 2.0 release status

[David Jencks]

On Aug 6, 2007, at 6:16 AM, Kevan Miller wrote:


Here's where things stand at the moment

Specs
We have a vote on 3 spec releases that have been held up by a CDDL  
licensing issue. After reviewing the issues, I don't think these  
specs have a problem. They are not built with CDDL licensed  
materials. We  start to rebase our specs on CDDL licensed  
materials. I think this would make things cleaner. However, I don't  
think that it is necessary to do that now.


It would also make it so we couldn't release them according to  the  
draft 3rd party licensing policy at http://people.apache.org/~cliffs/ 
3party.html which prohibits cddl source code in apache releases  
("Categoy B).  Sam has indicated that xsds are source code in his  
opinion and I certainly agree.




Schemas
We have an outstanding vote on two schema releases. These releases  
are built from CDDL licensed materials.
I believe the copies under vote are NOT built from CDDL but from the  
previous non-cddl xsds.  I guess only Prasad knows for sure.


At the moment, the license and notice files for the schema releases  
are not correct.
I think they are correct , since the jars are not built from cddl  
sources.  In any case I think that (in disagreement to Craig Russell)  
that even if we started with CDDL schemas the xmlbeans generated  
source and binary would be under asf, not cddl.  If not, then the  
xmlbeans code we've been using generated from the pre-cddl schemas  
would be under the mysterious sun license that prohibits all use, so  
we wouldn't be able to write a javaee server in the first place.


I think we should do the following: move the schema source  
directories from our tck svn repository to our public repository,  
fix our license and notice files, and build schema releases from  
there. Note that both the schema source directories and the  
resultant schema binaries will have CDDL licensed elements. The  
current guidance that we have received from legal-discuss is that  
both source and binary CDDL is ok for us to release. We will need  
to be sure that our schemas follow all CDDL requirements.


I don't think we should do this until the violent disagreement  
between the 3rd party licensing policy and sam's suggestion that it's  
ok to use the cddl xsds is resolved.


thanks
david jencks



TX-Manager and Connector components
The recently released 2.0 version of geronimo-connector has a  
problem. The geronimo-connector-2.0-tests.jar does not contain any  
classes. So, server builds fail when running tests. Matt has  
created a 2.0.1 release. We'll need to vote on this new release.


2.0 Release
Matt and I have been working on updating branches/2.0.0 in  
preparation for a release. At the moment, the build is failing  
because of an xmlbeans version incompatibility. I haven't worked  
out the cause of this problem, yet. Once we're able to build, we  
can start testing and get a release vote started. This vote either  
cover the above specs/schemas/components releases or the vote would  
be dependent on separate release votes.


--kevan

Re: 2.0 release status

[Vamsavardhana Reddy]

On 8/6/07, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> Here's where things stand at the moment
>
> Specs
> We have a vote on 3 spec releases that have been held up by a CDDL
> licensing issue. After reviewing the issues, I don't think these
> specs have a problem. They are not built with CDDL licensed
> materials. We  start to rebase our specs on CDDL licensed
> materials. I think this would make things cleaner. However, I don't
> think that it is necessary to do that now.
>
> Schemas
> We have an outstanding vote on two schema releases. These releases
> are built from CDDL licensed materials. At the moment, the license
> and notice files for the schema releases are not correct. I think we
> should do the following: move the schema source directories from our
> tck svn repository to our public repository, fix our license and
> notice files, and build schema releases from there. Note that both
> the schema source directories and the resultant schema binaries will
> have CDDL licensed elements. The current guidance that we have
> received from legal-discuss is that both source and binary CDDL is ok
> for us to release. We will need to be sure that our schemas follow
> all CDDL requirements.
>
> TX-Manager and Connector components
> The recently released 2.0 version of geronimo-connector has a
> problem. The geronimo-connector-2.0-tests.jar does not contain any
> classes. So, server builds fail when running tests. Matt has created
> a 2.0.1 release. We'll need to vote on this new release.
>
> 2.0 Release
> Matt and I have been working on updating branches/2.0.0 in
> preparation for a release. At the moment, the build is failing
> because of an xmlbeans version incompatibility. I haven't worked out
> the cause of this problem, yet. Once we're able to build, we can
> start testing and get a release vote started. This vote either cover
> the above specs/schemas/components releases or the vote would be
> dependent on separate release votes.


I do not know if this information is of great help and if the module I am
referring here is the one causing build failure.  I only hope it is useful.
When I build modules\geronimo-j2ee-builder, I get a build failure with
XmlBeans compile failed.  If I use IBMJDK1.5.0 it builds fine, but, without
the tests on.  I remember running into a similar problem attempting to build
G1.1 or 1.2 (I don't remember exactly) with IBMJDK and that time I had to
tweak some "exclusion" tags to get past some errors.   This is what prompted
me to attempt if that module builds fine using IBMJDK.  I have no
explanation why the module builds fine in branches\2.0.

--vamsi

--kevan
>

Re: 2.0 release status

[Vamsavardhana Reddy]

This is crude!!  First I ran the build on modules\geronimo-j2ee-builder with
IBMJDK1.5.0 with tests turned off to be able to build the module.  Then I
ran the build (not a clean build) with SunJDK1.5.0 with tests on and the
tests passed!!

--vamsi


On 8/6/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
>
>
>
> On 8/6/07, Kevan Miller <[EMAIL PROTECTED]> wrote:
> >
> > Here's where things stand at the moment
> >
> > Specs
> > We have a vote on 3 spec releases that have been held up by a CDDL
> > licensing issue. After reviewing the issues, I don't think these
> > specs have a problem. They are not built with CDDL licensed
> > materials. We  start to rebase our specs on CDDL licensed
> > materials. I think this would make things cleaner. However, I don't
> > think that it is necessary to do that now.
> >
> > Schemas
> > We have an outstanding vote on two schema releases. These releases
> > are built from CDDL licensed materials. At the moment, the license
> > and notice files for the schema releases are not correct. I think we
> > should do the following: move the schema source directories from our
> > tck svn repository to our public repository, fix our license and
> > notice files, and build schema releases from there. Note that both
> > the schema source directories and the resultant schema binaries will
> > have CDDL licensed elements. The current guidance that we have
> > received from legal-discuss is that both source and binary CDDL is ok
> > for us to release. We will need to be sure that our schemas follow
> > all CDDL requirements.
> >
> > TX-Manager and Connector components
> > The recently released 2.0 version of geronimo-connector has a
> > problem. The geronimo-connector-2.0-tests.jar does not contain any
> > classes. So, server builds fail when running tests. Matt has created
> > a 2.0.1 release. We'll need to vote on this new release.
> >
> > 2.0 Release
> > Matt and I have been working on updating branches/2.0.0 in
> > preparation for a release. At the moment, the build is failing
> > because of an xmlbeans version incompatibility. I haven't worked out
> > the cause of this problem, yet. Once we're able to build, we can
> > start testing and get a release vote started. This vote either cover
> > the above specs/schemas/components releases or the vote would be
> > dependent on separate release votes.
>
>
> I do not know if this information is of great help and if the module I am
> referring here is the one causing build failure.  I only hope it is useful.
> When I build modules\geronimo-j2ee-builder, I get a build failure with
> XmlBeans compile failed.  If I use IBMJDK1.5.0 it builds fine, but,
> without the tests on.  I remember running into a similar problem attempting
> to build G1.1 or 1.2 (I don't remember exactly) with IBMJDK and that time
> I had to tweak some "exclusion" tags to get past some errors.   This is what
> prompted me to attempt if that module builds fine using IBMJDK.  I have no
> explanation why the module builds fine in branches\2.0.
>
> --vamsi
>
> --kevan
> >
>
>

Re: 2.0 release status

[Donald Woods]

Here are my results -
1) Rebuilt Specs 1.4 and 1.5 on Linux with Sun 1.5.0_11 and the released 
maven-xmlbeans-plugin-2.3.1.
2) Built the server on Linux w/ IBM 1.5.0 SR4 (except for geronimo-corba which 
requires Sun JDK) with the released maven-xmlbeans-plugin-2.3.1 and tests 
enabled - everything built.


I also built the server on Linux w/ Sun 1.5.0_11 using the specs I rebuilt in 
#1 above and everything worked


Maybe the specs and server have to be built with the same 
maven-xmlbeans-plugin level???



-Donald

Vamsavardhana Reddy wrote:



On 8/6/07, *Kevan Miller* <[EMAIL PROTECTED] 
> wrote:


Here's where things stand at the moment

Specs
We have a vote on 3 spec releases that have been held up by a CDDL
licensing issue. After reviewing the issues, I don't think these
specs have a problem. They are not built with CDDL licensed
materials. We  start to rebase our specs on CDDL licensed
materials. I think this would make things cleaner. However, I don't
think that it is necessary to do that now.

Schemas
We have an outstanding vote on two schema releases. These releases
are built from CDDL licensed materials. At the moment, the license
and notice files for the schema releases are not correct. I think we
should do the following: move the schema source directories from our
tck svn repository to our public repository, fix our license and
notice files, and build schema releases from there. Note that both
the schema source directories and the resultant schema binaries will
have CDDL licensed elements. The current guidance that we have
received from legal-discuss is that both source and binary CDDL is ok
for us to release. We will need to be sure that our schemas follow
all CDDL requirements.

TX-Manager and Connector components
The recently released 2.0 version of geronimo-connector has a
problem. The geronimo-connector-2.0-tests.jar does not contain any
classes. So, server builds fail when running tests. Matt has created
a 2.0.1 release. We'll need to vote on this new release.

2.0 Release
Matt and I have been working on updating branches/2.0.0 in
preparation for a release. At the moment, the build is failing
because of an xmlbeans version incompatibility. I haven't worked out
the cause of this problem, yet. Once we're able to build, we can
start testing and get a release vote started. This vote either cover
the above specs/schemas/components releases or the vote would be
dependent on separate release votes.


I do not know if this information is of great help and if the module I 
am referring here is the one causing build failure.  I only hope it is 
useful.  When I build modules\geronimo-j2ee-builder, I get a build 
failure with XmlBeans compile failed.  If I use IBMJDK1.5.0 it builds 
fine, but, without the tests on.  I remember running into a similar 
problem attempting to build G1.1 or 1.2 (I don't remember exactly) with 
IBMJDK and that time I had to tweak some "exclusion" tags to get past 
some errors.   This is what prompted me to attempt if that module builds 
fine using IBMJDK.  I have no explanation why the module builds fine in 
branches\2.0.


--vamsi

--kevan




smime.p7s
Description: S/MIME Cryptographic Signature

[BUILD] 2.0.0: Failed for Revision: 563183

[prasad]

OpenEJB trunk at 
Geronimo Revision: 563183 built with tests skipped
 
See the full build-1240.log file at 
http://people.apache.org/~prasad/binaries/20070806/build-1240.log
 
[WARNING] Unable to get resource 'org.codehaus.plexus:plexus-utils:pom:1.0.4' 
from repository java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom
[WARNING] Unable to get resource 'org.codehaus.plexus:plexus-utils:pom:1.0.4' 
from repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom
6K downloaded
Downloading: http://download.java.net/maven/1//com.jcraft/poms/jsch-0.1.27.pom
[WARNING] Unable to get resource 'com.jcraft:jsch:pom:0.1.27' from repository 
java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//com/jcraft/jsch/0.1.27/jsch-0.1.27.pom
[WARNING] Unable to get resource 'com.jcraft:jsch:pom:0.1.27' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/com/jcraft/jsch/0.1.27/jsch-0.1.27.pom
965b downloaded
Downloading: 
http://download.java.net/maven/1//org.codehaus.plexus/poms/plexus-interactivity-api-1.0-alpha-4.pom
[WARNING] Unable to get resource 
'org.codehaus.plexus:plexus-interactivity-api:pom:1.0-alpha-4' from repository 
java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.pom
[WARNING] Unable to get resource 
'org.codehaus.plexus:plexus-interactivity-api:pom:1.0-alpha-4' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.pom
6K downloaded
Downloading: 
http://download.java.net/maven/1//org.codehaus.plexus/poms/plexus-container-default-1.0-alpha-7.pom
[WARNING] Unable to get resource 
'org.codehaus.plexus:plexus-container-default:pom:1.0-alpha-7' from repository 
java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
[WARNING] Unable to get resource 
'org.codehaus.plexus:plexus-container-default:pom:1.0-alpha-7' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
1K downloaded
Downloading: 
http://download.java.net/maven/1//plexus/poms/plexus-containers-1.0.2.pom
[WARNING] Unable to get resource 'plexus:plexus-containers:pom:1.0.2' from 
repository java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
[WARNING] Unable to get resource 'plexus:plexus-containers:pom:1.0.2' from 
repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
471b downloaded
Downloading: http://download.java.net/maven/1//plexus/poms/plexus-root-1.0.3.pom
[WARNING] Unable to get resource 'plexus:plexus-root:pom:1.0.3' from repository 
java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
[WARNING] Unable to get resource 'plexus:plexus-root:pom:1.0.3' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repo1.maven.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
5K downloaded
Downloading: http://download.java.net/maven/1//junit/poms/junit-3.8.1.pom
[WARNING] Unable to get resource 'junit:junit:pom:3.8.1' from repository 
java.net (http://download.java.net/maven/1/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//junit/junit/3.8.1/junit-3.8.1.pom
[WARNING] Unable to get resource 'junit:junit:pom:3.8.1' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/junit/junit/3.8.1/junit-3.8.1.pom
998b downloaded
Downloading: 
http://download.java.net/maven/1//plexus/poms/plexus-utils-1.0.2.pom
[WARNING] Unable to get resource 'plexus:plexus-utils:pom:1.0.2' from 
repository java.net (http://download.java.net/maven/1/)
D

Re: Splitting up the server into a few more chunks

[Donald Woods]

Anything more than 6 to 8 groupings could cause chaos (just like at our 
current release process which takes weeks to get everything voted and released...)


We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the wiki)
- components (shared/used by other projects)
- server (current catch-all)

After cleanup of server to move the samples to /samples and ApacheDS to 
/plugins, we should consider the more drastic changes, like moving the base 
Admin Console support (via Pluto 1.2) out to /plugins and start moving the 
Portlets into the actual modules/configs that they administer


Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level grouping 
and only contains server modules

- configs - current configs, which can be installed as plugins
- assemblies - current assemblies, which require the configs as input


-Donald

Jason Dillon wrote:

Um, I just took a blind stab in the dark...

But, what I was thinking was that we have  the core modules which are 
the bare minimum to boot up a functional Geronimo server w/o any JavaEE 
muck, then slice up the other components into plugins, though they don't 
really need to be G plugins, they just need to hold groups of modules to 
provide a components functionality and configuration.


I also split up the support bits, as those should be common across the 
core framework bits and components/plugins...


I'm certainly open to ideas and discussion on this.  I think we really 
need to move in this direction.


--jason


On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

I certainly agree with your goal but am less sure about your proposed 
naming and organization.  Also from looking at your list it took me a 
couple minutes to figure out what is removed from "server"


I've been thinking that we could proceed by turning bits of the server 
into plugins.  For instance I was planning to turn the directory bits 
I commented out recently into a plugin this week.  I think we could 
fairly easiiy turn jetty, tomcat, and openejb into plugins.  I wonder 
if, after turning the "easy stuff" into plugins what we will think 
about reorganizing the remaining stuff.


So then the question might be how to organize the plugins?

thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0 branch 
and trunk has moved on to 2.1 work, I think its time we really make a 
decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the 
server/trunk tree just in better locations organized by functionality 
and feature not by artifact type.  But, now I'm thinking we should 
really do one step more than that, and split up the server/trunk 
project into several smaller and more manageable chunks of modules.  
I still think that the basic grouping that we kinda talked about 
before should work fine, but instead of having them share a project 
namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder

And then we can group some of the related components up into shared 
projects, or just go out and give each component its own project, 
and/or think about maybe using the same style that the 
maven/plugins/trunk tree uses, a shared project, but each component 
is related individually... still not sure I like that, kinda messy.


I don't want to end up with a ton of projects either, and I certainly 
don't want to get up using SNAPSHOT versions of these puppies if we 
can help it.  So, maybe to start out we could do these:


server-support
server-framework
server-components
server-assembly

BTW, I'm using "dash" here so that the names don't collide with what 
is there now, but really we could user server/support/trunk, 
server/framework/trunk, etc (which is better IMO for the longer run).


And in the process of making this split up, we can re-arrange modules 
by feature and function instead of

Re: Cleanup of directory server code in branches\2.0 and branches\2.0.0

[Vamsavardhana Reddy]

David,

To be clear, you will take care of this whenever you can attend to it...
Right?

Vamsi

On 8/6/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> I was hoping to get to this today.  I need to move the commented out stuff
> to the plugins area and I'd like to make it so the code removal on all
> branches is linked in svn.
> thanks
> david jencks
>
> On Aug 6, 2007, at 5:46 AM, Vamsavardhana Reddy wrote:
>
> As part of "GERONIMO-3340 Take apache directory plugin out of the main
> build, put it in plugins.", the directory server code has been disabled from
> the main build in rev 558213 (prior to creating branches\2.0), by commenting
> out the entries in pom.xml, but the code has been left in the trunk as it
> has not been moved to plugins.  Now that the code is in trunk, the copy of
> this unused code is not required in branches\2.0 and branches\2.0.0.  I
> thought I would cleanup this code from the branches.  I checked with Matt
> and he is ok with it.  But, he asked me to check on the dev-list.  If there
> are no objections, I propose to knock this unused code from branches (from
> branches\2.0.0 only if an RC has not been spun already).  Here is an excerpt
> from geronimo IRC.
>
>
> hogstrom: just wanted to findout if some unused directories in
> modules and configs can be removed from branches\2.0.0. The directory server
> related suff.
>  not that it is a big thing... but just some cleanup...
> hogstrom: Removing those dirs won't make a difference because
> the build is not touching those directories anyway as the corresponding
> entries have been commented out in pom.xml files
> if you want to clean it up that's ok with me...however, we're
> dealing fall out from some other little changes :)
> < hogstrom>ask on the dev list ... I gotta run ... got a plane to catch
>
> hogstrom has left #geronimo
>  vamsic007: what are the dirs?
>  hogstrom: that's why I didn't propose any thing new to add at
> this stage :)
>  the directory server related stuff that has been disabled in
> the build for now...
> < vamsic007>hogstrom: ttyl
> kevan: https://issues.apache.org/jira/browse/GERONIMO-3340
>  keavn: the directory server related stuff that has been
> disabled in the build for now...
> < vamsic007>kevan: the directory server related stuff that has been
> disabled in the build for now...
> kevan: modules\geronimo-directory configs\ldap-realm
> configs\ldap-demo-jetty configs\ldap-demo-tomcat
>  kevan: The JIRA is on "Take apache directory plugin out of the
> main build, put it in plugins"
> kevan: djencks disabled these in the main build in rev 558213
> by commenting out the pom.xml entries, but left the code in there as it
> has not been moved to plugins.
>  kevan: now that a copy of the code is in trunk, we may not
> need it in branches\2.0 and branches\2.0.0
>
>
> --vamsi
>
>
>

Re: Splitting up the server into a few more chunks

[Donald Woods]

Another thought (now that I had some lunch)

What if we create a "builders/deployers" grouping, which contained the modules 
and configs needed for each builder, like -

deployers
myfaces
modules
geronimo-myfaces
geronimo-myfaces-builder
configs
myfaces
myfaces-deployers
tomcat
. . .
jetty
. . .

Anything that didn't fit into a deployer/builder category, could go into a 
system grouping or the existing components group.



Then again, maybe we need to step back from the current source code structure 
and think more along the lines of Lego blocks or OSGi bundles in a server, 
agree to what that "framework" would look like and then slice and dice our 
current .m2 structure into those new buckets.



-Donald

Donald Woods wrote:
Anything more than 6 to 8 groupings could cause chaos (just like at our 
current release process which takes weeks to get everything voted and 
released...)


We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the wiki)
- components (shared/used by other projects)
- server (current catch-all)

After cleanup of server to move the samples to /samples and ApacheDS to 
/plugins, we should consider the more drastic changes, like moving the 
base Admin Console support (via Pluto 1.2) out to /plugins and start 
moving the Portlets into the actual modules/configs that they 
administer


Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level 
grouping and only contains server modules

- configs - current configs, which can be installed as plugins
- assemblies - current assemblies, which require the configs as input


-Donald

Jason Dillon wrote:

Um, I just took a blind stab in the dark...

But, what I was thinking was that we have  the core modules which are 
the bare minimum to boot up a functional Geronimo server w/o any 
JavaEE muck, then slice up the other components into plugins, though 
they don't really need to be G plugins, they just need to hold groups 
of modules to provide a components functionality and configuration.


I also split up the support bits, as those should be common across the 
core framework bits and components/plugins...


I'm certainly open to ideas and discussion on this.  I think we really 
need to move in this direction.


--jason


On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

I certainly agree with your goal but am less sure about your proposed 
naming and organization.  Also from looking at your list it took me a 
couple minutes to figure out what is removed from "server"


I've been thinking that we could proceed by turning bits of the 
server into plugins.  For instance I was planning to turn the 
directory bits I commented out recently into a plugin this week.  I 
think we could fairly easiiy turn jetty, tomcat, and openejb into 
plugins.  I wonder if, after turning the "easy stuff" into plugins 
what we will think about reorganizing the remaining stuff.


So then the question might be how to organize the plugins?

thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0 
branch and trunk has moved on to 2.1 work, I think its time we 
really make a decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the 
server/trunk tree just in better locations organized by 
functionality and feature not by artifact type.  But, now I'm 
thinking we should really do one step more than that, and split up 
the server/trunk project into several smaller and more manageable 
chunks of modules.  I still think that the basic grouping that we 
kinda talked about before should work fine, but instead of having 
them share a project namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transactio

Re: Splitting up the server into a few more chunks

[Jason Dillon]

On Aug 6, 2007, at 9:59 AM, Donald Woods wrote:
Anything more than 6 to 8 groupings could cause chaos (just like at  
our current release process which takes weeks to get everything  
voted and released...)


Yes, it has to be done very carefully, though if you look a Maven,  
Plexus and the related bits, they tend to release smaller groups of  
modules together and for the most part it does work.




We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the  
wiki)

- components (shared/used by other projects)
- server (current catch-all)

After cleanup of server to move the samples to /samples and  
ApacheDS to /plugins, we should consider the more drastic changes,  
like moving the base Admin Console support (via Pluto 1.2) out to / 
plugins and start moving the Portlets into the actual modules/ 
configs that they administer


Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level  
grouping and only contains server modules

- configs - current configs, which can be installed as plugins


One key thing that *must* change IMO, is we need to group code jars  
with config jars (cars), the current split of modules/* configs/* is  
very artificial and doesn't really help make things easy for  
developers to update a specific component with out a lot of cd; mvn;  
junk or custom scripts.


--jason

Re: Splitting up the server into a few more chunks

[Jason Dillon]

I'd rather not have another level to simply separate code jars from  
config jars...  I think they should all live together, and if needed  
we suffix the config bits with "-config", so you'd have:


   activemq-broker
   activemq-broker-config
   activemq-ra
   activemq-ra-config

IMO, no need for another level of nested directories.

But regaurdless, my drive here is to help make it easier for folks to  
develop G and develop G plugins w/o having to build the entire  
server, which as well all know can be problematic from time to time.


--jason


On Aug 6, 2007, at 11:12 AM, Donald Woods wrote:


Another thought (now that I had some lunch)

What if we create a "builders/deployers" grouping, which contained  
the modules and configs needed for each builder, like -

deployers
myfaces
modules
geronimo-myfaces
geronimo-myfaces-builder
configs
myfaces
myfaces-deployers
tomcat
. . .
jetty
. . .

Anything that didn't fit into a deployer/builder category, could go  
into a system grouping or the existing components group.



Then again, maybe we need to step back from the current source code  
structure and think more along the lines of Lego blocks or OSGi  
bundles in a server, agree to what that "framework" would look like  
and then slice and dice our current .m2 structure into those new  
buckets.



-Donald

Donald Woods wrote:
Anything more than 6 to 8 groupings could cause chaos (just like  
at our current release process which takes weeks to get everything  
voted and released...)

We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the  
wiki)

- components (shared/used by other projects)
- server (current catch-all)
After cleanup of server to move the samples to /samples and  
ApacheDS to /plugins, we should consider the more drastic changes,  
like moving the base Admin Console support (via Pluto 1.2) out to / 
plugins and start moving the Portlets into the actual modules/ 
configs that they administer

Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level  
grouping and only contains server modules

- configs - current configs, which can be installed as plugins
- assemblies - current assemblies, which require the configs as input
-Donald
Jason Dillon wrote:

Um, I just took a blind stab in the dark...

But, what I was thinking was that we have  the core modules which  
are the bare minimum to boot up a functional Geronimo server w/o  
any JavaEE muck, then slice up the other components into plugins,  
though they don't really need to be G plugins, they just need to  
hold groups of modules to provide a components functionality and  
configuration.


I also split up the support bits, as those should be common  
across the core framework bits and components/plugins...


I'm certainly open to ideas and discussion on this.  I think we  
really need to move in this direction.


--jason


On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

I certainly agree with your goal but am less sure about your  
proposed naming and organization.  Also from looking at your  
list it took me a couple minutes to figure out what is removed  
from "server"


I've been thinking that we could proceed by turning bits of the  
server into plugins.  For instance I was planning to turn the  
directory bits I commented out recently into a plugin this  
week.  I think we could fairly easiiy turn jetty, tomcat, and  
openejb into plugins.  I wonder if, after turning the "easy  
stuff" into plugins what we will think about reorganizing the  
remaining stuff.


So then the question might be how to organize the plugins?

thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0  
branch and trunk has moved on to 2.1 work, I think its time we  
really make a decision on this and implement it.


Before, I had been thinking of keeping all of the modules in  
the server/trunk tree just in better locations organized by  
functionality and feature not by artifact type.  But, now I'm  
thinking we should really do one step more than that, and split  
up the server/trunk project into several smaller and more  
manageable chunks of modules.  I still think that the basic  
grouping that we kinda talked about before should work fine,  
but instead of having them share a project namespace we give  
them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clust

Re: 2.0 release status

[Kevan Miller]

On Aug 6, 2007, at 11:25 AM, David Jencks wrote:



On Aug 6, 2007, at 6:16 AM, Kevan Miller wrote:


Here's where things stand at the moment

Specs
We have a vote on 3 spec releases that have been held up by a CDDL  
licensing issue. After reviewing the issues, I don't think these  
specs have a problem. They are not built with CDDL licensed  
materials. We  start to rebase our specs on CDDL licensed  
materials. I think this would make things cleaner. However, I  
don't think that it is necessary to do that now.


It would also make it so we couldn't release them according to  the  
draft 3rd party licensing policy at http://people.apache.org/ 
~cliffs/3party.html which prohibits cddl source code in apache  
releases ("Categoy B).  Sam has indicated that xsds are source code  
in his opinion and I certainly agree.


I also agree that they are source code.

According to the draft 3rd party licensing policy, you are correct. I  
used to treat that very literally.


However, we have also gotten a clear advice from Sam Ruby, a member  
and current chair of the ASF legal team, that the use of CDDL schemas  
is ok. In fact, Sam has instructed all projects to replace Sun  
Proprietary/confidential dtd's and xsd's with their CDDL equivalent.


As long as the Geronimo PMC agrees and we follow the rules of the  
CDDL license, I don't see a problem. I think we're better off.






Schemas
We have an outstanding vote on two schema releases. These releases  
are built from CDDL licensed materials.
I believe the copies under vote are NOT built from CDDL but from  
the previous non-cddl xsds.  I guess only Prasad knows for sure.


I believe you are correct. I got ahead of myself.



At the moment, the license and notice files for the schema  
releases are not correct.
I think they are correct , since the jars are not built from cddl  
sources.  In any case I think that (in disagreement to Craig  
Russell) that even if we started with CDDL schemas the xmlbeans  
generated source and binary would be under asf, not cddl.  If not,  
then the xmlbeans code we've been using generated from the pre-cddl  
schemas would be under the mysterious sun license that prohibits  
all use, so we wouldn't be able to write a javaee server in the  
first place.


I'm going to skip this for now. We can come back to it, if you still  
feel we should not move to CDDL licensed schemas.




I think we should do the following: move the schema source  
directories from our tck svn repository to our public repository,  
fix our license and notice files, and build schema releases from  
there. Note that both the schema source directories and the  
resultant schema binaries will have CDDL licensed elements. The  
current guidance that we have received from legal-discuss is that  
both source and binary CDDL is ok for us to release. We will need  
to be sure that our schemas follow all CDDL requirements.


I don't think we should do this until the violent disagreement  
between the 3rd party licensing policy and sam's suggestion that  
it's ok to use the cddl xsds is resolved.


I don't think there's a violent disagreement. I think Sam's opinion  
on the matter carries a lot of weight and also makes a lot of sense.


There was some discussion about whether or not schemas are source or  
binary. Seems we both agree they are source. So, let's assume they  
are source and treat them accordingly.


There is also some discussion about whether xmlbeans or jaxb  
generated code would inherit a CDDL license. This may be debatable.  
Best case the code is ASL. Worst case it's ASL+CDDL or even just  
CDDL. IMO, we can deal just fine with all of those cases. So, let's  
make our best call on the appropriate license for the schema jars.


IMO, we end up in a better situation. In particular, we move our  
schema code out of tck svn -- this seems like a very, very good thing  
to me. Other than the overhead of moving some code, building new  
release candidates, and minor mods to license/notice files, I don't  
see a downside...


--kevan

Re: Splitting up the server into a few more chunks

[Paul McMahan]

On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:

we should consider the more drastic changes, like moving the base  
Admin Console support (via Pluto 1.2) out to /plugins


I really like that idea for a couple of reasons -
-  it allows us to keep the admin console that's currently at server/ 
trunk/applications/console in place until the new extensible admin  
console is ready and can scale up from minimal to full JEE5  
functionality plus debug views, etc.
-  I like the idea of streamlining server/trunk for JEE5 stuff and  
moving the optional stuff  elsewhere


My only reservation (and its no biggie) is that using the location / 
plugins for optional stuff is misleading since there will be stuff in  
server/trunk that's required for JEE5 (i.e. not optional) but  
implemented as plugins like tomcat, jetty, amq, openejb, etc. 
Calling something a plugin is a statement about its packaging and  
deployment mechanism, and not whether it is required or optional.


So maybe "/opt" or some such would be a better place to put the  
extensible admin console, tuscany (eventually), directory server,  
samples, roller, etc...


and start moving the Portlets into the actual modules/configs that  
they administer


I like this idea from a conceptual point of view since it keeps  
things neat and well organized.  But I am not sure how to implement  
it since the main geronimo components are typically packaged in JARs,  
and the admin portlets for a component have to be packaged in a WAR  
(that's just the way that pluto works).  i.e. a JAR can't contain a WAR.


Some options I can think of:
-  use EAR as the packaging format for all geronimo components and  
package the admin WARs inside them
-  maintain geronimo components and their admin WARs separately. bind  
them at deployment time via the plugin installer's dependency  
resolution or by some enhancement to the maven car plugin
-  package the geronimo components as WARs so the admin portlets can  
be merged with them.  (seems like the tail wagging the dog)
-  follow some organizational structure like in your previous email  
where each geronimo component has a module, config, and (now) WAR  
subdirectory


Just brainstorming here...


Best wishes,
Paul

Re: Splitting up the server into a few more chunks

[David Jencks]

On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:


On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:

we should consider the more drastic changes, like moving the base  
Admin Console support (via Pluto 1.2) out to /plugins


I really like that idea for a couple of reasons -
-  it allows us to keep the admin console that's currently at  
server/trunk/applications/console in place until the new extensible  
admin console is ready and can scale up from minimal to full JEE5  
functionality plus debug views, etc.
-  I like the idea of streamlining server/trunk for JEE5 stuff and  
moving the optional stuff  elsewhere


My only reservation (and its no biggie) is that using the location / 
plugins for optional stuff is misleading since there will be stuff  
in server/trunk that's required for JEE5 (i.e. not optional) but  
implemented as plugins like tomcat, jetty, amq, openejb, etc. 
Calling something a plugin is a statement about its packaging and  
deployment mechanism, and not whether it is required or optional.


So maybe "/opt" or some such would be a better place to put the  
extensible admin console, tuscany (eventually), directory server,  
samples, roller, etc...


and start moving the Portlets into the actual modules/configs that  
they administer


I like this idea from a conceptual point of view since it keeps  
things neat and well organized.  But I am not sure how to implement  
it since the main geronimo components are typically packaged in  
JARs, and the admin portlets for a component have to be packaged in  
a WAR (that's just the way that pluto works).  i.e. a JAR can't  
contain a WAR.


Some options I can think of:
-  use EAR as the packaging format for all geronimo components and  
package the admin WARs inside them
-  maintain geronimo components and their admin WARs separately.  
bind them at deployment time via the plugin installer's dependency  
resolution or by some enhancement to the maven car plugin
-  package the geronimo components as WARs so the admin portlets  
can be merged with them.  (seems like the tail wagging the dog)
-  follow some organizational structure like in your previous email  
where each geronimo component has a module, config, and (now) WAR  
subdirectory


Just brainstorming here...


I think we want to use "plugin groups" which IIRC is already  
implemented in some way.  So I see a typical feature (say jetty  
support) as having 3 plugins:


- runtime jetty (geronimo-jetty6 module + jetty car)
- deploy time jetty (geronimo-jetty6-builder + jetty-deployer car)
- admin jetty (war with jetty admin portlets)

To keep it simple I'm purposefully forgetting about wadi clustering  
support.


I think you should be able to install (1), (1 and 3) (1 and 2) or (1  
2 and 3).


thanks
david jencks




Best wishes,
Paul

Re: [VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1

[David Jencks]

After a little more discussion on legal-discuss and considering that  
the legal-discuss discussion is about cddl licensed schemas which are  
not the ones we are using and we are following the same procedure we  
have used before I'm reinstating my +1 vote.


thanks
david jencks

On Aug 4, 2007, at 10:54 AM, David Jencks wrote:

Due to recent discussion on legal-discuss it has become clear to me  
that I don't understand if we can release these or under what  
license, so I'm withdrawing my vote.  This is not a +-0, it is no  
vote.


thanks
david jencks

On Aug 2, 2007, at 11:02 AM, David Jencks wrote:

+1 although I think there are some extraneous -src.jar files that  
could profitably be excluded from upload.


thanks
david jencks

On Aug 1, 2007, at 7:16 PM, Prasad Kashyap wrote:

Hi, Please review and vote on the release of the following  
Geronimo specs:


-- geronimo-schema-j2ee_1.4-1.2
-- geronimo-schema-jee_5-1.1

The corresponding tar files are here:
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz

The current svn locations (restricted access) are here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-j2ee_1.4/branches/1.2/
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-jee_5/branches/1.1/


The future svn locations (restricted access) will be here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-jee_5/tags/geronimo-schema-jee_5-1.1


The vote will conclude at 10:00 PM EST on Saturday, August 4nd.

NOTE: These schemas were built with the help of a
org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is
currently up for vote. The jar for this artifact is located at
http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar
So the schema pom.xml in svn branches have not been updated with  
this

version of the artifact yet, pending it's final vote and release.

Cheers
Prasad

Re: [VOTE] Release specs for JACC, JSP, Servlet

[David Jencks]

After a little more discussion on legal-discuss and considering that  
the legal-discuss discussion is about cddl licensed schemas which are  
not the ones we are using and we are following the same procedure we  
have used before I'm reinstating my +1 vote.


thanks
david jencks

On Aug 4, 2007, at 10:51 AM, David Jencks wrote:

As a result of recent discussion on the legal-discuss list it has  
become clear to me that I don't understand whether or not we are  
allowed to redistribute sun schemas and in what form or under what  
license so I have to withdraw my vote for
http://people.apache.org/~mcconne/geronimo- 
servlet_2.5_spec-1.1.tar.gz

entirely.  This is not a +-0 vote, it is no vote for that spec jar.
I'm still +1 for the other two.

thanks
david jencks


On Aug 2, 2007, at 10:21 AM, David Jencks wrote:


+1

david jencks

On Jul 30, 2007, at 7:04 PM, Tim McConnell wrote:

Hi, Please review and vote on the release of the following  
Geronimo specs:


-- geronimo-jacc_1.1_spec-1.0
-- geronimo-jsp_2.1_spec-1.0
-- geronimo-servlet_2.5_spec-1.1

The corresponding tar files are here:

http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo- 
servlet_2.5_spec-1.1.tar.gz


The current svn locations are here:

https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
servlet_2.5_spec-1.1


The future svn locations will be here:

https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
servlet_2.5_spec-1.1


The vote will conclude at 10:00 PM EST on Thursday, August 2nd.

--
Thanks,
Tim McConnell

Re: Splitting up the server into a few more chunks

[David Blevins]

On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

I certainly agree with your goal but am less sure about your  
proposed naming and organization.  Also from looking at your list  
it took me a couple minutes to figure out what is removed from  
"server"


I've been thinking that we could proceed by turning bits of the  
server into plugins.  For instance I was planning to turn the  
directory bits I commented out recently into a plugin this week.  I  
think we could fairly easiiy turn jetty, tomcat, and openejb into  
plugins.  I wonder if, after turning the "easy stuff" into plugins  
what we will think about reorganizing the remaining stuff.


So then the question might be how to organize the plugins?


Haven't read the rest of the thread yet, but I'd like to backup the  
idea of pulling things out one at a time, like we did with connector  
and transaction, making them plugins if possible.  It would be really  
great if people do things like upgrade OpenEJB when a new release  
came out -- which we're hoping is often.


-David



thanks
david jencks

On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:

Hiya, I've mentioned this before... and now that we have a 2.0  
branch and trunk has moved on to 2.1 work, I think its time we  
really make a decision on this and implement it.


Before, I had been thinking of keeping all of the modules in the  
server/trunk tree just in better locations organized by  
functionality and feature not by artifact type.  But, now I'm  
thinking we should really do one step more than that, and split up  
the server/trunk project into several smaller and more manageable  
chunks of modules.  I still think that the basic grouping that we  
kinda talked about before should work fine, but instead of having  
them share a project namespace we give them their own.


So, for example...

server-support/trunk
testsupport
buildsupport

server-framework/trunk
geronimo-activation
geronimo-client
geronimo-client-builder
geronimo-clustering
geronimo-common
geronimo-connector
geronimo-connector-builder
geronimo-core
geronimo-deploy-config
geronimo-deploy-jsr88
geronimo-deploy-jsr88-bootstrapper
geronimo-deploy-tool
geronimo-deployment
geronimo-gbean-deployer
geronimo-interceptor
geronimo-j2ee
geronimo-j2ee-builder
geronimo-j2ee-schema
geronimo-jmx-remoting
geronimo-kernel
geronimo-management
geronimo-naming
geronimo-naming-builder
geronimo-security
geronimo-security-builder
geronimo-service-builder
geronimo-system
geronimo-test-ddbean
geronimo-timer
geronimo-transaction
geronimo-transaction-jta11
geronimo-transformer
geronimo-util
geronimo-web-2.5-builder

And then we can group some of the related components up into  
shared projects, or just go out and give each component its own  
project, and/or think about maybe using the same style that the  
maven/plugins/trunk tree uses, a shared project, but each  
component is related individually... still not sure I like that,  
kinda messy.


I don't want to end up with a ton of projects either, and I  
certainly don't want to get up using SNAPSHOT versions of these  
puppies if we can help it.  So, maybe to start out we could do these:


server-support
server-framework
server-components
server-assembly

BTW, I'm using "dash" here so that the names don't collide with  
what is there now, but really we could user server/support/trunk,  
server/framework/trunk, etc (which is better IMO for the longer run).


And in the process of making this split up, we can re-arrange  
modules by feature and function instead of by type... and actually  
we have to do that to make the components bits work.


 * * *

I really believe this will help improve the support and  
maintainability of the server's code-base and it will help the  
project scale better as new components are added too.  For  
developers that are only interested in working on a specific  
component, it reduces the amount of other sources they need to  
check out and reduces the time to build too, so that they can  
build a clean server assembly faster and developer their features  
sooner and hopefully have less hair-pulling and more relaxed beer  
drinking as they pat themselves on the back for doing such a  
speedy job.


I really, really... really, really, really ( :-P ) think that we  
*must* move along these lines for the longer term health of the  
project...


Comments?  Suggestions?

--jason

Re: 2.0 release status

[Anita Kulshreshtha]

--- Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:

> This is crude!!  First I ran the build on
> modules\geronimo-j2ee-builder with
> IBMJDK1.5.0 with tests turned off to be able to build the module. 
> Then I
> ran the build (not a clean build) with SunJDK1.5.0 with tests on and
> the
> tests passed!!
> 
> --vamsi
> 
...
> > When I build modules\geronimo-j2ee-builder, I get a build failure
> with
> > XmlBeans compile failed.  

I recently ran into a similar problem. In my case I ran "mvn clean"
on modules, which downloaded the latest xmlbeans plugin but it did not
update its dependencies!!! One could say it does not need them to
perform clean operation. Later when j2ee-builder was being built, I got
the error you mentioned. I deleted xmlbeans plugin from .m2 repo and
built using "mvn" from geronoimo-j2ee-builder (or modules) directory.
This time the plugin and all its dependencies were downloaded and the
build was successful. 
So if a plugin is downloaded/updated during mvn clean, its
dependencies may not be the latest. It's a maven thing...

Thanks
Anita

 


  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

Test case failure

[Duminda Ekanayake]

Hi,
   I just checkout gerenimo and start building , but seems to be the
building is failed at org.apache.geronimo.security.jaas.LoginKerberosTest.
since the test is failed.Any updates on this?

Regrads!
Duminda

-- 
Hasta la victoria siempè!

[jira] Closed: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3368.
---


Closing as it has been resolved and committed.

> Axis2ClientConfigurationFactory not always being used in certain platforms
> --
>
> Key: GERONIMO-3368
> URL: https://issues.apache.org/jira/browse/GERONIMO-3368
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0
>Reporter: Lin Sun
>Assignee: Jarek Gawor
> Fix For: 2.0
>
> Attachments: G-3368.patch
>
>
> On Windows 2003 & Linux, GBean TomcatWebAppContext will be started before 
> Axis2ConfigGBean. Class 
> org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
> when the geronimo kernel starts TomcatWebAppContext, look at the following 
> codes in DescriptionFactoryImpl:
> private static ClientConfigurationFactory clientConfigFactory = 
> ClientConfigurationFactory.newInstance();
> This will make class DescriptionFactoryImpl can not load 
> Axis2ClientConfigurationFactory which is registered into 
> MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
> use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.
> On Windows XP, GBean TomcatWebAppContext will be started after 
> Axis2ConfigGBean so the client configurationcontext is working as expected.
> GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's 
> not mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The 
> patch will set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3365) config.xml condition vs. load attribute issues

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3365.
---

Assignee: Jarek Gawor

Closing as it has been resolved and committed.

> config.xml condition vs. load attribute issues
> --
>
> Key: GERONIMO-3365
> URL: https://issues.apache.org/jira/browse/GERONIMO-3365
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M7
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
>Priority: Critical
> Fix For: 2.0
>
>
> The initial config.xml contains the following condition:
>  name="org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car">
> But after the server is started and stopped for the first time this entry is 
> rewritten as:
>  name="org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car">
> The 'load' attribute is added which invalidates the specified condition.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3352) Upgrade to Jetty 6.1.5 (just released) for Geronimo 2.0

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3352.
---


Closing as it has been resolved and committed.

> Upgrade to Jetty 6.1.5 (just released) for Geronimo 2.0
> ---
>
> Key: GERONIMO-3352
> URL: https://issues.apache.org/jira/browse/GERONIMO-3352
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.0
>Reporter: Joe Bohn
>Assignee: Joe Bohn
> Fix For: 2.0
>
>
> There are some problems that are fixed in Jetty 6.1.5 that are needed for 
> Geronimo and we need a stable release for our Geronimo 2.0 release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3332) POJO Web-services under Geronimo fail with arrays as method call arguments

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3332.
---


Closing as the problem could not be recreated.

> POJO Web-services under Geronimo fail with arrays as method call arguments
> --
>
> Key: GERONIMO-3332
> URL: https://issues.apache.org/jira/browse/GERONIMO-3332
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0-M6
> Environment: Windows XP Pro SP2, Sun JSDK 1.5._07, 
> geronimo-tomcat6-jee5-2.0-M6-rc1
>Reporter: Alexei Kozich
>Assignee: Jarek Gawor
> Fix For: 2.0
>
>
> We created POJO web sevice like following:
> @WebService
> @SOAPBinding(style = Style.RPC, use = Use.LITERAL)
> public interface PartInventoryWs {
> @WebMethod
>   public Integer completeReplenishOrders(
>   @WebParam(name = "orderIds")
>   List orderIds);
> }
> in web.xml we defined servlet mapping in order to call this web-service like 
> following:
> 
>   PartInventoryWs
>   /partinventory
> 
> 
>   PartInventoryWs
>   
> democrm.webservice.shop.PartInventoryWsImpl
> 
> So everything is deployed fine and we can access wsdl document by opening 
> URL: http://localhost:8080/.../partinventory?wsdl.
> But this webservice fails when I try to invoke method and pass to it array of 
> Strings (I generated client classes by 
>  the Apache Axis 1.3 Oct 05, 2005 (05:23:37 EDT) WSDL2Java emitter) :
> (see string "HTTP/1.1 500 Internal Server Error" in the below debug log).
> <2007-07-18 14:53:16,812>  
>  
> org.apache.axis.i18n.resource::handleGetObject(engineFactory)
> <2007-07-18 14:53:16,812>  
>  Got 
> EngineFactory: org.apache.axis.configuration.EngineConfigurationFactoryDefault
> <2007-07-18 14:53:16,812>   Enter: 
> AxisEngine::init
> <2007-07-18 14:53:17,031>   Exit: 
> AxisEngine::init
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(transport00)
> <2007-07-18 14:53:17,031>   Transport is 
> [EMAIL PROTECTED]
> <2007-07-18 14:53:17,031>   Enter: 
> Call::invoke(ns, meth, args)
> <2007-07-18 14:53:17,031>   
> operation=name:completeReplenishOrders
> returnQName: null
> returnType:  {http://xml.apache.org/axis/}Void
> returnClass: null
> elementQName:null
> soapAction:  null
> style:   rpc
> use: literal
> numInParams: 1
> method:null
>  ParameterDesc[0]:
>   name:   orderIds
>   typeEntry:  null
>   mode:   IN
>   position:   0
>   isReturn:   false
>   typeQName:  {http://jaxb.dev.java.net/array}stringArray
>   javaType:   class [Ljava.lang.String;
>   inHeader:   false
>   outHeader:  false
> <2007-07-18 14:53:17,031>   
> operation.getNumParams()=1
> <2007-07-18 14:53:17,031>   getParamList 
> number of params: 1
> <2007-07-18 14:53:17,031>   Enter: 
> Call::invoke(RPCElement)
> <2007-07-18 14:53:17,031>   Enter: SOAPPart 
> ctor(FORM_SOAPENVELOPE)
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
> <2007-07-18 14:53:17,031>   Setting current 
> message form to: FORM_SOAPENVELOPE (currentMessage is now 
> org.apache.axis.message.SOAPEnvelope)
> <2007-07-18 14:53:17,031>   Exit: SOAPPart 
> ctor()
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(addBody00)
> <2007-07-18 14:53:17,031>   Adding 
> body element to message...
> <2007-07-18 14:53:17,031>   Enter: 
> Call::invoke()
> <2007-07-18 14:53:17,031>   
> MessageContext: setTargetService(PartInventoryWsImplPort)
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(noService10)
> <2007-07-18 14:53:17,031>   Enter: 
> SOAPPart::getAsSOAPEnvelope()
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(currForm)
> <2007-07-18 14:53:17,031>   current form is 
> FORM_SOAPENVELOPE
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(register00)
> <2007-07-18 14:53:17,031>  
>  register 'soapenv' - 
> 'http://schemas.xmlsoap.org/soap/envelope/'
> <2007-07-18 14:53:17,031>   NSPush (32)
> <2007-07-18 14:53:17,031>   NSPush (32)
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(register00)
> <2007-07-18 14:53:17,031>  
>  register 'soapenv' - 
> 'http://schemas.xmlsoap.org/soap/envelope/'
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(register00)
> <2007-07-18 14:53:17,031>  
>  register 'xsd' - 
> 'http://www.w3.org/2001/XMLSchema'
> <2007-07-18 14:53:17,031>   NSPush (32)
> <2007-07-18 14:53:17,031>  
>  
> org.apache.axis.i18n.resource::handleGetObject(register00)
> <2007-07-18 14:53:17,031>  
>  register 'xsi' 

[jira] Closed: (GERONIMO-3196) ConcurrentModificationException in ?wsdl processing

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3196.
---


Closing per Jarek's comments.

> ConcurrentModificationException in ?wsdl processing
> ---
>
> Key: GERONIMO-3196
> URL: https://issues.apache.org/jira/browse/GERONIMO-3196
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0
>
>
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
> at java.util.HashMap$EntryIterator.next(HashMap.java:883)
> at java.util.HashMap$EntryIterator.next(HashMap.java:881)
> at 
> org.apache.geronimo.cxf.GeronimoQueryHandler.updatePorts(GeronimoQueryHandler.java:93)
> at 
> org.apache.geronimo.cxf.GeronimoQueryHandler.updateServices(GeronimoQueryHandler.java:73)
> at 
> org.apache.geronimo.cxf.GeronimoQueryHandler.updateDefinition(GeronimoQueryHandler.java:55)
> at 
> org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:130)
> at 
> org.apache.geronimo.cxf.CXFWebServiceContainer.getWsdl(CXFWebServiceContainer.java:118)
> at 
> org.apache.geronimo.webservices.WebServiceContainerInvoker.service(WebServiceContainerInvoker.java:74)
> at 
> org.apache.geronimo.webservices.POJOWebServiceServlet.service(POJOWebServiceServlet.java:79)
> at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098)
> at 
> com.sun.ts.tests.jaxws.wsi.w2j.document.literal.swatest.CheckHttpMimeHeadersFilter.doFilter(CheckHttpMimeHeadersFilter.java:68)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at 
> org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46)
> at 
> org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58)
> at 
> org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at 
> org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:510)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
> at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at 
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3305) Out Of Memory Error when Running DayTrader in WebServices Mode

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3305.
---


Close pending Jarek's comments and changes.

> Out Of Memory Error when Running DayTrader in WebServices Mode
> --
>
> Key: GERONIMO-3305
> URL: https://issues.apache.org/jira/browse/GERONIMO-3305
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M7
> Environment: All
>Reporter: Matt Hogstrom
>Assignee: Jarek Gawor
> Fix For: 2.0
>
>
> I deployed DayTrader 2.0 on the latest SVN rev 554753 of trunk.
> I deploy daytrader-ear-2.0-SNAPSHOT.ear (using the 
> daytrader-g-2.0-SNAPSHOT-plan.xml in ${DT}/trunk/plans
> Create the tables and populate them in the config section.
> Switch to WebServices mode
> Log in and do portfolio, quotes, buy and sell a few stocks and then logoff.
> Try to log in again and I get:
> 10:34:34,089 ERROR [Log] Error: JSR 109 lookup failed .. defaulting to JSR 101
> javax.naming.NamingException: Could not look up : service/Trade [Root 
> exception is net.sf.cglib.core.CodeGenerationException: 
> java.lang.reflect.InvocationTargetException-->null]
> javax.naming.NamingException: Could not look up : service/Trade [Root 
> exception is net.sf.cglib.core.CodeGenerationException: 
> java.lang.reflect.InvocationTargetException-->null]
> at 
> org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:65)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at 
> org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getPortFromFactory(TradeWebSoapProxy.java:67)
> at 
> org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getTrade(TradeWebSoapProxy.java:47)
> at 
> org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getAccountData(TradeWebSoapProxy.java:122)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeServletAction.doHome(TradeServletAction.java:277)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(TradeServletAction.java:372)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:126)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAppServlet.java:91)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Pro

[jira] Closed: (GERONIMO-3353) Adjust server log4j files to use a default logging level of error instead of info before releasing.

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3353.
---

Resolution: Fixed

Changed default to:

Committed revision 563399.

> Adjust server log4j files to use a default logging level of error instead of 
> info before releasing.
> ---
>
> Key: GERONIMO-3353
> URL: https://issues.apache.org/jira/browse/GERONIMO-3353
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Reporter: Matt Hogstrom
>Assignee: Matt Hogstrom
> Fix For: 2.0
>
>
> The title says it all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-2581) Update Version Numbers of Dependent Projects for Geronimo Version 2.0

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-2581.
---

Resolution: Fixed

Version changes complete for 2.0.

> Update Version Numbers of Dependent Projects for Geronimo Version 2.0
> -
>
> Key: GERONIMO-2581
> URL: https://issues.apache.org/jira/browse/GERONIMO-2581
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M5
> Environment: All
>Reporter: Matt Hogstrom
>Assignee: Matt Hogstrom
> Fix For: 2.0
>
>
> This is a master record for dependent JIRAs for updating various version 
> numbers of supporting project of o.a.g.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-1567) Plan XML files aren't included in Geronimo distributions (was included in M5 release)

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom updated GERONIMO-1567:


Fix Version/s: (was: 2.0)
   2.0.x

Moving to 2.0.x

> Plan XML files aren't included in Geronimo distributions (was included in M5 
> release)
> -
>
> Key: GERONIMO-1567
> URL: https://issues.apache.org/jira/browse/GERONIMO-1567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 1.0
>Reporter: John Sisson
>Assignee: Jason Dillon
> Fix For: 2.0.x
>
>
> It was a combination of an oversight and the idea that being able to add 
> gbeans using config.xml could replace the need to modify and redeploy the 
> plans we supply.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-807) Better handling for system log viewer portlet render requests

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-807.
--

Resolution: Fixed

Applied patch and tested and it works.  The text for criteria is still wiped 
out when navigating to different portlets.  Given the longevity of this issue 
I'm going to close it and open a separate issue to be tracked independently.

Thanks Rakesh!

> Better handling for system log viewer portlet render requests
> -
>
> Key: GERONIMO-807
> URL: https://issues.apache.org/jira/browse/GERONIMO-807
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, usability
>Affects Versions: 1.0-M5
>Reporter: Aaron Mulder
>Assignee: Rakesh Midha
>Priority: Minor
> Fix For: 2.0
>
> Attachments: jira807.patch
>
>
> If you interact with a different portal on the log page, the system log 
> viewer portlet reverts to its default filter settings.  It should instead 
> default to the same values used previously (if there are previous search 
> criteria and if none of the criteria were submitted in the request). See 
> LogViewerPortlet.java:73 or so

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-2025) Undeploy and redeploy with no version leaves dangling entries in config.xml

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom updated GERONIMO-2025:


Fix Version/s: (was: 2.0)
   2.0.x

Moving to 2.0.x

> Undeploy and redeploy with no version leaves dangling entries in config.xml
> ---
>
> Key: GERONIMO-2025
> URL: https://issues.apache.org/jira/browse/GERONIMO-2025
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, kernel
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: Rakesh Midha
> Fix For: 2.0.x
>
> Attachments: removeunwantedconfig.patch
>
>
> If you deploy an application with no version and then undeploy it, we leave 
> an entry for it (with a timestamp version number) in config.xml, just marked 
> as load=false.
> If you later deploy the application again, you get a new timestamp version 
> number and a new entry is written into config.xml.  Do this (undeploy/deploy) 
> a few times and config.xml gets kind of messy.
> It would be be good to delete entries from config.xml on undeploy if they 
> have no actual settings.
> It would be good to detect that a previous version is in conifg.xml but not 
> in the repository and delete the settings from config.xml if the artifact has 
> no version number and a newer copy is deployed.
> This is not a huge priority since nothing breaks, it just makes config.xml 
> kind of crufty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom updated GERONIMO-1907:


Fix Version/s: (was: 1.x)
   (was: 2.0)
   2.0.x

Moving to 2.0.x 

> Deploy command should redeploy if the app is already deployed
> -
>
> Key: GERONIMO-1907
> URL: https://issues.apache.org/jira/browse/GERONIMO-1907
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment, usability
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: Rakesh Midha
>Priority: Critical
> Fix For: 2.0.x
>
> Attachments: redeploy.patch
>
>
> Attached patch, and changing fix version to 1.2. Also unassigning so that 
> committers can review and update.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3382) InvalidConfigurationException is thrown when starting the plugins from the console

[Song (JIRA)]

 InvalidConfigurationException is thrown when starting the plugins from the 
console
---

 Key: GERONIMO-3382
 URL: https://issues.apache.org/jira/browse/GERONIMO-3382
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Plugins
Affects Versions: 2.0-M5
 Environment: Windows xp x86-32
Reporter: Song


After successfully installed plugins provided by Geronimo, start the plugin 
just installed, "InvalidConfigurationException
" exception is thrown from server 
  
  The below steps can reproduce the error:
  1) Login to admin console,click on "Plugins" in the left navigation bar.
  2) Click on "Update Repository List" link in  Create and Install Plugins 
portlet, and select
"http://geronimo.apache.org/plugins/geronimo-2.0/"; in "Repository" field.
  3) Click on "Search for Plugins" button.
  4) Click on "Jakarta JSP Examples (Tomcat) (2.0-SNAPSHOT)" link,click on 
"Continue" button,click
on "Install Plugin" button.
  5) Click on "Start 
org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car" button.
   
   NO response at the current page, but from the server started console, the 
below error is thrown:
 ---
14:18:58,796 WARN  [ConfigurationUtil] Could not load gbean 
org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car
org.apache.geronimo.gbean.InvalidConfigurationException: Getter method not 
found Attribute Name: URLFor, Type: class java.net.URL, GBeanInstance: Tomcat 
WebApplication Context
at 
org.apache.geronimo.gbean.runtime.GBeanAttribute.(GBeanAttribute.java:252)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.(GBeanInstance.java:245)
at 
org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:354)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:433)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$3a7a5946.startConfiguration()
at 
org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:76)
at 
org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:116)
at 
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
at 
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
at 
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.po

[jira] Updated: (GERONIMO-2884) JNDI Name Not Correct

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom updated GERONIMO-2884:


Fix Version/s: (was: 2.0)
   2.0.x

> JNDI Name Not Correct
> -
>
> Key: GERONIMO-2884
> URL: https://issues.apache.org/jira/browse/GERONIMO-2884
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
> Environment: Linux
>Reporter: Tom Purcell
>Assignee: David Blevins
> Fix For: 2.0.x
>
>
> I was asked to open this issue by David Blevins following this Nabble 
> exchange: http://www.nabble.com/InitialContext-JNDI-Lookup-tf3273209s2756.html
> The issue is that the JNDI entry under which an ejb's remote business 
> interface is registered is constructed as:
> deploymentId/BussinessRemote
> instead of
> /BussinessRemote
> this results in an entry that looks like this:
> geronimo-deploymentUtil5840.tmpdir/ConferenceCallSchedulerBeanBusinessRemote
> The main problem with this is that the number part of the deployment id (5840 
> in the above) will be different on each redeploy making it difficult for a 
> client app to find.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3351) Plugin installer downloads a different version of dependecy than the one specified

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-3351:
--

Affects Version/s: 2.1
   2.0.x
Fix Version/s: (was: 2.0)
   2.1
   2.0.x

> Plugin installer downloads a different version of dependecy than the one 
> specified
> --
>
> Key: GERONIMO-3351
> URL: https://issues.apache.org/jira/browse/GERONIMO-3351
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0, 2.0.x, 2.1
> Environment: G 2.0 Tomcat (should be applicable to G 2.0 Jetty as 
> well)
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: 2.0.x, 2.1
>
>
> Plugin installer downloads a different version of dependecy than the one 
> specified.  A scenario below:
> I am trying to install a plugin which has a dependency on 
> "commonj/sdo-api-r2.1/1.0-incubating-SNAPSHOT/jar".  During the stage at 
> which the depedency jar are downloaded, I see the following:
> Searching for commonj/sdo- api-r2.1/1.0-incubating-SNAPSHOT/jar at 
> http://people.apache.org/repo/m2-incubating-repository
> Downloading commonj/sdo-api-r2.1/1.0-incubating-beta1/jar...
> Notice that the version it is supposed to download (this is the same version 
> specified in geronimo-plugin.xml) and the one it is actually downloading are 
> different.
> The plugin is failing to start and is throwing an exception with "reason: 
> Unable to resolve dependency commonj/sdo- 
> api-r2.1/1.0-incubating-SNAPSHOT/jar".
> A discussion thread on dev-list is at 
> http://www.mail-archive.com/dev@geronimo.apache.org/msg48842.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3059) CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom closed GERONIMO-3059.
---

Resolution: Fixed

Looks like this has been fixed.

> CLIs refactoring - options and arguments parsing should be done prior the 
> boot of a Kernel to provide a quicker feedback to users if they are invalid
> -
>
> Key: GERONIMO-3059
> URL: https://issues.apache.org/jira/browse/GERONIMO-3059
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: usability
>Affects Versions: 2.0-M4
>Reporter: Gianny Damour
>Assignee: Gianny Damour
> Fix For: 2.0
>
> Attachments: GERONIMO-3059.patch
>
>
> CLIs options and arguments are parsed after the boot of a Kernel. As the boot 
> of a Kernel, and especially the loading of configurations, are time 
> expensive, users have to wait an unacceptable time to receive a feedback from 
> CLs if these options or arguments are invalid.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3089) geronimo-activemq-ra's ra.xml is missing several config-property elements

[Matt Hogstrom (JIRA)]

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

Matt Hogstrom updated GERONIMO-3089:


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

Good candidate for a 2.0.1.

> geronimo-activemq-ra's ra.xml is missing several config-property elements
> -
>
> Key: GERONIMO-3089
> URL: https://issues.apache.org/jira/browse/GERONIMO-3089
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 2.0.x
>
>
> Several configuration properties which are listed ( 
> http://activemq.apache.org/resource-adapter-properties.html ) are not 
> actually configurable in the normal J2EE/JavaEE ra way as the ra.xml is 
> missing config-property elements to define them as configurable.
> Specifically these documented properties are missing:
>  * AllPrefetchValues
>  * DurableTopicPrefetch
>  * QueuePrefetch
>  * InputStreamPrefetch
>  * TopicPrefetch
>  * InitialRedeliveryDelay
>  * MaximumRedeliveries
>  * RedeliveryBackOffMultiplier
>  * RedeliveryUseExponentialBackOff
> Should also double check the org.apache.activemq.ra.ActiveMQResourceAdapter 
> class for any other properties which may be missing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.