Re: Division of responsibilities for annotations to xml and jndi entries

[Tim McConnell]

Hi David, Just a few comments to consider:

-- This interface you mentioned is now complete and attached as a patch to 
GERONIMO-2870. The interface basically allows multiple application types (e.g., 
WebAppType, ApplicaitonClient, etc...) to reuse the same XmlBeans code that 
exists in the AnnotationHelper classes. This will facilitate adding support for 
more than just the Web apps that we're currently supporting for annotations (via 
AbstractWebModuleBuilder).


-- I believe there is a problem with the additional classloader added to support 
remote/local EJB's--it does seem to work but gets a "java.lang.Exception" 
exception in ClassFinder that is likely contributing to and exacerbating the 
longer delays when deploying EJBs.


-- The notion I currently have of the AnnotationHelper classes is to encapsulate 
as much of the annotation processing as possible and isolate that underlying 
function(s) from the consumers of those classes. If that is still the case, I 
believe that they can be invoked elsewhere (i.e., in the NamingBuilders as you 
suggest) without much adverse impact. If the functions that they provide need to 
change though we may want to rethink/revisit what it is that I'm encapsulating.


-- Finally, before we move the annotation processing to the naming builders it 
might be useful to step back a little and articulate the 5-10 most critical 
usage scenarios that we need to support for annotations. That might help with 
the proper placement of the annotation support and uncover the information/data 
required to support these usage scenarios. I know this would help me as I've 
currently only been considering the most obvious mechanical translation 
scenarios, which as suggest may not be sufficient. I shall come up with a short 
list of scenarios first thing tomorrow for review.


Thanks,
Tim McConnell


David Jencks wrote:
While working on injections for jetty I ran into a problem with ejb 
annotations not indicating whether they are local or remote.  I solved 
it with a rather brute force attack of just building an additional 
ClassFinder and looking for all the ejbs.  This is really unpleasant 
because openejb has to do the same work all over again.  After talking 
with David Blevins on IRC for a bit to try to understand the problem 
better I've come to the conclusion that our current division of 
responsibility between the annotation stuff Tim's been working on and 
the NamingBuilders is not very good.  Actually figuring out what xml is 
the accurate representation of an annotation requires deep understanding 
of the meaning of the annotation, not just a mechanical translation.  As 
such it should be done by the NamingBuilder that is part of the 
implementation of the system we are referring to.


This means that the NamingBuilders need more information that just the 
xml from the spec dd.  They also need information about the annotations 
involved and they need to be the code that modifies the spec dd.


IIUC Tim is working on providing an interface that provides for updating 
spec dds with additional refs.  I think that this can be used by 
NamingBuilders to add whatever xml they come up with.  I expect a lot of 
the code in EjbAnnotationHelper and ResourceAnnotationHelper is going to 
need to move to NamingBuilders.


So, I've concluded that the information in the annotations need to be 
supplied to the NamingBuilders in some form, but I don't have a clear 
idea yet about exactly what form.  I think that something like a map 
from annotation to Member might be adequate.  It might be better so 
extract the info into something more like the xml info, or it might be 
better to pass in the classes with annotations, or something else.


I expect to be thinking about this over the next day or two and comments 
and ideas are more than welcome.


thanks
david jencks

[jira] Updated: (GERONIMO-2870) AnnotationHelper classes not yet supported for all application types

[Tim McConnell (JIRA)]

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

Tim McConnell updated GERONIMO-2870:


Attachment: GERONIMO-2870.patch

Interface added for the AnnotationHelper classes so that the same XmlBeans code 
can be used for multiple application types--not just WebAppType. 

> AnnotationHelper classes not yet supported for all application types
> 
>
> Key: GERONIMO-2870
> URL: https://issues.apache.org/jira/browse/GERONIMO-2870
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
> Attachments: GERONIMO-2870.patch
>
>


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

Getting "java.lang.IllegalStateException: component is not owner" Exception

[Keertikar]

Hi All,

I've written a simple application for publishing a message on the Service
Bus and retrieving the same.
This is working fine and i'm able to receive the message in a proper way but
an exception occurrs on ServiceMix console, (ERROR [CBRComponent] Error
processing exchange InOut[)as follows:

java.lang.IllegalStateException: component is not owner
at
org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setMessage(MessageExchangeImpl.java:297)
at
com.globallogic.chrysalis.esb.component.cbr.endpoint.ContentBasedRouter.sendResponse(ContentBasedRouter.java:231)
at
com.globallogic.chrysalis.esb.component.cbr.endpoint.ContentBasedRouter.process(ContentBasedRouter.java:124)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:431)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:624)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:169)
at
org.apache.servicemix.jbi.nmr.flow.jms.JMSFlow.access$301(JMSFlow.java:73)
at
org.apache.servicemix.jbi.nmr.flow.jms.JMSFlow$5.run(JMSFlow.java:534)
at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:595)

All suggestion are welcome.

Keertikar
-- 
View this message in context: 
http://www.nabble.com/Getting-%22java.lang.IllegalStateException%3A-component-is-not-owner%22-Exception-tf3298389s12049.html#a9175449
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

[jira] Updated: (GERONIMO-2870) AnnotationHelper classes not yet supported for all application types

[Tim McConnell (JIRA)]

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

Tim McConnell updated GERONIMO-2870:


Summary: AnnotationHelper classes not yet supported for all application 
types  (was: AnnotationHelper classes not using XmlObjects)

> AnnotationHelper classes not yet supported for all application types
> 
>
> Key: GERONIMO-2870
> URL: https://issues.apache.org/jira/browse/GERONIMO-2870
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
>


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

Re: M3 Build Error: Axis2 tests

[Lasantha Ranaweera]

This problem was fixed with GERONIMO-2888.

Lasantha
Lin Sun wrote:
Worked for me with the latest trunk and some local modification about 
to be attached as a patch (tho I don't think the modification made a 
difference).


---
 T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.578 sec
Running org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.563 sec

Results :
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0

Lin
Davanum Srinivas wrote:

Can you please post the surefire logs?

thanks,
dims

On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:


---
 T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 
0.081 sec

<<< FAILURE!
Running
org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
0.242 sec

<<< FAILURE!

Results :
Tests run: 8, Failures: 0, Errors: 6, Skipped: 0

[INFO]
 


[ERROR] BUILD FAILURE
[INFO]
 


[INFO] There are test failures.
[INFO]
 


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


[INFO] Total time: 6 minutes 42 seconds
[INFO] Finished at: Mon Feb 26 08:16:02 EST 2007
[INFO] Final Memory: 87M/508M
[INFO]
 



-sachin

Re: WebXmlParser WARN on startup

[Paul McMahan]

On 2/26/07, Jason Dillon <[EMAIL PROTECTED]> wrote:

By squelched you mean adding an entry in server-log4j.properties to
limit the level of WebXmlParser to ERROR or something?


yes


I really don't like having to add these... as it cuts of stuff from
making it into the log file.

If we limit the console to ERROR by default, then I think this one is
okay to just remain asis... or unless its meaningless, then hopefully
the MyFaces folks can fix this.


I agree with you but didn't realize limiting the console to ERROR
might be considered OK.  I like that approach much better, regardless
of whether or not this particular WARNING is actually legit.

Best wishes,
Paul


On Feb 26, 2007, at 7:51 PM, Paul McMahan wrote:

> That message is emitted by MyFaces when it processes the admin
> console's web.xml.  I need to take a look to see if it indicates a
> real problem or if it can be squelched.
>
> Best wishes,
> Paul
>
> On 2/26/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
>> Anyone what whats up with this WARN from WebXmlParser on startup?
>>
>> 
>> WARN  [WebXmlParser] Ignored element 'dispatcher' as child of
>> 'filter-
>> mapping'.
>> 
>>
>> This shows up with Jetty and Tomcat assemblies...
>>
>> --jason
>>

Re: WebXmlParser WARN on startup

[Jason Dillon]

By squelched you mean adding an entry in server-log4j.properties to  
limit the level of WebXmlParser to ERROR or something?


I really don't like having to add these... as it cuts of stuff from  
making it into the log file.


If we limit the console to ERROR by default, then I think this one is  
okay to just remain asis... or unless its meaningless, then hopefully  
the MyFaces folks can fix this.


--jason


On Feb 26, 2007, at 7:51 PM, Paul McMahan wrote:


That message is emitted by MyFaces when it processes the admin
console's web.xml.  I need to take a look to see if it indicates a
real problem or if it can be squelched.

Best wishes,
Paul

On 2/26/07, Jason Dillon <[EMAIL PROTECTED]> wrote:

Anyone what whats up with this WARN from WebXmlParser on startup?


WARN  [WebXmlParser] Ignored element 'dispatcher' as child of  
'filter-

mapping'.


This shows up with Jetty and Tomcat assemblies...

--jason

Re: WebXmlParser WARN on startup

[Paul McMahan]

That message is emitted by MyFaces when it processes the admin
console's web.xml.  I need to take a look to see if it indicates a
real problem or if it can be squelched.

Best wishes,
Paul

On 2/26/07, Jason Dillon <[EMAIL PROTECTED]> wrote:

Anyone what whats up with this WARN from WebXmlParser on startup?


WARN  [WebXmlParser] Ignored element 'dispatcher' as child of 'filter-
mapping'.


This shows up with Jetty and Tomcat assemblies...

--jason

[jira] Commented: (GERONIMO-2741) Info messages are being displayed in the console output

[Jason Dillon (JIRA)]

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

Jason Dillon commented on GERONIMO-2741:


Appears there are some other logging related issues that need to be resolve in 
addition to applying this patch to fix things... pending some responses on 
questions sent to the dev list to resolve.

> Info messages are being displayed in the console output
> ---
>
> Key: GERONIMO-2741
> URL: https://issues.apache.org/jira/browse/GERONIMO-2741
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Logging
>Affects Versions: 2.0-M1, 2.0-M2
> Environment: 2.0 trunk Rev496565
>Reporter: Donald Woods
> Assigned To: Jason Dillon
>Priority: Minor
> Fix For: 2.0-M2
>
> Attachments: G2741.patch
>
>
> The default logging level for the console (system.out) logging is INFO.
> This should be changed to default WARN to remove msgs such as -
> 16:18:44,875 INFO  [root] --
> 16:18:44,875 INFO  [root] Started Logging Service
> 16:18:44,875 INFO  [root] Runtime Information:
> 16:18:44,875 INFO  [root]   Install Directory = 
> E:\geronimo-tomcat6-jee5-2.0-SNAPSHOT
> 16:18:44,875 INFO  [root]   JVM in use = IBM Corporation Java 1.5.0
> 16:18:44,875 INFO  [root] Java Information:
> . . .
> 15:56:21,156 INFO  [DWRServlet] retrieved system configuration file: [EMAIL 
> PROTECTED]

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

mx4j logging init

[Jason Dillon]

Anyone know if we can replace these bits in GeronimoLogging.initialize()


try {
Class clazz = Class.forName("mx4j.log.Log");
Class paramClazz = Class.forName("mx4j.log.Logger");
Method method = clazz.getDeclaredMethod("redirectTo", new Class 
[] {paramClazz});

paramClazz = Class.forName("mx4j.log.CommonsLogger");
method.invoke(null, new Object[] {paramClazz.newInstance()});
} catch (ClassNotFoundException e) {
// MX4J is not present.
} catch (Exception e) {
throw (AssertionError) new AssertionError("Cannot force MX4J to  
use commons logging.").initCause(e);

}


With:


System.setProperty("mx4j.log.prototype", "mx4j.log.CommonsLogger");


--jason

Logging to STDERR via org.mortbay.log.StdErrLog

[Jason Dillon]

Why is Jetty configured to anything that logs to STDERR?

This is causing some nasty looking messages...


[WARNING] 2007-02-26 18:53:41.088::INFO:  Logging to STDERR via  
org.mortbay.log.StdErrLog

[WARNING] 2007-02-26 18:53:41.103::INFO:  jetty-6.1.x
[WARNING] 2007-02-26 18:53:41.227::INFO:  Started SocketConnector @  
0.0.0.0:8080
[WARNING] 2007-02-26 18:53:41.453::INFO:  Started GeronimoSSLListener  
@ 0.0.0.0:8443



Why is Jetty not configured to a JCL or Log4j bridge?

--jason

WebXmlParser WARN on startup

[Jason Dillon]

Anyone what whats up with this WARN from WebXmlParser on startup?


WARN  [WebXmlParser] Ignored element 'dispatcher' as child of 'filter- 
mapping'.



This shows up with Jetty and Tomcat assemblies...

--jason

RecoveryController ERROR messages on startup

[Jason Dillon]

Anyone know what these mean?  And why the show up when booting up  
Geronimo?



ERROR [RecoveryController] javax.transaction.xa.XAException: No  
current connection.

...
ERROR [RecoveryController] javax.transaction.xa.XAException: The  
connection is already closed



--jason

Re: [RESULT] VOTE J2G Conversion tool acceptance

[Filip Hanik - Dev Lists]

cool, sorry to bug, but is there anything more you need from us?

Filip

Davanum Srinivas wrote:

Checked in.

thanks,
dims

On 2/26/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

dims,
I've updated some info in the IP clearance form, attached is the 
patch file.

The JIRA has also been updated with the codebase that reflects the ASF
license in the source header, and the IBM copyright in the COPYRIGHT.txt
file
Both Covalent and IBM CCLA are also attached to the JIRA item.

Is there anything left from us, or is the rest left up to the 
Geronimo PMC?


Filip

Bootstrap logging init...

[Jason Dillon]

Is there any reason why this is done:


GeronimoLogging.initialize(verboseArg == null || verboseArg.equals 
(ARGUMENT_VERBOSE) ? GeronimoLogging.WARN : GeronimoLogging.DEBUG);
GeronimoLogging.setConsoleLogLevel(verboseArg == null ?  
GeronimoLogging.INFO : verboseArg.equals(ARGUMENT_VERBOSE) ?  
GeronimoLogging.DEBUG : GeronimoLogging.TRACE);



Instead of something like:


GeronimoLogging level = GeronimoLogging.WARN;
if (verboseArg != null) {
if (verboseArg.equals(ARGUMENT_VERBOSE)) {
level = GeronimoLogging.DEBUG;
} else if (verboseArg.equals(ARGUMENT_MORE_VERBOSE)) {
level = GeronimoLogging.TRACE;
}
}
GeronimoLogging.initialize(level);


Also, I've noticed that we still end up allowing INFO for console  
output (see the first snippet), which means we end up adding a bunch  
of levels to the server's log4j configuration to limit stuff to above  
INFO, which ends up limiting what goes into the log file, which I  
generally expect to have a bunch more detail.


What do we really want to see on the default console?  I assume this  
output is generally intended for users who don't really care about a  
lot of the internal muck, and really only expect to see ERROR  
(possibly) WARN messages, in addition to the startup monitory and  
shutdown messages.


Assuming this is correct, then we should set the default console  
appenders level to either WARN or ERROR.  I see that in  
GeronimoLogging, the default is ERROR, though I've seen some  
references to where the default should be WARN.


So... why don't we set the default to ERROR (ie.  
GeronimoLogging.initialize(GeronimoLogging.ERROR)) and then set to  
INFO,DEBUG,TRACE with -v, -vv, -vvv?


This should by default make the console output very terse, only  
showing log messages when something bad happens (else its just  
startup/shutdown messages) and then all the wonderful gory details  
can be captured in the log file, w/o needing so many limiting logger  
level entries in the log4j configuration.


Comments?

--jason

Re: 2.0-M3 release is cooking - FREEZE

[Jason Dillon]

You may want to consider using `svn lock` to enforce this... then  
`svn unlock` to unfreeze it.


--jason


On Feb 26, 2007, at 6:06 PM, Matt Hogstrom wrote:

I'm starting the release now.  Please don't update 2.0-M3 unless  
there is something really bad going on.

2.0-M3 release is cooking - FREEZE

[Matt Hogstrom]

I'm starting the release now.  Please don't update 2.0-M3 unless  
there is something really bad going on.

org.apache.geronimo.system.main.Daemon and commons-cli

[Jason Dillon]

Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to  
use commons-cli to handle option processing?


Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses  
commons-lang, which is already there), and will greatly simplify this  
code, and make it a little easier/nicer to add more command-line  
options in the future as well as providing.


--jason

Re: CORBA ported from OpenEJB 2

[David Blevins]

On Feb 23, 2007, at 7:08 AM, Dain Sundstrom wrote:


On Feb 23, 2007, at 5:06 AM, Rick McGuire wrote:
To do that part just implement the ModuleBuilderExtension  
interface and you can hook into all phases of the EjbModuleBuilder.
This is probably the part I have the most questions on.  Based on  
what I see in the two extensions that Geronimo currently has, I  
*think* the corba extension will need to do the following:


1)  In createModule(), handle merging of the default environments  
if we have one.  Should this be unconditional, or should we make  
it conditional on the presence of TSSLinks as in done in 1.2.


Conditional on the presence of the TSSLink seems optimal.

2)  In addGBeans(), create the TSSLink GBeans as is currently done  
in TSSLinkBuilder.  djencks and I couldn't figure out where we  
need to look to find the TSSLink plan entries.  I'm guessing we  
retrieve it from the Module somehow, but I'm not sure how or in  
what form it will be in when retrieved.


We just need to add that data to the geronimo-openejb.xml schema,  
which is available at EjbModule.getVendorDD().  In the v2 plan I see  
that we have two different elements, tss and tss-link.  What's the  
difference between those two?  If I can get a better understanding I  
can be a better help on the "how" part of adding them to the geronimo- 
openejb.xml.  Once we have a place for the data, we'd just update the  
conversion tool to port it over from the v2 plans and you're good to go.



Also a couple of side questions.
1)  There are two different signatures for createModule(), but I  
notice that the other extensions only override one of them.  When  
are they called and what needs to be done here?


Go with the one method the other extensions override. They're called  
at the very end of each of the matching phases in the ModuleBuilder  
interface.  As far as what needs to be done, you don't need to do  
anything if you don't want to.  They're just hooks there for you to  
have nearly-equal opportunity to do participate in all phases of the  
deployment process.  I say nearly as there are things you can't do  
like determine the module type or create it in createModule as the  
primary builder can, etc.


2)  I notice that both of these pass a plan argument, in different  
forms (one File, one Object).  Is it the responsibility of the  
createModule() method to examine the plan and add any relevant  
information to the module shared context?  Is that how we get the  
TSSLink information we'll need in addGBeans()?


You'd get it from the EjbModule.getVendorDD() when we add that info  
as described above.  But generally, it is possible to put data in the  
plan intended only for the builder extension which is something we  
may want to do someday though not really required for this.  The  
passing of the raw plan is more a "for future use" kind of thing so  
that we could someday do as described and have data passed to the  
builder extension in the plan without having to update the primary  
builder to handle it -- though it would have to know not to handle it.


3)  What form is the plan Object passed to the second createModule 
() signature?


It's usually an XMLBeans XmlObject.  Most likely one for a v2 openejb- 
jar.  These are already converted into the geronimo-openejb plan and  
available at builder extension createModule time via  
EjbModule.getVendorDD().  As stated, we just need a spot in the  
geronimo-openejb.xml to put the converted data.


Hope this helps.

-David

Re: GBeanInstance/GBeanInstanceState eating exceptions?

[David Jencks]

The stuff I added was mostly changing interfaces so the client could  
access the reason, and having the client do so: I also changed a  
bunch of places to record more info in the reason.


thanks
david jencks

On Feb 26, 2007, at 5:43 PM, Dain Sundstrom wrote:

I fixed a bug in 1.2, where the exception was being rethrown before  
it was recorded as the root cause.


-dain

On Feb 26, 2007, at 4:22 PM, David Jencks wrote:



On Feb 26, 2007, at 3:33 PM, Jason Dillon wrote:

I think David Jencks added something (or was going to add  
something) which would provide more detail for these exceptions  
when run from the car-m-p.


David, did you ever get around to adding that?  If not, is it  
something you can easily do?


I definitely added it to trunk (2.0).  I'm not sure if it made it  
into 1.2.


thanks
david jencks



--jason


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

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


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


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


-dain

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

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


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

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


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


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


--jason


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

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


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


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


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


-dain

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

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


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


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



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



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



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

...


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

Division of responsibilities for annotations to xml and jndi entries

[David Jencks]

While working on injections for jetty I ran into a problem with ejb  
annotations not indicating whether they are local or remote.  I  
solved it with a rather brute force attack of just building an  
additional ClassFinder and looking for all the ejbs.  This is really  
unpleasant because openejb has to do the same work all over again.   
After talking with David Blevins on IRC for a bit to try to  
understand the problem better I've come to the conclusion that our  
current division of responsibility between the annotation stuff Tim's  
been working on and the NamingBuilders is not very good.  Actually  
figuring out what xml is the accurate representation of an annotation  
requires deep understanding of the meaning of the annotation, not  
just a mechanical translation.  As such it should be done by the  
NamingBuilder that is part of the implementation of the system we are  
referring to.


This means that the NamingBuilders need more information that just  
the xml from the spec dd.  They also need information about the  
annotations involved and they need to be the code that modifies the  
spec dd.


IIUC Tim is working on providing an interface that provides for  
updating spec dds with additional refs.  I think that this can be  
used by NamingBuilders to add whatever xml they come up with.  I  
expect a lot of the code in EjbAnnotationHelper and  
ResourceAnnotationHelper is going to need to move to NamingBuilders.


So, I've concluded that the information in the annotations need to be  
supplied to the NamingBuilders in some form, but I don't have a clear  
idea yet about exactly what form.  I think that something like a map  
from annotation to Member might be adequate.  It might be better so  
extract the info into something more like the xml info, or it might  
be better to pass in the classes with annotations, or something else.


I expect to be thinking about this over the next day or two and  
comments and ideas are more than welcome.


thanks
david jencks

Re: GBeanInstance/GBeanInstanceState eating exceptions?

[Dain Sundstrom]

I fixed a bug in 1.2, where the exception was being rethrown before  
it was recorded as the root cause.


-dain

On Feb 26, 2007, at 4:22 PM, David Jencks wrote:



On Feb 26, 2007, at 3:33 PM, Jason Dillon wrote:

I think David Jencks added something (or was going to add  
something) which would provide more detail for these exceptions  
when run from the car-m-p.


David, did you ever get around to adding that?  If not, is it  
something you can easily do?


I definitely added it to trunk (2.0).  I'm not sure if it made it  
into 1.2.


thanks
david jencks



--jason


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

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


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


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


-dain

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

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


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

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


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


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


--jason


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


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

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


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


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


-dain

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

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


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


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



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



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



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

...


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


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



try {
kernel.startRecursiveGBean(dependent);
} catch (GBeanNotFoundException e) {
// this is ok the gbean died before we could start it
} catch (Exceptio

Re: 2.0-M3 - Building the release later today

[Jason Dillon]

You might just rename 2.0-beta1 to 2.0-M3, then create a new 2.0- 
beta1...


--jason


On Feb 26, 2007, at 2:59 PM, Matt Hogstrom wrote:

Ya, I'll remap the ones closed against beta-1 to M3 and close  
M2...thanks.


On Feb 26, 2007, at 4:50 PM, Jason Dillon wrote:

Matt, when you release m3 today... what JIRA version does that map  
to?  Looks like some of the issues were for 2.0-beta-1, which  
appears to be what 2.0-m3 is.  It would be swell if you could keep  
the JIRA version's in sync with reality.


And along those lines be sure to mark 2.0-m2 as released with what  
ever date it went out on... and do the same for 2.0-m3.  This is  
important to keep the JIRA roadmap/changelog feature functional.


--jason


On Feb 26, 2007, at 6:18 AM, Matt Hogstrom wrote:

Are there any outstanding issues with the branch that need to be  
resolved that anyone is aware of?  If not I'll cut the release  
for a vote this evening.

Re: [Discussion] Geronimo web site update

[Jason Dillon]

FYI... I tried a simple rsync today to see how well the copied  
content functions... and well it looks good:


http://people.apache.org/~jdillon/GMOxSITE

Seems to root everything properly, nav is happy, etc...

So... once the content is up to snuff, and we agree this is the right  
direction, then it should be fairly easy to make this live on  
geronimo.apache.org.


Only question is... who's account on people will perform the rsync?   
And at what time/freq should that be done.  I hope we can figure out  
an optimal time to perform this so that the lag from change to live  
is minimized.


And... I guess another question is do we want to toss the output in  
SVN at all?  Or just have a simple rsync, which will lay files ontop  
of the SVN-base (we still need some stuff from SVN, like style,  
images, plugin repo bits and some others).


--jason


On Feb 21, 2007, at 1:10 PM, Hernan Cunico wrote:

Hey Jason, have you tried to install the autoexport plugin in  
Confluence 2.3.3? for the record, I can't get it to work


Cheers!
Hernan

Jason Dillon wrote:
I may have an updated template on my local system... will try and  
find it.
I'm really tempted to hack the AutoExport plugin to pull templates  
from URL's, so we can configure it to use a URL from SVN for the  
template... and probably can even get includes working to allow  
splitting up the template into more manageable bits.
But... last I looked at the AE plugin it started to melt my  
brain... so who knows.

--jason
On Feb 20, 2007, at 2:57 PM, Hernan Cunico wrote:
I updated a bunch of pages in GMOxSITE and there are still a lot  
more to update


For now I'm trying to figure out the best way for using the *News*

I'll take a look at the template later on, unless somebody else  
wants to jump in ;-)


Just in case you don't know this is the URL -> http:// 
cwiki.apache.org/GMOxSITE/index.html


Cheers!
Hernan

Hernan Cunico wrote:
For the record, I'm getting an exception while trying to delete  
that space. Created a JIRA (INFRA-1170) with this issue.

Cheers!
Hernan
Hernan Cunico wrote:

Not really, we can nuke it. I'll make a XML bkp and delete it.

We have a tar ball backup in the sandbox for sentimental reasons.

Cheers!
Hernan


Jason Dillon wrote:

Do we still need this space?

 http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home

--jason


On Feb 19, 2007, at 4:35 PM, Hernan Cunico wrote:

you mean the shaded frame box? I think the difficult part  
will be the resizing in the css. Creating the graphics should  
be pretty simple.


Cheers!
Hernan

Jason Dillon wrote:
Can you find out where the ActiveMQ folks got that sexy box  
image from?  I'd *love* to have a nice box like that (g- 
styled of course) for our page too :-)

--jason
On Feb 19, 2007, at 4:05 PM, Hernan Cunico wrote:

Hey Jason,
I'm trying to catch up with the News/blog-posts on GMOxSITE  
as part of the web site update. I created a few tests  
(added News) but these posts take forever to show up. Any  
suggestions?


Anyway, do you have any idea how could we port the *News*  
we have on the live site?


Cheers!
Hernan

Jason Dillon wrote:

On Feb 15, 2007, at 9:17 AM, Hernan Cunico wrote:

Folks,
after lots of separated discussions on different threads  
it is clear the spirit for moving the authoring of our  
web site over Confluence. Let's bring to this thread all  
the ideas and discussion.


Proposal:
The idea is to use Confluence as the authoring tool for  
Geronimo's web site. To achieve this we will use the  
autoexport plugin already installed and in use on the  
cwiki.apache.org.
With the autoexport plugin we can customize the generated  
HTML look and feel by using templates. The current POC  
can be viewed at http://cwiki.apache.org/GMOxSITE (thx  
Jason D.)


Some suggestions (mine ;-)  )

- Avoid JIRA references/direct imports, if JIRA is down  
or running slow it will affect the main web site.
Eh... maybe... though JIRA should not be down or slow.   
These are also static pages, which only pull images off of  
the JIRA webapp, but we could remove the icon from the  
rendering.  I personally think its useful to show some  
JIRA activity on some page on the website.  Shows that we  
are still moving even if the website content isn't.
- Remove edit/print/export links from the generated site.  
Only Geronimo committers will have edit access

Fine w/me.
- Update the template L&F. Why not? It is a good  
opportunity to do it !!!
Ya, probably some changes to be made... I like the Cayenne  
site a lot... clean, simple... nice popup menus.
- Need to define how to integrate the other subprojects  
web sites (consider confluence spaces too).
Aye, we need a basic theme that works for the main site,  
documentation sites and sub-project sites.

- pls chime in!!!

I volunteer to start updating the content (matching with  
what we already have on the live site), unless somebody  
else wants to go it!

I will also look at some alternative templates.
I really would

Eclipse update site

[Stefan Seelmann]

Hi,

I just want to say that we reused the devtool's dynamic update site for
Apache Directory LDAP Studio. We adapted it a bit to return a site.xml
with the preferred mirror, see
http://svn.apache.org/viewvc?view=rev&revision=512038

Many thanks,
Stefan

Re: GBeanInstance/GBeanInstanceState eating exceptions?

[David Jencks]

On Feb 26, 2007, at 3:33 PM, Jason Dillon wrote:

I think David Jencks added something (or was going to add  
something) which would provide more detail for these exceptions  
when run from the car-m-p.


David, did you ever get around to adding that?  If not, is it  
something you can easily do?


I definitely added it to trunk (2.0).  I'm not sure if it made it  
into 1.2.


thanks
david jencks



--jason


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

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


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


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


-dain

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

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


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

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


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


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


--jason


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


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

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


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


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


-dain

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

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


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


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



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



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



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

...


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


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



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


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


This also looks fish

[jira] Closed: (GERONIMO-2881) Client-Transaction explicit-versions.properties does not include all dependencies.

[Jason Dillon (JIRA)]

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

Jason Dillon closed GERONIMO-2881.
--

Resolution: Cannot Reproduce

> Client-Transaction explicit-versions.properties does not include all 
> dependencies.
> --
>
> Key: GERONIMO-2881
> URL: https://issues.apache.org/jira/browse/GERONIMO-2881
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Maven Plugins for G
>Affects Versions: 2.0-beta1
> Environment: All (I think)
>Reporter: Matt Hogstrom
> Assigned To: Jason Dillon
> Fix For: 2.0-beta1
>
>
> When working on the branch I ran into a problem in configs/client-transaction 
> where the build failed because geronimo-ejb_3.0_specs//car could not be 
> resolved.  In looking at the generated explicit-versions.properties this 
> entry was missing.  I looked at the Maven dependencies for that module and 
> found that all dependencies under geronimo-transaction were missing in the 
> explicit versions.
> Here are the Maven dependencies:
> {noformat}
> [INFO] org.apache.geronimo.configs:client-transaction:car { 
> version=2.0-M3-SNAPSHOT, scope=null }
> [INFO] junit:junit:jar { version=3.8.1, scope=test }
> [INFO] org.apache.geronimo.genesis.config:logging-config:jar { 
> version=1.1, scope=test }
> [INFO] org.apache.geronimo.modules:geronimo-transaction:jar { 
> version=2.0-M3-SNAPSHOT, scope=compile }
> {noformat}
> These are not included in the explicit-version.properties file that is 
> generated:
> {noformat}
> [INFO] org.apache.geronimo.modules:geronimo-core:jar { 
> version=2.0-M3-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.modules:geronimo-j2ee:jar { 
> version=2.0-M3-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar { 
> version=1.0, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar { 
> version=1.0, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar 
> { version=1.1, scope=compile }
> [INFO] backport-util-concurrent:backport-util-concurrent:jar { 
> version=2.2, scope=compile }
> [INFO] org.objectweb.howl:howl:jar { version=1.0.1-1, scope=compile }
> {noformat}
> Resume included dependencies:
> {noformat}
> [INFO] org.apache.geronimo.configs:client:car { version=2.0-M3-SNAPSHOT, 
> scope=compile }
> [INFO] org.apache.geronimo.configs:client-system:car { 
> version=2.0-M3-SNAPSHOT, scope=compile }
> [INFO] 
> org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.configs:jee-specs:car { 
> version=2.0-M3-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar 
> { version=1.0-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar 
> { version=1.0, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-el_1.0_spec:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jacc_1.1_spec:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] 
> org.apache.geronimo.javamail:geronimo-javamail_1.4_mail:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] 
> org.apache.geronimo.javamail:geronimo-javamail_1.4_provider:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] 
> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar { 
> version=1.1, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jaxr_1.0_spec:jar { 
> version=1.1, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar { 
> version=1.1, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-jsp_2.1_spec:jar { 
> version=1.0-SNAPSHOT, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-saaj_1.1_spec:jar { 
> version=1.1, scope=compile }
> [INFO] org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar { 
> version=1.1-SNAPSHOT, scope=compile }
> [INFO] stax:stax-api:jar { version=1.0.1, scope=compile }
> [INFO] javax.xml.bind:jaxb-api:jar { version=2.0, scope=compile }
> [INFO] 
> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar { 
> version=1.1-SNAPSHOT, scope=compile }
> [INFO] javax.xml.ws:jaxws-api:jar { version=2.0, scope=compile }
> [INFO] org.apache.geronimo.modules:geronimo-activation:jar { 
> version=2.0-M3-SNAPSH

[jira] Commented: (GERONIMO-2741) Info messages are being displayed in the console output

[Jason Dillon (JIRA)]

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

Jason Dillon commented on GERONIMO-2741:


Forgot about this... looking at it again now...

> Info messages are being displayed in the console output
> ---
>
> Key: GERONIMO-2741
> URL: https://issues.apache.org/jira/browse/GERONIMO-2741
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Logging
>Affects Versions: 2.0-M1, 2.0-M2
> Environment: 2.0 trunk Rev496565
>Reporter: Donald Woods
> Assigned To: Jason Dillon
>Priority: Minor
> Fix For: 2.0-M2
>
> Attachments: G2741.patch
>
>
> The default logging level for the console (system.out) logging is INFO.
> This should be changed to default WARN to remove msgs such as -
> 16:18:44,875 INFO  [root] --
> 16:18:44,875 INFO  [root] Started Logging Service
> 16:18:44,875 INFO  [root] Runtime Information:
> 16:18:44,875 INFO  [root]   Install Directory = 
> E:\geronimo-tomcat6-jee5-2.0-SNAPSHOT
> 16:18:44,875 INFO  [root]   JVM in use = IBM Corporation Java 1.5.0
> 16:18:44,875 INFO  [root] Java Information:
> . . .
> 15:56:21,156 INFO  [DWRServlet] retrieved system configuration file: [EMAIL 
> PROTECTED]

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

Re: Geronimo Eclipse plugin for Apache Geronimo v1.0 only?

[Jacek Laskowski]

On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:


Is there a way I could build the monster locally and install it?

Yes, simply checkout devtools/trunk.


Got the following error:

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.apache.geronimo.specs
ArtifactId: specs
Version: 1.1.1

Reason: Unable to download the artifact from any repository

 org.apache.geronimo.specs:specs:pom:1.1.1

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


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 140 minutes 58 seconds
[INFO] Finished at: Tue Feb 27 00:50:07 CET 2007
[INFO] Final Memory: 40M/254M
[INFO] 

Jacek

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

Re: GBeanInstance/GBeanInstanceState eating exceptions?

[Jason Dillon]

I think David Jencks added something (or was going to add something)  
which would provide more detail for these exceptions when run from  
the car-m-p.


David, did you ever get around to adding that?  If not, is it  
something you can easily do?


--jason


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

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


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


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


-dain

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

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


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

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


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


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


--jason


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


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

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


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


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


-dain

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

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


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


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


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



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



org.apache.geronimo.kernel.repository.MissingDependencyException: U 
nable to resolve dependency org.apache.openejb/openejb-loader//jar
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resol 
veInClassLoader(DefaultArtifactResolver.java:123)
at  
org.apache.geronimo.kernel.repository.DefaultArtifactResolver$ 
$FastClassByCGLIB$$e847b746.invoke()
at net.sf.cglib.reflect.FastMethod.invoke 
(FastMethod.java:53)

...


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


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



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


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


This also looks fishy:


try {
// try to create the instance
if (!gbeanInstance.createInstance()) {
// instance is not ready to start... this is normally  
caused by 

Re: 1.2 status

[Jason Dillon]

There does not appear to be a 4.1.1-SNAPSHOT up anywhere I can find.   
Are you guys gonna deploy a 4.1.1-SNAPSHOT with this fix in it... or  
does the 4.2-SNAPSHOT contain these fixes (and is relatively  
compatible with 4.1-incubator, and hopefully going to be releasable  
soon) so we can include this fix and re-run the TCK to verify its happy?


--jason


On Feb 26, 2007, at 12:10 PM, Hiram Chirino wrote:


Both the AMQ issues now have fixes applied to the 4.1 branch.

On 2/22/07, Rick McGuire <[EMAIL PROTECTED]> wrote:

Dain Sundstrom wrote:
> This release is finally wrapping up.  We are basically waiting on
> final releases from the projects we depend on.  Specifically, we  
need

> releases from:
>
>   Yoko 1.0 - Contains many fixes to CORBA interoperability
>   ActiveMQ 4.1.1 - We need a release which contains AMQ-1165 and  
AMQ-1088

>   OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be release
There are a couple of fixes to both the javamail 1.3.1 specs and
providers we really should try to get into 1.2.  Multiple  
customers have
hit this problem in 1.1.1.   This will require releasing new  
versions of
both deliverables.  The fixes are already in the code, we just  
need to

go through the mechanics of releasing it.

Rick


>
> As always, this could take a painful amount of time to get the
> binaries, but I'm hopeful.
>
> -dain
>





--
Regards,
Hiram

Blog: http://hiramchirino.com

[jira] Created: (SM-858) Unable to access a JBIContainer using the supplied component context in various endpoints (i.e. JSR181)

[jmdev (JIRA)]

Unable to access a JBIContainer using the supplied component context in various 
endpoints (i.e. JSR181)
---

 Key: SM-858
 URL: https://issues.apache.org/activemq/browse/SM-858
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core, servicemix-http, servicemix-jsr181
Affects Versions: 3.1
Reporter: jmdev


Following the instructions at 

http://incubator.apache.org/servicemix/how-can-i-access-the-jbicontainer-from-inside-a-component-.html
 

a developer should be able to access the JBIContainer from within a JSR181 
POJO.  However, there is a ClassCastException due to the fact that the 
ComponentContext returned is of type EndpointComponentContext.  In turn, an 
EndpointComponentContext does not provide access to it's internal context of 
type ComponentContext, which allows the developer to get a reference to the 
JBIContainer.

Temporary fix can be found here:

http://www.nabble.com/Error-Accessing-JBI-Container-from-JSR181-Component---Is-it-Possible--tf3281290s12049.html#a9132255

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

Re: 2.0-M3 - Building the release later today

[Matt Hogstrom]

Ya, I'll remap the ones closed against beta-1 to M3 and close  
M2...thanks.


On Feb 26, 2007, at 4:50 PM, Jason Dillon wrote:

Matt, when you release m3 today... what JIRA version does that map  
to?  Looks like some of the issues were for 2.0-beta-1, which  
appears to be what 2.0-m3 is.  It would be swell if you could keep  
the JIRA version's in sync with reality.


And along those lines be sure to mark 2.0-m2 as released with what  
ever date it went out on... and do the same for 2.0-m3.  This is  
important to keep the JIRA roadmap/changelog feature functional.


--jason


On Feb 26, 2007, at 6:18 AM, Matt Hogstrom wrote:

Are there any outstanding issues with the branch that need to be  
resolved that anyone is aware of?  If not I'll cut the release for  
a vote this evening.

Re: 1.2 status

[Jason Dillon]

Is there a 4.1.1 snapshot we should be using to pick up these  
changes?  We are still using 4.1.0-incubator.


--jason


On Feb 26, 2007, at 12:10 PM, Hiram Chirino wrote:


Both the AMQ issues now have fixes applied to the 4.1 branch.

On 2/22/07, Rick McGuire <[EMAIL PROTECTED]> wrote:

Dain Sundstrom wrote:
> This release is finally wrapping up.  We are basically waiting on
> final releases from the projects we depend on.  Specifically, we  
need

> releases from:
>
>   Yoko 1.0 - Contains many fixes to CORBA interoperability
>   ActiveMQ 4.1.1 - We need a release which contains AMQ-1165 and  
AMQ-1088

>   OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be release
There are a couple of fixes to both the javamail 1.3.1 specs and
providers we really should try to get into 1.2.  Multiple  
customers have
hit this problem in 1.1.1.   This will require releasing new  
versions of
both deliverables.  The fixes are already in the code, we just  
need to

go through the mechanics of releasing it.

Rick


>
> As always, this could take a painful amount of time to get the
> binaries, but I'm hopeful.
>
> -dain
>





--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Moving plugin-support bits out of Genesis into Mojo?

[Jason Dillon]

On Feb 26, 2007, at 7:08 AM, Donald Woods wrote:
The only concern, would be that we need multiple Geronimo commiters  
with commit and release access to the dependent Mojo project, so we  
don't lie in limbo when we need fixes/changes made to the plugin to  
support new build requirements


Understood, and we have a few committers on the Mojo project already:

  * Jason van Zyl
  * Hiram Chirino
  * David Blevins
  * Jeff Genender
  * James Strachan
  * Alan Cabrera
  * (ME) Jason Dillon

Not sure I listed all of them... but we have a few ;-)

And, well project-support is not really changing all that much,  
changes to be made in the future are to make these bits into more re- 
usable components instead of base-classes, blah, blah.


As for being stuck in limbo... well, I don't think that will be the  
case any time soon... I'm still here :-P


--jason

Re: Moving plugin-support bits out of Genesis into Mojo?

[Jason Dillon]

On Feb 26, 2007, at 8:29 AM, Anita Kulshreshtha wrote:


   I agree with Donald because this code (plugins/plugin-support) is
very closely tied to geronimo. Here is an example:
System.getProperties().remove("geronimo.bootstrap.logging.enabled");


This is the only bit from plugin-support that is Geronimo specific,  
and I've a note to move that stuff out.


--jason

Re: 2.0-M3 - Building the release later today

[Jason Dillon]

Matt, when you release m3 today... what JIRA version does that map  
to?  Looks like some of the issues were for 2.0-beta-1, which appears  
to be what 2.0-m3 is.  It would be swell if you could keep the JIRA  
version's in sync with reality.


And along those lines be sure to mark 2.0-m2 as released with what  
ever date it went out on... and do the same for 2.0-m3.  This is  
important to keep the JIRA roadmap/changelog feature functional.


--jason


On Feb 26, 2007, at 6:18 AM, Matt Hogstrom wrote:

Are there any outstanding issues with the branch that need to be  
resolved that anyone is aware of?  If not I'll cut the release for  
a vote this evening.

Re: Jetty for Geronimo with annotations?

[David Jencks]

On Feb 26, 2007, at 1:36 PM, Joe Bohn wrote:


David,

I see that in rev. 512007 you just checked code to support  
injection of annotations for Jetty.   So does that mean that we  
have enough support in Jetty 6.1 to meet our JavaEE5 requirements  
without moving to a newer (not yet released) level of Jetty?


I think so.  I don't have everything working yet, and don't have the  
pre/post annotations done, but I don't see any major problems on the  
horizon.


BTW I decided it was easier to imitate rather than use the annotation  
support in jetty plus.


thanks
david jencks



Thanks,
Joe



David Jencks wrote:

On Feb 23, 2007, at 11:07 AM, Joe Bohn wrote:



David Jencks wrote:
I think enough support is already in released versions of jetty  
for our purposes, the main thing I'm aware of that's left is  
hooking up the injection stuff we fish out using tim's new code  
to the jetty injection processor.


That may be.  What was making me wonder was seeing items like  
this: http://docs.codehaus.org/display/JETTY/Annotations
making references to a Jetty 6.1.2beta with additional annotation  
support.   It's not clear to me if it is required that the  
annotations are support for the resource injection and callbacks  
in order to be spec compliant  ... so, I thought I should ask.
We require support for that, but I think that since we've taken  
over pretty much all the deployment stuff from jetty, we have to  
figure out what needs to be injected and feed that into jetty's  
injection system.  I believe the injection system itself is  
already released.  It might be in a jetty plus jar.  I was  
thinking of taking a look at this shortly were you also?

thanks
david jencks


Joe



On Feb 22, 2007, at 2:19 PM, Joe Bohn wrote:

Jan, Greg, any other Jetty experts ...

I know that there is work going on to get annotation support  
included in a Jetty (6.1.2*).  Is there a release planned soon  
that we could pick up in for Geronimo 2.0 (ie. soon enough that  
we could maybe get it included and tested before JavaOne).


Thanks,
Joe

Re: Jetty for Geronimo with annotations?

[Joe Bohn]

David,

I see that in rev. 512007 you just checked code to support injection of 
annotations for Jetty.   So does that mean that we have enough support 
in Jetty 6.1 to meet our JavaEE5 requirements without moving to a newer 
(not yet released) level of Jetty?


Thanks,
Joe



David Jencks wrote:


On Feb 23, 2007, at 11:07 AM, Joe Bohn wrote:




David Jencks wrote:
I think enough support is already in released versions of jetty for 
our purposes, the main thing I'm aware of that's left is hooking up 
the injection stuff we fish out using tim's new code to the jetty 
injection processor.


That may be.  What was making me wonder was seeing items like this: 
http://docs.codehaus.org/display/JETTY/Annotations
making references to a Jetty 6.1.2beta with additional annotation 
support.   It's not clear to me if it is required that the annotations 
are support for the resource injection and callbacks in order to be 
spec compliant  ... so, I thought I should ask.


We require support for that, but I think that since we've taken over 
pretty much all the deployment stuff from jetty, we have to figure out 
what needs to be injected and feed that into jetty's injection system.  
I believe the injection system itself is already released.  It might be 
in a jetty plus jar.  I was thinking of taking a look at this 
shortly were you also?


thanks
david jencks



Joe



On Feb 22, 2007, at 2:19 PM, Joe Bohn wrote:

Jan, Greg, any other Jetty experts ...

I know that there is work going on to get annotation support 
included in a Jetty (6.1.2*).  Is there a release planned soon that 
we could pick up in for Geronimo 2.0 (ie. soon enough that we could 
maybe get it included and tested before JavaOne).


Thanks,
Joe

[jira] Commented: (XBEAN-74) ClassFinder NullPointerException

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/XBEAN-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476010
 ] 

David Blevins commented on XBEAN-74:


http://svn.apache.org/viewvc?view=rev&rev=507771

> ClassFinder NullPointerException
> 
>
> Key: XBEAN-74
> URL: https://issues.apache.org/jira/browse/XBEAN-74
> Project: XBean
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
>Priority: Minor
> Fix For: 3.0
>
> Attachments: GERONIMO-2833.patch
>
>
> Classes which are not part of a package will result in a null from the 
> class.getPackage() method, ultimately causing a NullPointerException

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

Geronimo v2.0 Documentation update

[Hernan Cunico]

Hi All,
Administration docs are half way through. Would like to hear new ideas for 
topics to cover, see

http://cwiki.apache.org/GMOxDOC20/documentation.html

Just added Virtual Host configuration example for both Jetty and Tomcat.

Cheers!
Hernan

Re: Geronimo Eclipse plugin for Apache Geronimo v1.0 only?

[Sachin Patel]

-sachin


On Feb 26, 2007, at 3:35 PM, Jacek Laskowski wrote:


On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:
Hi Jacek, The download additional server adapters only pulls down  
published

released adapters.  So currently support for 1.0, and 1.1.x can be
downloaded.  For 2.0 I'm currently working on a driver, which I  
should hope
to have available with our M3 milestone. But this won't be  
published to the

update manager site and will be a download and extract installation
procedure.


Is there a way I could build the monster locally and install it?


Yes, simply checkout devtools/trunk.




FYI WTP2.0M5 is currently very restricted in its EE5 capability.  For
example, only the facet suppport is really there, and not any of the
namespace support, thus none of the deployment descriptors will be  
generated

if you create an EE5 project.  This is targeted for their M6.


Yeah, you're right, but that's the only working WTP version for
Eclipse 3.3M5eh with an enhanced Dali. I couldn't wait till M6 is
released.


Ok, well go for it and let me know what is working and whats not. :)



Jacek

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

[jira] Commented: (GERONIMO-2887) Hook up injections for jetty and app client

[David Jencks (JIRA)]

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

David Jencks commented on GERONIMO-2887:


I got injections to pretty much work for jetty and committed in rev 512007.  
AFAICT it doesn't break tomcat
This probably slows down deployment A LOT because I'm creating a ClassFinder 
for the entire web app classloader to pick up any ejbs that might be available. 
 That part of the code needs to be improved.

> Hook up injections for jetty and app client
> ---
>
> Key: GERONIMO-2887
> URL: https://issues.apache.org/jira/browse/GERONIMO-2887
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 2.0
>
> Attachments: GERONIMO-2887.patch
>
>
> Now all the annotations are getting put into the xml dd.  We need to actually 
> use this info to do the injections for jetty and the app client.

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

Apache Geronimo v2 at conferences on March in Poland

[Jacek Laskowski]

Hi,

Just a head-up for two upcoming conferences in Poland featuring Apache
Geronimo v2 where I'm presenting what's new in Java EE 5 and how one
can learn the stuff with Geronimo. Not much time to talk about it as
I've only got 2 x 1h, but quite enough to show how well we stack up
against competition.

* Studencki Festiwal Informatyczny - 03/8-10 (http://www.sfi.org.pl) -
"Apache Geronimo v2 - a Java EE 5 application server" by Jacek
Laskowski

* Software Development GigaCon 2007 - 03/22-23
(http://www.gigacon.org/pl/conferences/gigacon/software_development.html)
- "More, faster, easier with Java EE 5 and Apache Geronimo v2" by
Jacek Laskowski

Come and see two old yet beautiful cities in Poland - Krakow and
Warszawa. The conferences are free as far as I know so anyone's
invited!

Jacek

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

[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.

[Bjorn Harvold (JIRA)]

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

Bjorn Harvold commented on GERONIMO-1553:
-

Is this issue still ongoing? I am migrating a Websphere app to Geronimo and the 
task timer is the only thing that cannot be migrated.

> Provide commonj Timer and Work Manager.
> ---
>
> Key: GERONIMO-1553
> URL: https://issues.apache.org/jira/browse/GERONIMO-1553
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: general
>Affects Versions: Wish List
> Environment: na
>Reporter: Seth White
> Assigned To: Kevan Miller
> Attachments: commonj.jar, commonj_spec.jar, commonj_timer.jar
>
>
> It would be nice if Geronimo provided an implementation of the Timer and Work 
> Manager APIs specified by commonj.
> More information on these features can be found here:
> http://dev2dev.bea.com/wlplatform/commonj/twm.html

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

Re: svn commit: r511833 - /incubator/servicemix/trunk/pom.xml

[Terry Cox]

The problem seems due to a failure in the merge/switch. The error 
message is a bit obtuse, but seems to relate to switching to/from a 
folder which doesn't exist.


It might be worth trying to back out those changes and apply them 
individually to see which breaks?

--
Terry Cox
Meta-Concepts Ltd

Re: Geronimo Eclipse plugin for Apache Geronimo v1.0 only?

[Jacek Laskowski]

On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:

Hi Jacek, The download additional server adapters only pulls down published
released adapters.  So currently support for 1.0, and 1.1.x can be
downloaded.  For 2.0 I'm currently working on a driver, which I should hope
to have available with our M3 milestone. But this won't be published to the
update manager site and will be a download and extract installation
procedure.


Is there a way I could build the monster locally and install it?


FYI WTP2.0M5 is currently very restricted in its EE5 capability.  For
example, only the facet suppport is really there, and not any of the
namespace support, thus none of the deployment descriptors will be generated
if you create an EE5 project.  This is targeted for their M6.


Yeah, you're right, but that's the only working WTP version for
Eclipse 3.3M5eh with an enhanced Dali. I couldn't wait till M6 is
released.

Jacek

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

Re: [RESULT] VOTE J2G Conversion tool acceptance

[Davanum Srinivas]

Checked in.

thanks,
dims

On 2/26/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

dims,
I've updated some info in the IP clearance form, attached is the patch file.
The JIRA has also been updated with the codebase that reflects the ASF
license in the source header, and the IBM copyright in the COPYRIGHT.txt
file
Both Covalent and IBM CCLA are also attached to the JIRA item.

Is there anything left from us, or is the rest left up to the Geronimo PMC?

Filip

Davanum Srinivas wrote:
> Yes, i can help with the ip-clearance.
>
> -- dims
>
> On 2/19/07, Kevan Miller <[EMAIL PROTECTED]> wrote:
>>
>> On Feb 19, 2007, at 9:47 AM, Matt Hogstrom wrote:
>>
>> > So, we voted this monster in and accepted the code base.   At this
>> > point, per Geir's note in this thread Noted below:
>> >
>> >
>> > > Here's the process :
>> > >
>> > > 1) Contributor offers code  *Complete*
>> > >
>> > > 2) Project decides to accept or reject code.  Formally, this is
>> > the PMC, but everyone should chime in.   *Complete* per vote below
>> > >
>> > > 3) Contributor provides CCLA
>> > *Complete* CCLA located in JIRA
>> >
>> > > Cleans up code to remove copyright statements
>> > *Outstanding* Need a volunteer here.  I think ideally the
>> > contributor would accomplish this step and post an updated file in
>> > the JIRA with this work completed.
>> >
>> > > And puts the standard apache file header in place.
>> > *Outstanding* Really same as above.  Needs to have a committer
>> > review this so need a new volunteer here.
>> >
>> > >
>> > > 4) Project accepts code contribution and registers the code
>> > contribution w/ the incubator with an ip_clearance form :  http://
>> > svn.apache.org/viewvc/incubator/public/trunk/site-author/ip-clearance/
>> > *Outstanding*  We've already accepted the code through this vote.
>> > This is the mechanics of getting the code into Apache.  I think the
>> > committer noted above should do this as well.
>>
>> Matt, committers can certainly help. However, either an officer (you)
>> or an ASF member (Dims or Geir) will need to fill out and submit the
>> IP Clearance form -- http://incubator.apache.org/ip-clearance/ip-
>> clearance-template.html. Also, the software grant form needs to be
>> acknowledged by the ASF secretary (or another ASF officer).
>>
>> --kevan
>>
>>
>>
>>
>>
>>
>
>


Index: geronimo-2743-ibm-covalent-j2g.xml
===
--- geronimo-2743-ibm-covalent-j2g.xml  (revision 511944)
+++ geronimo-2743-ibm-covalent-j2g.xml  (working copy)
@@ -35,7 +35,7 @@
Project info
 

-   Which PMC will be responsible for the code 
: Apache Geronimo
+   Which PMC will be responsible for the code 
: Apache Geronimo

   

@@ -59,15 +59,28 @@
 


-   Not Applicable
+January-16-2007

-  
-   
-   If applicable, make sure 
that any associated name does not already
-exist and check www.nameprotect.com to be sure that the name is not
-already trademarked for an existing software product.
-
+JIRA https://issues.apache.org/jira/browse/GERONIMO-2743";>GERONIMO-2743 Created. 
+   https://issues.apache.org/jira/secure/attachment/12349176/Covalent-J2G-Tool.pdf"Covalent 
CCLA Attached
+   https://issues.apache.org/jira/secure/attachment/12349047/CCLA.tif";>IBM CCLA 
Attached
+   https://issues.apache.org/jira/secure/attachment/12349046/J2G-Migration-v2_src_1.0.0.zip";>Original
 codebase attached
+
+  
+  
+February-21-2007
+
+Copyright adjusted and https://issues.apache.org/jira/secure/attachment/12351724/J2G-Migration_2.0.0_src_20070220-1501.zip";>codebase
 cleaned up, ready for import 
+

+ 
+   February-21-2007
+   
+MD5 or SHA1 sum for donated software: 
+  3cfbefd2424c3556fdcbf162a1129399 
*J2G-Migration_2.0.0_src_20070220-1501.zip
+  e49e61df710dae15025b0126e4f8e672 *J2G-Migration-v2_src_1.0.0.zip
+  (Note versioned software used to calculate sum in parentheses).
+


Copyright
@@ -80,7 +93,7 @@
 


-   Not Yet Done.
+   Not yet done
 
Check and make sure 
that the papers that transfer rights to the ASF
 been received. It is

[jira] Resolved: (GERONIMO-2876) Initial web service EJB support for Axis2

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas resolved GERONIMO-2876.


Resolution: Fixed

Thanks Lin. svn revision 511987

-- dims

> Initial web service EJB support for Axis2
> -
>
> Key: GERONIMO-2876
> URL: https://issues.apache.org/jira/browse/GERONIMO-2876
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
> Environment: winxp + sun 1.5
>Reporter: Lin Sun
> Attachments: G2876-2.patch, G2876.patch
>
>
> This work-in-progress patch tried to port the initial web service ejb support 
> from CXF to Axis2 (G2850) and here are a few details:
> 1) I had a hard time with classexception while working through the two 
> portinfo classes (org.apache.geronimo.jaxws.PortInfo and 
> org.apache.geronimo.axis2.PortInfo) thus I am proposing to get rid of 
> org.apache.geronimo.axis2.PortInfo for simplicities.
> 2) I decided to keep the old Axis structure instead of the new CXF structure 
> for EJB support, as I envision that all the requests will be handled in one 
> Axis2WebServiceContainer. 
> Able to do a full build with the patch.Tested the patch with jax-ws-ejb 
> test.   For CXF, 2 out of 3 pass (same as before the patch).  For Axis2,  was 
> able to see the ejb module loaded and started.  However, get the jaxb error:
> 22:51:09,906 INFO  [JAXBUtils] Both ObjectFactory & package-info not found in 
> pa
> ckage hierachy
> 22:51:10,296 ERROR [Axis2WebServiceContainer] Exception occurred while trying 
> to
>  invoke service method doService()
> org.apache.axis2.AxisFault: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]; 
> nested e
> xception is:
> javax.xml.ws.WebServiceException: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:367)
> at 
> org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessa
> geReceiver.java:147)
> Will attempt to fix this tomorrow by supplying the generated ObjectFactory & 
> package-info classes for jax-ws-ejb test.
> Please let me know any comments you might have.

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

Re: 1.2 status

[Aaron Mulder]

Also there have been reports that some console screens are broken
(JMS, maybe?) and it would be nice to fix those for the 1.2 final
release.

Thanks,
  Aaron

On 2/22/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

This release is finally wrapping up.  We are basically waiting on
final releases from the projects we depend on.  Specifically, we need
releases from:

   Yoko 1.0 - Contains many fixes to CORBA interoperability
   ActiveMQ 4.1.1 - We need a release which contains AMQ-1165 and
AMQ-1088
   OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be release

As always, this could take a painful amount of time to get the
binaries, but I'm hopeful.

-dain

Re: 1.2 status

[Hiram Chirino]

Both the AMQ issues now have fixes applied to the 4.1 branch.

On 2/22/07, Rick McGuire <[EMAIL PROTECTED]> wrote:

Dain Sundstrom wrote:
> This release is finally wrapping up.  We are basically waiting on
> final releases from the projects we depend on.  Specifically, we need
> releases from:
>
>   Yoko 1.0 - Contains many fixes to CORBA interoperability
>   ActiveMQ 4.1.1 - We need a release which contains AMQ-1165 and AMQ-1088
>   OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be release
There are a couple of fixes to both the javamail 1.3.1 specs and
providers we really should try to get into 1.2.  Multiple customers have
hit this problem in 1.1.1.   This will require releasing new versions of
both deliverables.  The fixes are already in the code, we just need to
go through the mechanics of releasing it.

Rick


>
> As always, this could take a painful amount of time to get the
> binaries, but I'm hopeful.
>
> -dain
>





--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: 2.0-M3 Status

[Matt Hogstrom]

Release notes look good Hernan...thanks!

Anyone have any other comments?

I added a comment at the front of the notes to point to the Wiki for  
"the latest information."



On Feb 26, 2007, at 11:56 AM, Hernan Cunico wrote:


the wiki seems to be back from the "undead".

here is the link to the release notes, I made some updates but need  
you guys to chime in and do the "fine tuning" ;-)


http://cwiki.apache.org/GMOxDOC20/release-notes-20-m3txt.html

WS needs validation and I don't really know how complete we are  
with EJB 3


I'm still having some problems with JIRA so the last part of the  
notes is missing, I'm working on it.


Cheers!
Hernan

Matt Hogstrom wrote:
I was finally able to get a build to complete on 2.0-M3.  The  
problem I was seeing (on old and new repos) is that for client- 
transaction and client-deployer and had to add a reference to the  
geronimo-ejb_3.0_spec dependency.  I'll work on the Car plugin to  
isolate this problem for the next cut but I think we're good for now.
Hernan, I think you mentioned you were pulling together the  
release notes.  Could you post what you have to the branches/2.0- 
M3 tree?  I'll pop out the binaries tomorrow to make available.

Start the creative juices flowing for what's in there folks :)

Re: Removing ServiceMix build on continuum

[Joe Schaefer]

"Guillaume Nodet" <[EMAIL PROTECTED]> writes:

> I have no idea who set up the ServiceMix builds at
>  http://vmbuild.apache.org:8080/continuum/servlet/continuum
> but they are flooding the dev list, as the buils currently fail
> every hour or so.
> Would it be possible to remove them please ?
> (i have no admin rights there afaik, i even don't have
> any account).

Please open an INFRA Jira ticket under VMBuild.

-- 
Joe Schaefer

[jira] Commented: (GERONIMO-2743) [Code donation] J2G Conversion tool

[Paul McMahan (JIRA)]

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

Paul McMahan commented on GERONIMO-2743:


There was some discussion about the package name on dev:
http://www.nabble.com/-VOTE--J2G-Conversion-tool-acceptance-tf3149274.html#a9120007

Specifically, Sachin said:
{quote}
In order to follow proper convention, the package names need to start with the 
plugin id and the plugin id should be organization + product + plugin so in our 
case...

plugin id: org.apache.geronimo.j2g.someIdForThisSpecificPlugin

and all packages within that plugin should start with the pluginId
{quote}

Since this probably constitutes a significant amount of refactoring (and maybe 
even some more discussion) I think it might be best to make the packaging 
adjustments after the code is in sandbox.

> [Code donation] J2G Conversion tool
> ---
>
> Key: GERONIMO-2743
> URL: https://issues.apache.org/jira/browse/GERONIMO-2743
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>Affects Versions: 1.1.x
> Environment: MS Windows XP SP2 (although Java based should work on 
> any OS supporting Java)
>Reporter: Filip Hanik
>Priority: Minor
> Fix For: 1.1.x
>
> Attachments: CCLA.tif, Covalent-J2G-Tool.pdf, 
> J2G-Migration-v2_src_1.0.0.zip, J2G-Migration_2.0.0_src_20070220-1501.zip
>
>
> IBM has together with in a joint effort with Covalent developed a JBoss to 
> Geronimo conversion tool. This tool is used when converting applications from 
> JBoss to Geronimo, and automatically converts the configuration file from one 
> app server to the other.
> We feel that this piece of software adds value to Geronimo and users adopting 
> Geronimo and would like to see this effort continue as part of the Geronimo 
> project, a plugin or a sub project of Geronimo.
> The initial donation is for version 1.0 of this tool, and while a 1.1 is in 
> the making to improve 1.0, 1.1 is not yet complete but will be donated as 
> soon as the community feels that this tool belongs at the ASF, more 
> specifically within the Geronimo project.
> If you'd think this tool is valuable, but believe it should go through 
> incubation, we would hope that a Geronimo committer would step up and 
> champion this effort.
> The tool, including IBM's CCLA, can be found at 
> http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the CCLA 
> upon request) 

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

[jira] Created: (XBEAN-77) ClassFinder needs better error handling

[David Jencks (JIRA)]

ClassFinder needs better error handling
---

 Key: XBEAN-77
 URL: https://issues.apache.org/jira/browse/XBEAN-77
 Project: XBean
  Issue Type: Bug
Affects Versions: 2.9
Reporter: David Jencks
 Fix For: 2.9


ClassFinder uses e.printStackTrace() as an error reporting mechanism.  This 
needs to be fixed somehow.

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

[jira] Closed: (XBEAN-76) Another NPE in ClassFinder

[David Jencks (JIRA)]

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

David Jencks closed XBEAN-76.
-

Resolution: Fixed

Fixed NPE in rev 511967.  Also fixed intellij warnings (javadoc tags and 
unchecked assignments to generics)

> Another NPE in ClassFinder
> --
>
> Key: XBEAN-76
> URL: https://issues.apache.org/jira/browse/XBEAN-76
> Project: XBean
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 2.9
>
>
> ClassFinder.readClassDef has a lot of opportunities  for NPEs.  I get them  
> when I've constructed a ClassFinder for a geronimo war classloader, the 
> missing paths are in WEB-INF/classes.

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

Removing ServiceMix build on continuum

[Guillaume Nodet]

I have no idea who set up the ServiceMix builds at
 http://vmbuild.apache.org:8080/continuum/servlet/continuum
but they are flooding the dev list, as the buils currently fail
every hour or so.
Would it be possible to remove them please ?
(i have no admin rights there afaik, i even don't have
any account).

--
Cheers,
Guillaume Nodet

[jira] Commented: (GERONIMO-2743) [Code donation] J2G Conversion tool

[Filip Hanik (JIRA)]

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

Filip Hanik commented on GERONIMO-2743:
---

Current codebase is packaged as: org.apache.apps.j2gmigrator...
we suggest that during the import, the code is restructured as: 
org.apache.geronimo.j2gmigrator or org.apache.geronimo.devtools.j2gmigrator



> [Code donation] J2G Conversion tool
> ---
>
> Key: GERONIMO-2743
> URL: https://issues.apache.org/jira/browse/GERONIMO-2743
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>Affects Versions: 1.1.x
> Environment: MS Windows XP SP2 (although Java based should work on 
> any OS supporting Java)
>Reporter: Filip Hanik
>Priority: Minor
> Fix For: 1.1.x
>
> Attachments: CCLA.tif, Covalent-J2G-Tool.pdf, 
> J2G-Migration-v2_src_1.0.0.zip, J2G-Migration_2.0.0_src_20070220-1501.zip
>
>
> IBM has together with in a joint effort with Covalent developed a JBoss to 
> Geronimo conversion tool. This tool is used when converting applications from 
> JBoss to Geronimo, and automatically converts the configuration file from one 
> app server to the other.
> We feel that this piece of software adds value to Geronimo and users adopting 
> Geronimo and would like to see this effort continue as part of the Geronimo 
> project, a plugin or a sub project of Geronimo.
> The initial donation is for version 1.0 of this tool, and while a 1.1 is in 
> the making to improve 1.0, 1.1 is not yet complete but will be donated as 
> soon as the community feels that this tool belongs at the ASF, more 
> specifically within the Geronimo project.
> If you'd think this tool is valuable, but believe it should go through 
> incubation, we would hope that a Geronimo committer would step up and 
> champion this effort.
> The tool, including IBM's CCLA, can be found at 
> http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the CCLA 
> upon request) 

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

Re: svn commit: r511833 - /incubator/servicemix/trunk/pom.xml

[Guillaume Nodet]

Yeah, but I have no admin rights there afaik,
and I have no idea who setup that :-(

On 2/26/07, Terry Cox <[EMAIL PROTECTED]> wrote:

> Author: gnodet Date: Mon Feb 26 06:53:33 2007 New Revision: 511833
> URL: http://svn.apache.org/viewvc?view=rev&rev=511833 Log: Remove
> continuum notifier

I guess you are probably on this already, but just in case, changing the
pom hasn't fixed the problem because it's a svn issue:

Provider message: The svn command failed.
Command output:
---
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: Cannot replace a directory from within

Continuum can't get a new copy of the source including that pom change,
  so it is still using the original copy. You may have to stop continuum
and manually clean its build folder first to see if the problem is there
or in svn.

Cheers,
--
Terry Cox
Meta-Concepts Ltd
0788 1920512




--
Cheers,
Guillaume Nodet

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

Re: [RESULT] VOTE J2G Conversion tool acceptance

[Filip Hanik - Dev Lists]

dims,
I've updated some info in the IP clearance form, attached is the patch file.
The JIRA has also been updated with the codebase that reflects the ASF 
license in the source header, and the IBM copyright in the COPYRIGHT.txt 
file

Both Covalent and IBM CCLA are also attached to the JIRA item.

Is there anything left from us, or is the rest left up to the Geronimo PMC?

Filip

Davanum Srinivas wrote:

Yes, i can help with the ip-clearance.

-- dims

On 2/19/07, Kevan Miller <[EMAIL PROTECTED]> wrote:


On Feb 19, 2007, at 9:47 AM, Matt Hogstrom wrote:

> So, we voted this monster in and accepted the code base.   At this
> point, per Geir's note in this thread Noted below:
>
>
> > Here's the process :
> >
> > 1) Contributor offers code  *Complete*
> >
> > 2) Project decides to accept or reject code.  Formally, this is
> the PMC, but everyone should chime in.   *Complete* per vote below
> >
> > 3) Contributor provides CCLA
> *Complete* CCLA located in JIRA
>
> > Cleans up code to remove copyright statements
> *Outstanding* Need a volunteer here.  I think ideally the
> contributor would accomplish this step and post an updated file in
> the JIRA with this work completed.
>
> > And puts the standard apache file header in place.
> *Outstanding* Really same as above.  Needs to have a committer
> review this so need a new volunteer here.
>
> >
> > 4) Project accepts code contribution and registers the code
> contribution w/ the incubator with an ip_clearance form :  http://
> svn.apache.org/viewvc/incubator/public/trunk/site-author/ip-clearance/
> *Outstanding*  We've already accepted the code through this vote.
> This is the mechanics of getting the code into Apache.  I think the
> committer noted above should do this as well.

Matt, committers can certainly help. However, either an officer (you)
or an ASF member (Dims or Geir) will need to fill out and submit the
IP Clearance form -- http://incubator.apache.org/ip-clearance/ip-
clearance-template.html. Also, the software grant form needs to be
acknowledged by the ASF secretary (or another ASF officer).

--kevan











Index: geronimo-2743-ibm-covalent-j2g.xml
===
--- geronimo-2743-ibm-covalent-j2g.xml  (revision 511944)
+++ geronimo-2743-ibm-covalent-j2g.xml  (working copy)
@@ -35,7 +35,7 @@
Project info
 

-   Which PMC will be responsible for the 
code  : Apache Geronimo
+   Which PMC will be responsible for the code  
: Apache Geronimo
 
   

@@ -59,15 +59,28 @@
 


-   Not Applicable
+January-16-2007
 
-  
-   
-   If applicable, make sure 
that any associated name does not already
-exist and check www.nameprotect.com to be sure that the name is not
-already trademarked for an existing software product.
-
+JIRA https://issues.apache.org/jira/browse/GERONIMO-2743";>GERONIMO-2743 
Created. 
+   https://issues.apache.org/jira/secure/attachment/12349176/Covalent-J2G-Tool.pdf"Covalent
 CCLA Attached
+   https://issues.apache.org/jira/secure/attachment/12349047/CCLA.tif";>IBM 
CCLA Attached
+   https://issues.apache.org/jira/secure/attachment/12349046/J2G-Migration-v2_src_1.0.0.zip";>Original
 codebase attached
+
+  
+  
+February-21-2007
+
+Copyright adjusted and https://issues.apache.org/jira/secure/attachment/12351724/J2G-Migration_2.0.0_src_20070220-1501.zip";>codebase
 cleaned up, ready for import 
+

+ 
+   February-21-2007
+   
+MD5 or SHA1 sum for donated software: 
+  3cfbefd2424c3556fdcbf162a1129399 
*J2G-Migration_2.0.0_src_20070220-1501.zip
+  e49e61df710dae15025b0126e4f8e672 *J2G-Migration-v2_src_1.0.0.zip
+  (Note versioned software used to calculate sum in parentheses).
+


Copyright
@@ -80,7 +93,7 @@
 


-   Not Yet Done.
+   Not yet done
 
Check and make sure 
that the papers that transfer rights to the ASF
 been received. It is only necessary to transfer rights for the
@@ -107,13 +120,13 @@
 


-   

[jira] Created: (XBEAN-76) Another NPE in ClassFinder

[David Jencks (JIRA)]

Another NPE in ClassFinder
--

 Key: XBEAN-76
 URL: https://issues.apache.org/jira/browse/XBEAN-76
 Project: XBean
  Issue Type: Bug
Affects Versions: 2.9
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 2.9


ClassFinder.readClassDef has a lot of opportunities  for NPEs.  I get them  
when I've constructed a ClassFinder for a geronimo war classloader, the missing 
paths are in WEB-INF/classes.

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

[jira] Commented: (XBEAN-74) ClassFinder NullPointerException

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/XBEAN-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475946
 ] 

David Jencks commented on XBEAN-74:
---

dblevins, can you figure out which rev this was applied in and add a comment? 
JIRA doesn't seem to be finding it automatically.

> ClassFinder NullPointerException
> 
>
> Key: XBEAN-74
> URL: https://issues.apache.org/jira/browse/XBEAN-74
> Project: XBean
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
>Priority: Minor
> Fix For: 3.0
>
> Attachments: GERONIMO-2833.patch
>
>
> Classes which are not part of a package will result in a null from the 
> class.getPackage() method, ultimately causing a NullPointerException

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

Re: svn commit: r511833 - /incubator/servicemix/trunk/pom.xml

[Terry Cox]

Author: gnodet Date: Mon Feb 26 06:53:33 2007 New Revision: 511833 
URL: http://svn.apache.org/viewvc?view=rev&rev=511833 Log: Remove 
continuum notifier


I guess you are probably on this already, but just in case, changing the 
pom hasn't fixed the problem because it's a svn issue:


Provider message: The svn command failed.
Command output:
---
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: Cannot replace a directory from within

Continuum can't get a new copy of the source including that pom change, 
 so it is still using the original copy. You may have to stop continuum 
and manually clean its build folder first to see if the problem is there 
or in svn.


Cheers,
--
Terry Cox
Meta-Concepts Ltd
0788 1920512

Re: no web.xml

[David Jencks]

On Feb 26, 2007, at 9:40 AM, Jarek Gawor wrote:


Hi,

I got a question on how things supposed to work if there is no web.xml
supplied. For example, in case of web services, there are certain
rules on how the web.xml file should get updated if the web.xml is not
present. That is, the servlet-name and servlet-class gets set to the
bean class name and the url-pattern is set to the
@WebService.serviceName value. Are there similar rules for pure
servlets? For example, if there is no web.xml file, should the module
builder scan all classes and check if a given class implements the
Servlet interface, etc. and update the web.xml appropriately? I can't
find a lot of information on this topic. Maybe it's just a special
case for web services?


I think so... someone found a spec reference recently that indicated  
that web.xml can be omitted only if there are no servlets or filters.


I think we're going to have to work harder to generate a web.xml when  
it's missing for these webservices.


thanks
david jencks



Thanks,
Jarek

no web.xml

[Jarek Gawor]

Hi,

I got a question on how things supposed to work if there is no web.xml
supplied. For example, in case of web services, there are certain
rules on how the web.xml file should get updated if the web.xml is not
present. That is, the servlet-name and servlet-class gets set to the
bean class name and the url-pattern is set to the
@WebService.serviceName value. Are there similar rules for pure
servlets? For example, if there is no web.xml file, should the module
builder scan all classes and check if a given class implements the
Servlet interface, etc. and update the web.xml appropriately? I can't
find a lot of information on this topic. Maybe it's just a special
case for web services?

Thanks,
Jarek

[jira] Created: (GERONIMO-2889) add support for resource injection in JSF Managed Beans

[Paul McMahan (JIRA)]

add support for resource injection in JSF Managed Beans
---

 Key: GERONIMO-2889
 URL: https://issues.apache.org/jira/browse/GERONIMO-2889
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.0-beta1
Reporter: Paul McMahan
Priority: Critical


According to the spec resource injection support is required for JSF managed 
beans.  The MyFaces 1.2 component currently does not support resource injection 
(or other annotations) but they are considering adding an InjectionProvider 
interface like in the RI that would allow Geronimo to pass resources after 
discovering them during deployment.

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

[jira] Updated: (GERONIMO-2876) Initial web service EJB support for Axis2

[Lin Sun (JIRA)]

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

Lin Sun updated GERONIMO-2876:
--

Attachment: G2876-2.patch

This updated patch contains the following:

- more formatting of axisservicegenerator file.   Add 2 methods in this file to 
generate wsdlDefinition when the wsdlFile is present in portinfo.  This is 
needed to get rid of axis2.PortInfo class as it creates inconvenience in the 
initial EJB support.

- Updated the Axis2Builder, Axix2WebServiceContainer, 
Axix2WebServiceContainerFactoryGbean, Axix2WebServiceContainerTest to reflect 
the change that axis2.PortInfo is gone.

- Added various config files for the intial support of EJB and the 
EJBWebServiceGBean.
I marked a todo there to forward the calls to openejb container.   

Able to build the patch with latest trunk today and tested with jaxws-ejb test 
case (1 out of 3 pass) and jaxws-war test case.  (2 out of 3 pass).

Lin

> Initial web service EJB support for Axis2
> -
>
> Key: GERONIMO-2876
> URL: https://issues.apache.org/jira/browse/GERONIMO-2876
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
> Environment: winxp + sun 1.5
>Reporter: Lin Sun
> Attachments: G2876-2.patch, G2876.patch
>
>
> This work-in-progress patch tried to port the initial web service ejb support 
> from CXF to Axis2 (G2850) and here are a few details:
> 1) I had a hard time with classexception while working through the two 
> portinfo classes (org.apache.geronimo.jaxws.PortInfo and 
> org.apache.geronimo.axis2.PortInfo) thus I am proposing to get rid of 
> org.apache.geronimo.axis2.PortInfo for simplicities.
> 2) I decided to keep the old Axis structure instead of the new CXF structure 
> for EJB support, as I envision that all the requests will be handled in one 
> Axis2WebServiceContainer. 
> Able to do a full build with the patch.Tested the patch with jax-ws-ejb 
> test.   For CXF, 2 out of 3 pass (same as before the patch).  For Axis2,  was 
> able to see the ejb module loaded and started.  However, get the jaxb error:
> 22:51:09,906 INFO  [JAXBUtils] Both ObjectFactory & package-info not found in 
> pa
> ckage hierachy
> 22:51:10,296 ERROR [Axis2WebServiceContainer] Exception occurred while trying 
> to
>  invoke service method doService()
> org.apache.axis2.AxisFault: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]; 
> nested e
> xception is:
> javax.xml.ws.WebServiceException: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:367)
> at 
> org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessa
> geReceiver.java:147)
> Will attempt to fix this tomorrow by supplying the generated ObjectFactory & 
> package-info classes for jax-ws-ejb test.
> Please let me know any comments you might have.

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

Re: 2.0-M3 Status

[Hernan Cunico]

the wiki seems to be back from the "undead".

here is the link to the release notes, I made some updates but need you guys to chime in 
and do the "fine tuning" ;-)

http://cwiki.apache.org/GMOxDOC20/release-notes-20-m3txt.html

WS needs validation and I don't really know how complete we are with EJB 3

I'm still having some problems with JIRA so the last part of the notes is 
missing, I'm working on it.

Cheers!
Hernan

Matt Hogstrom wrote:
I was finally able to get a build to complete on 2.0-M3.  The problem I 
was seeing (on old and new repos) is that for client-transaction and 
client-deployer and had to add a reference to the geronimo-ejb_3.0_spec 
dependency.  I'll work on the Car plugin to isolate this problem for the 
next cut but I think we're good for now.


Hernan, I think you mentioned you were pulling together the release 
notes.  Could you post what you have to the branches/2.0-M3 tree?  I'll 
pop out the binaries tomorrow to make available.


Start the creative juices flowing for what's in there folks :)

Re: Moving plugin-support bits out of Genesis into Mojo?

[Anita Kulshreshtha]

   I agree with Donald because this code (plugins/plugin-support) is
very closely tied to geronimo. Here is an example:
System.getProperties().remove("geronimo.bootstrap.logging.enabled");

Thanks
Anita
 
--- Donald Woods <[EMAIL PROTECTED]> wrote:

> The only concern, would be that we need multiple Geronimo commiters
> with 
> commit and release access to the dependent Mojo project, so we don't
> lie 
> in limbo when we need fixes/changes made to the plugin to support new
> 
> build requirements
> 
> 
> -Donald
> 
> Jason Dillon wrote:
> > Folks, I'm thinking about moving the plugin-support module out of 
> > Genesis and into the Mojo project. 

..
> > Does anyone object to moving these bits to the Mojo project?  I'm 
> > actually working on this at the moment, but if there are objections
> I 
> > will stop and we can discus more if needed.
> > 
> > --jason
> > 
> > 
> 



 

8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

Encoding Service Engine and JBI Mock Framework projects

[jlo_gestalt]

I wanted to inform developers of ServiceMix about two projects recently
open-sourced under the  https://open-jbi-components.dev.java.net/ Open JBI
Components  incubator project on  http://java.net/ java.net . The goal of
this project is to foster community-based development of JBI components that
conform to the Java Business Integration specification (JSR 208).

The  http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=EncodingSE Encoding
Service Engine  is a JBI component providing plug-n-play compression
capabilities to ESBs to improve performance between web services by
decreasing bandwidth consumption. The compression mechanism itself is
configurable and independent from the transport.  For example, one
configuration might use GZIP compression over HTTP and another might use
FastInfoset over SIP.

The  http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=JBIMockFramework JBI
Mock Framework  is a set of classes that allow developers to test JBI
Components at a unit level, mocking out the Normalized Message Router (NMR).

We are actively developing these components and are looking for developers
and testers.

For more information, please visit the 
https://open-jbi-components.dev.java.net/ Open JBI Components  project on
java.net.
-- 
View this message in context: 
http://www.nabble.com/Encoding-Service-Engine-and-JBI-Mock-Framework-projects-tf3293716s12049.html#a9161614
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: M3 Build Error: Axis2 tests

[Lin Sun]

Worked for me with the latest trunk and some local modification about to 
be attached as a patch (tho I don't think the modification made a 
difference).


---
 T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.578 sec
Running org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.563 sec

Results :
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0

Lin
Davanum Srinivas wrote:

Can you please post the surefire logs?

thanks,
dims

On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:


---
 T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.081 sec
<<< FAILURE!
Running
org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.242 sec
<<< FAILURE!

Results :
Tests run: 8, Failures: 0, Errors: 6, Skipped: 0

[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] There are test failures.
[INFO]

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

[INFO] Total time: 6 minutes 42 seconds
[INFO] Finished at: Mon Feb 26 08:16:02 EST 2007
[INFO] Final Memory: 87M/508M
[INFO]


-sachin

[jira] Commented: (GERONIMO-2846) modified jax-ws calculator sample to work with CXF and Axis2

[Lin Sun (JIRA)]

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

Lin Sun commented on GERONIMO-2846:
---

Hi, I am not seeing these two issues with jetty.  I am able to get a slightly 
different sample (jax-ws test) working with both CXF and Axis2.   The 
calculator sample is based on the jax-ws test so I don't expect to see a big 
issue.   I am using Friday's trunk with a few modifications for EJB.

Lin

> modified jax-ws calculator sample to work with CXF and Axis2
> 
>
> Key: GERONIMO-2846
> URL: https://issues.apache.org/jira/browse/GERONIMO-2846
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: sample apps
>Affects Versions: 2.0-M2
> Environment: winxp + sun jsk 1.5
>Reporter: Lin Sun
> Fix For: 2.0
>
> Attachments: jax-ws-calculator.zip
>
>
> Hi Dims,
> Per your request, here's the modified version of the sample.  
> Current issues:
> 1) I haven't been able to run the webservice client outside of my eclipse 
> env.   Getting CNF error if I ran the client as "java -jar 
> jaxws-calculator-1.0.jar".   This could be fixed by providing an ant script 
> or build the java execution into maven's pom.xml.
> 2) Running the Axis2 CalculatorClient client caused 
> Caused by: java.lang.ClassNotFoundException: com.sun.xml.ws.spi.ProviderImpl
>   at java.net.URLClassLoader$1.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>   at java.lang.ClassLoader.loadClass(Unknown Source)
>   at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:34)
>   ... 6 more
> I just added this client back in this morning so I probably have missed the 
> dependency for this one.   There are so many Axis2 dependencies so if you 
> know which one I need let me know.:)
> Running the Axis2 CalculatorClientAxiom client works fine.   
> Thanks, Lin

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

Geronimo has been listed on Count From Zero

[Olinga K . Abbott]

Hello!

Your software, Geronimo, has been selected for inclusion in Count From Zero 
(CFZ, http://www.countfromzero.com). CFZ indexes libraries and tools for 
software engineers. You will find the data CFZ publishes for Geronimo at 
http://www.countfromzero.com/package/Geronimo. This data includes
website: http://geronimo.apache.org/
version: 2.0-M2
date: 2007-01-30
If someone else could respond better to this message please forward it to them 
and/or let me know.

CFZ supports hierarchical categorization and multiple categories per software 
package. For example, if a user wants software for
part-of-speech tagging
they can find it under
artificial intelligence: natural language processing: part-of-speech 
tagging

(http://www.countfromzero.com/category/part-of-speech_tagging_POS_tagging)
and a package listed there might also be found under
artificial intelligence: natural language processing: shallow parsers
(http://www.countfromzero.com/category/shallow_parsers)
if applicable.

Please examine the page at http://www.countfromzero.com/package/Geronimo and 
reply to this message with
* corrections, such as new versions, improper categorization, or additional 
categories.
* a summary description (two lines)
* a full description (any length)
* software Geronimo depends on
* your real name if you feel comfortable providing it. CFZ requires your 
permission to release your name or email address unless under legal obligation.

CFZ is beta-stage and possesses many rough edges but I hope it will already 
prove beneficial to you and your users.

Sincerely,

Olinga K. Abbott
www.countfromzero.com
[EMAIL PROTECTED]

Re: Moving plugin-support bits out of Genesis into Mojo?

[Donald Woods]

The only concern, would be that we need multiple Geronimo commiters with 
commit and release access to the dependent Mojo project, so we don't lie 
in limbo when we need fixes/changes made to the plugin to support new 
build requirements



-Donald

Jason Dillon wrote:
Folks, I'm thinking about moving the plugin-support module out of 
Genesis and into the Mojo project.  A few plugins I maintain there 
already use some parts of this, but the classes were simply duplicated.


I'm also planning on updating the groovy-maven-plugin at the Mojo 
project to have the same features as the script-maven-plugin from 
Genesis, and that plugin uses a quite a bit of the support fluff in 
plugin-support.  I've talked to Jeff already about this and he seems 
fine with it.


Does anyone object to moving these bits to the Mojo project?  I'm 
actually working on this at the moment, but if there are objections I 
will stop and we can discus more if needed.


--jason




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Geronimo v2.0 Documentation - Administration

[Hernan Cunico]

Yeah, my bad. I got carried on with the doc and forgot what I said in my previous thread. 


Pls feel free to jump into the security configuration arena ;-)

Cheers!
Hernan

Karthiga Ratnam wrote:
Sorry Hernan, just some confusion in my thread. Since Adminstering the 
AG Server is already taken care of. I could work on "Configuring 
Security" , if no one is working on it.


I apologise for missing your last post.


Thanks

Karthiga

On 2/22/07, *Hernan Cunico* <[EMAIL PROTECTED] 
> wrote:


Karthiga,
I just realized I said I would only work on the first two bullets.

I just finished the whole "Administering the Apache Geronimo Server"
section.

To be consistent with previous docs I also created an
"Administrative tasks" and moved the content accordingly.

Sorry for the confusion, what other area would you like to work on
for the v2.0 doc?

Cheers!
Hernan

Hernan Cunico wrote:
 > Actually I was working on that topic. Left on "Adding new
listeners for
 > the Web containers"
 >
 > These are the topics covered in v1.2 under "Administering the Apache
 > Geronimo Server". I'll finish the two sections I started ("Adding new
 > listeners for the Web containers" and "Configure log level").
Feel free
 > to jump on any of the other topics ("Configuring a remote Apache HTTP
 > server", "Configuring the JMS server" ...)
 >
 > # Administering the Apache Geronimo Server
 >
 >* Adding new listeners for the Web containers
 >  o Add new AJP listener
 >  o Add new HTTP listener
 >  o Add new HTTPS listener
 >* Configure log level
 >  o Derby Log Viewer
 >  o Log Manager
 >  o Server Log Viewer
 >  o Web Access Log Viewer
 >* Configuring a remote Apache HTTP server
 >  o Configure Apache HTTPd as a reverse proxy (mod_proxy)
 >  o Configure Apache HTTPd with Jakarta Tomcat Connector
(mod_jk)
 >* Configuring the JMS server
 >* Display JVM information
 >* Monitor Server status
 >* Performance monitoring
 >* Starting and stopping the server
 >
 > Also, add any other topic you consider should be covered in this
(or any
 > other) section.
 >
 > Cheers!
 > Hernan
 >
 >
 > Karthiga Ratnam wrote:
 >> I'm in for covering the Adminstration series of articles. If no
one is
 >> working on it , I would like to cover the areas under "Adminstering
 >> the Apache Geronimo Server".
 >>
 >> Any other topics I can cover??
 >>
 >> Regards
 >>
 >> Karthiga
 >>
 >> On 2/20/07, *Hernan Cunico* < [EMAIL PROTECTED]

 >> >> wrote:
 >>
 >> - Continuing the discussion for topics to cover in the
Geronimo v2.0
 >> Documentation - Administration section -
 >>
 >> The idea is to use Geronimo's existing documentation as a topic
 >> guideline adding user input for new topics. So, pls chime in
with
 >> the topics you would like to see covered.
 >> It would be great to see volunteers too ;-)
 >>
 >> Here are some of the topics already covered:
 >>
 >> http://cwiki.apache.org/GMOxDOC20/administration.html
 >> >
 >>
 >> What other topics would you like to see covered?
 >>
 >> What areas you volunteer to work on? (rise your hand, don't
be shy,
 >> there are a couple of threads already showing volunteers to
work on
 >> documentation ;-)  )
 >>
 >> Cheers!
 >> Hernan
 >>
 >>
 >

Re: 2.0-M3 Status

[Hernan Cunico]

I do have some of the stuff for the release notes but not all. 
I didn't get any reply on the "what's new" thread so it's taking me a bit longer to get all the info consolidated.


Brutus (Confluence, JIRA, and friends) is down now so I can't make any updates 
to the wiki. I'll get the release notes in trunk and branches as soon as I can 
retrieve them from the wiki.

Cheers!
Hernan

Matt Hogstrom wrote:
I was finally able to get a build to complete on 2.0-M3.  The problem I 
was seeing (on old and new repos) is that for client-transaction and 
client-deployer and had to add a reference to the geronimo-ejb_3.0_spec 
dependency.  I'll work on the Car plugin to isolate this problem for the 
next cut but I think we're good for now.


Hernan, I think you mentioned you were pulling together the release 
notes.  Could you post what you have to the branches/2.0-M3 tree?  I'll 
pop out the binaries tomorrow to make available.


Start the creative juices flowing for what's in there folks :)

2.0-M3 - Building the release later today

[Matt Hogstrom]

Are there any outstanding issues with the branch that need to be  
resolved that anyone is aware of?  If not I'll cut the release for a  
vote this evening.

Re: Additional 'inverse' classloader view in Geronimo Console

[Paul McMahan]

Yes, I chair my own little PMC but unfortunately can't seem to keep
the committers from flaming each other.  You make it look so easy
Matt!  :-)

Best wishes,
Paul

On 2/26/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:


On Feb 25, 2007, at 6:48 PM, Paul McMahan wrote:

> Thanks for the patch Rakesh!  Looks great, I committed it.  With my
> daugther sitting on my lap trying to press keys

So now we know where the real work is generated from the in the
McMahan family :)

Build broken

[Terry Cox]

Hi,

Can someone fix the continuum reporting config as well as the build, 
please? It seems to be spitting out multiple copies of the error mails 
and flooding the list.


--
Terry Cox
Meta-Concepts Ltd

Re: M3 Build Error: Axis2 tests

[Davanum Srinivas]

Can you please post the surefire logs?

thanks,
dims

On 2/26/07, Sachin Patel <[EMAIL PROTECTED]> wrote:


---
 T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.081 sec
<<< FAILURE!
Running
org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.242 sec
<<< FAILURE!

Results :
Tests run: 8, Failures: 0, Errors: 6, Skipped: 0

[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] There are test failures.
[INFO]

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

[INFO] Total time: 6 minutes 42 seconds
[INFO] Finished at: Mon Feb 26 08:16:02 EST 2007
[INFO] Final Memory: 87M/508M
[INFO]


-sachin





--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

Re: 2.0-M3 Status

[Sachin Patel]

Matt,

I just posted a build error that we should resolve, its the same  
build error that Prasad posted on trunk.


-sachin


On Feb 25, 2007, at 11:26 PM, Matt Hogstrom wrote:

I was finally able to get a build to complete on 2.0-M3.  The  
problem I was seeing (on old and new repos) is that for client- 
transaction and client-deployer and had to add a reference to the  
geronimo-ejb_3.0_spec dependency.  I'll work on the Car plugin to  
isolate this problem for the next cut but I think we're good for now.


Hernan, I think you mentioned you were pulling together the release  
notes.  Could you post what you have to the branches/2.0-M3 tree?   
I'll pop out the binaries tomorrow to make available.


Start the creative juices flowing for what's in there folks :)

M3 Build Error: Axis2 tests

[Sachin Patel]

---
T E S T S
---
Running org.apache.geronimo.axis2.Axis2HandlerResolverTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.081  
sec <<< FAILURE!

Running org.apache.geronimo.axis2.Axis2WebServiceContainerTest
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.242  
sec <<< FAILURE!


Results :
Tests run: 8, Failures: 0, Errors: 6, Skipped: 0

[INFO]  


[ERROR] BUILD FAILURE
[INFO]  


[INFO] There are test failures.
[INFO]  


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


[INFO] Total time: 6 minutes 42 seconds
[INFO] Finished at: Mon Feb 26 08:16:02 EST 2007
[INFO] Final Memory: 87M/508M
[INFO]  




-sachin

Re: Geronimo Eclipse plugin for Apache Geronimo v1.0 only?

[Sachin Patel]

Hi Jacek, The download additional server adapters only pulls down  
published released adapters.  So currently support for 1.0, and 1.1.x  
can be downloaded.  For 2.0 I'm currently working on a driver, which  
I should hope to have available with our M3 milestone. But this won't  
be published to the update manager site and will be a download and  
extract installation procedure.


FYI WTP2.0M5 is currently very restricted in its EE5 capability.  For  
example, only the facet suppport is really there, and not any of the  
namespace support, thus none of the deployment descriptors will be  
generated if you create an EE5 project.  This is targeted for their M6.


I hope this helps.

-sachin


On Feb 25, 2007, at 4:21 PM, Jacek Laskowski wrote:


Hi,

Just installed WTP 2.0M5 in Eclipse IDE 3.3M5eh and downloaded the
Geronimo Eclipse plugin via "Download additional server adapters" in
the New Server panel. I had been thinking about Apache Geronimo v2,
but saw "Apache Geronimo v1.0 Server" beneath "Apache" category. I do
need geronimo v2, though.

Does the plugin support Apache Geronimo v2? How could I install the
current plugin? Build locally and create a extension location?

Jacek

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

[jira] Commented: (GERONIMO-2876) Initial web service EJB support for Axis2

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas commented on GERONIMO-2876:


Looks like i have to wait for a new patch :)

thanks,
dims

> Initial web service EJB support for Axis2
> -
>
> Key: GERONIMO-2876
> URL: https://issues.apache.org/jira/browse/GERONIMO-2876
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
> Environment: winxp + sun 1.5
>Reporter: Lin Sun
> Attachments: G2876.patch
>
>
> This work-in-progress patch tried to port the initial web service ejb support 
> from CXF to Axis2 (G2850) and here are a few details:
> 1) I had a hard time with classexception while working through the two 
> portinfo classes (org.apache.geronimo.jaxws.PortInfo and 
> org.apache.geronimo.axis2.PortInfo) thus I am proposing to get rid of 
> org.apache.geronimo.axis2.PortInfo for simplicities.
> 2) I decided to keep the old Axis structure instead of the new CXF structure 
> for EJB support, as I envision that all the requests will be handled in one 
> Axis2WebServiceContainer. 
> Able to do a full build with the patch.Tested the patch with jax-ws-ejb 
> test.   For CXF, 2 out of 3 pass (same as before the patch).  For Axis2,  was 
> able to see the ejb module loaded and started.  However, get the jaxb error:
> 22:51:09,906 INFO  [JAXBUtils] Both ObjectFactory & package-info not found in 
> pa
> ckage hierachy
> 22:51:10,296 ERROR [Axis2WebServiceContainer] Exception occurred while trying 
> to
>  invoke service method doService()
> org.apache.axis2.AxisFault: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]; 
> nested e
> xception is:
> javax.xml.ws.WebServiceException: javax.xml.bind.UnmarshalException
>  - with linked exception:
> [javax.xml.bind.UnmarshalException: unexpected element 
> (uri:"http://apache.org/g
> reeter_control/types", local:"greetMe"). Expected elements are (none)]
> at org.apache.axis2.AxisFault.makeFault(AxisFault.java:367)
> at 
> org.apache.axis2.jaxws.server.JAXWSMessageReceiver.receive(JAXWSMessa
> geReceiver.java:147)
> Will attempt to fix this tomorrow by supplying the generated ObjectFactory & 
> package-info classes for jax-ws-ejb test.
> Please let me know any comments you might have.

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

[jira] Commented: (GERONIMO-2888) Axis2WebServiceContainerTest getting failed due to missing libraries in the classpath

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas commented on GERONIMO-2888:


Fixed in svn revision  511793.

thanks,
dims

> Axis2WebServiceContainerTest getting failed due to missing libraries in the 
> classpath
> -
>
> Key: GERONIMO-2888
> URL: https://issues.apache.org/jira/browse/GERONIMO-2888
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Reporter: Lasantha Ranaweera
> Attachments: GERONIMO-2888.patch
>
>
> Geronimo Axis2 related Axis2WebServiceContainerTest getting failed due to the 
> missing libraries in the classpath when it get invokes. The given patch will 
> add to libraries to the pom.xml.
> Additionally includes the changes which were submitted under GERONIMO-2877 
> too.   

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

[jira] Resolved: (GERONIMO-2888) Axis2WebServiceContainerTest getting failed due to missing libraries in the classpath

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas resolved GERONIMO-2888.


Resolution: Fixed

> Axis2WebServiceContainerTest getting failed due to missing libraries in the 
> classpath
> -
>
> Key: GERONIMO-2888
> URL: https://issues.apache.org/jira/browse/GERONIMO-2888
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Reporter: Lasantha Ranaweera
> Attachments: GERONIMO-2888.patch
>
>
> Geronimo Axis2 related Axis2WebServiceContainerTest getting failed due to the 
> missing libraries in the classpath when it get invokes. The given patch will 
> add to libraries to the pom.xml.
> Additionally includes the changes which were submitted under GERONIMO-2877 
> too.   

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

[jira] Resolved: (GERONIMO-2877) Minor improvement to Axis2 Jaxws Integration

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas resolved GERONIMO-2877.


Resolution: Fixed

> Minor improvement to Axis2 Jaxws Integration
> 
>
> Key: GERONIMO-2877
> URL: https://issues.apache.org/jira/browse/GERONIMO-2877
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: webservices
>Reporter: Lasantha Ranaweera
>Priority: Minor
> Attachments: GERONIMO-2877-2.patch, GERONIMO-2877.patch
>
>
> This patch will improve the source code of the Axis2 JAXWS integration in 
> following areas.
> 1. Remove unnecessary Definition object used in the Axis2ServiceGenerator 
> class.
> 2. Source code formatting ( I am totally not sure this source code formatting 
> getting messing up. If somebody please point me out if this is due to a 
> problem of patches I have been submitting or not).
> Thanks,
> Lasantha

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

[jira] Commented: (GERONIMO-2877) Minor improvement to Axis2 Jaxws Integration

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas commented on GERONIMO-2877:


Applied as part of svn revision 511793 for GERONIMO-2888

thanks,
dims

> Minor improvement to Axis2 Jaxws Integration
> 
>
> Key: GERONIMO-2877
> URL: https://issues.apache.org/jira/browse/GERONIMO-2877
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: webservices
>Reporter: Lasantha Ranaweera
>Priority: Minor
> Attachments: GERONIMO-2877-2.patch, GERONIMO-2877.patch
>
>
> This patch will improve the source code of the Axis2 JAXWS integration in 
> following areas.
> 1. Remove unnecessary Definition object used in the Axis2ServiceGenerator 
> class.
> 2. Source code formatting ( I am totally not sure this source code formatting 
> getting messing up. If somebody please point me out if this is due to a 
> problem of patches I have been submitting or not).
> Thanks,
> Lasantha

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

[jira] Commented: (GERONIMO-2790) Remove Depricated addOperation from GBeans

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas commented on GERONIMO-2790:


Close as per submitter's comment.

-- dims

> Remove Depricated addOperation from GBeans
> --
>
> Key: GERONIMO-2790
> URL: https://issues.apache.org/jira/browse/GERONIMO-2790
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Lasantha Ranaweera
> Attachments: GERONIMO-2790.patch
>
>
> I saw lot of deprecated methods in every GBean. So following is a patch to 
> remove it.

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

[jira] Closed: (GERONIMO-2790) Remove Depricated addOperation from GBeans

[Davanum Srinivas (JIRA)]

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

Davanum Srinivas closed GERONIMO-2790.
--

Resolution: Fixed

> Remove Depricated addOperation from GBeans
> --
>
> Key: GERONIMO-2790
> URL: https://issues.apache.org/jira/browse/GERONIMO-2790
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Lasantha Ranaweera
> Attachments: GERONIMO-2790.patch
>
>
> I saw lot of deprecated methods in every GBean. So following is a patch to 
> remove it.

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

[BUILD] TRUNK: Failed for Revision: 511768

[prasad]

Building with Maven version: 2.0.5
Revision: 511768 built with tests included
See the full build-0500.log file at 
http://people.apache.org/~prasad/binaries/20070226/build-0500.log
 
242K downloaded
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/axis2-metadata/SNAPSHOT/axis2-metadata-20070226.010128-22.jar
331K downloaded
Downloading: 
http://tomcat.apache.org/dev/dist/m2-repository//commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
[WARNING] Unable to get resource 
'commons-fileupload:commons-fileupload:jar:1.1.1' from repository 
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading: 
http://ws.zones.apache.org/repository2//commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
[WARNING] Unable to get resource 
'commons-fileupload:commons-fileupload:jar:1.1.1' from repository axis2-m2-repo 
(http://ws.zones.apache.org/repository2/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
[WARNING] Unable to get resource 
'commons-fileupload:commons-fileupload:jar:1.1.1' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
[WARNING] Unable to get resource 
'commons-fileupload:commons-fileupload:jar:1.1.1' from repository codehaus 
(http://repository.codehaus.org)
Downloading: 
http://ws.zones.apache.org/repository2//commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
[WARNING] Unable to get resource 
'commons-fileupload:commons-fileupload:jar:1.1.1' from repository 
apache-ws-snapshots2 (http://ws.zones.apache.org/repository2/)
Downloading: 
http://repo1.maven.org/maven2//commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar
31K downloaded
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/axis2-java2wsdl/SNAPSHOT/axis2-java2wsdl-20070226.070055-38.jar
53K downloaded
Downloading: 
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
[WARNING] Unable to get resource 
'org.apache.httpcomponents:jakarta-httpcore:jar:4.0-alpha3' from repository 
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading: 
http://ws.zones.apache.org/repository2//org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
[WARNING] Unable to get resource 
'org.apache.httpcomponents:jakarta-httpcore:jar:4.0-alpha3' from repository 
axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
[WARNING] Unable to get resource 
'org.apache.httpcomponents:jakarta-httpcore:jar:4.0-alpha3' from repository 
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
[WARNING] Unable to get resource 
'org.apache.httpcomponents:jakarta-httpcore:jar:4.0-alpha3' from repository 
codehaus (http://repository.codehaus.org)
Downloading: 
http://ws.zones.apache.org/repository2//org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
[WARNING] Unable to get resource 
'org.apache.httpcomponents:jakarta-httpcore:jar:4.0-alpha3' from repository 
apache-ws-snapshots2 (http://ws.zones.apache.org/repository2/)
Downloading: 
http://repo1.maven.org/maven2//org/apache/httpcomponents/jakarta-httpcore/4.0-alpha3/jakarta-httpcore-4.0-alpha3.jar
125K downloaded
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/axis2-jaxws/SNAPSHOT/axis2-jaxws-20070226.010128-8.jar
348K downloaded
Downloading: 
http://tomcat.apache.org/dev/dist/m2-repository//xerces/xmlParserAPIs/2.6.0/xmlParserAPIs-2.6.0.jar
[WARNING] Unable to get resource 'xerces:xmlParserAPIs:jar:2.6.0' from 
repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading: 
http://ws.zones.apache.org/repository2//xerces/xmlParserAPIs/2.6.0/xmlParserAPIs-2.6.0.jar
[WARNING] Unable to get resource 'xerces:xmlParserAPIs:jar:2.6.0' from 
repository axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//xerces/xmlParserAPIs/2.6.0/xmlParserAPIs-2.6.0.jar
[WARNING] Unable to get resource 'xerces:xmlParserAPIs:jar:2.6.0' from 
repository apache-incubator 
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading: 
http://repository.codehaus.org/xerces/xmlParserAPIs/2.6.0/xmlParserAPIs-2.6

New Axis2 Test Framework Patch

[Lasantha Ranaweera]

Hi Guys,

There is a patch submitted under GERONIMO-2888 for a bug waiting for 
review. Please somebody review it becos it might affect the overall 
build of the G.


Thanks,
Lasantha

[jira] Updated: (GERONIMO-2888) Axis2WebServiceContainerTest getting failed due to missing libraries in the classpath

[Lasantha Ranaweera (JIRA)]

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

Lasantha Ranaweera updated GERONIMO-2888:
-

Attachment: GERONIMO-2888.patch

> Axis2WebServiceContainerTest getting failed due to missing libraries in the 
> classpath
> -
>
> Key: GERONIMO-2888
> URL: https://issues.apache.org/jira/browse/GERONIMO-2888
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Reporter: Lasantha Ranaweera
> Attachments: GERONIMO-2888.patch
>
>
> Geronimo Axis2 related Axis2WebServiceContainerTest getting failed due to the 
> missing libraries in the classpath when it get invokes. The given patch will 
> add to libraries to the pom.xml.
> Additionally includes the changes which were submitted under GERONIMO-2877 
> too.   

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

[jira] Created: (GERONIMO-2888) Axis2WebServiceContainerTest getting failed due to missing libraries in the classpath

[Lasantha Ranaweera (JIRA)]

Axis2WebServiceContainerTest getting failed due to missing libraries in the 
classpath
-

 Key: GERONIMO-2888
 URL: https://issues.apache.org/jira/browse/GERONIMO-2888
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: webservices
Reporter: Lasantha Ranaweera


Geronimo Axis2 related Axis2WebServiceContainerTest getting failed due to the 
missing libraries in the classpath when it get invokes. The given patch will 
add to libraries to the pom.xml.

Additionally includes the changes which were submitted under GERONIMO-2877 too. 
  

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

[jira] Created: (SM-857) java:comp/env/ environment is read-only - Could not start ClientFactory javax.naming.NamingException

[Alper Sogukpinar (JIRA)]

java:comp/env/ environment is read-only  - Could not start ClientFactory 
javax.naming.NamingException
-

 Key: SM-857
 URL: https://issues.apache.org/activemq/browse/SM-857
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.1
 Environment: both Tomcat 5.5 and WAS 6.1 
Reporter: Alper Sogukpinar


As far as I know  java:comp/env/ environment is read-only at runtime according 
to J2EE spec. Because of that it generates errror on start and stop methods of 
org.apache.servicemix.jbi.framework.ClientFactory class.

I use Servicemix 3.1 in a web application and its configuration is very similar 
to configuration of "servicemix-web" example.
When application starts  I see exceptions which are taken from start and stop 
methods of org.apache.servicemix.jbi.framework.ClientFactory class.
ClientFactory fails while binding itself to the namingContext and while 
unbinding from the context.

I tested my application both in Tomcat 5.5 and Websphere 6.1. I see the similar 
logs for both. 
I also tested "servicemix-web" example with Tomcat 5.5 and I see the logs for 
"servicemix-web" example, too.

In addition to these, warning messages in the stop and start methods are 
misspelled: (org.apache.servicemix.jbi.framework.ClientFactory)
logger.warn("Cound not start ClientFactory: " + e); > logger.warn("Could 
not start ClientFactory: " + e);
logger.warn("Cound not stop ClientFactory: " + e); >logger.warn("Could not 
stop ClientFactory: " + e);

**WAS 6.1**
Context name: java:
Target name: java:comp/env/jbi/ClientFactory
Other data: Object to bind: [EMAIL PROTECTED]
Exception stack trace: javax.naming.OperationNotSupportedException: 
The operation on the context "java:comp/env/jbi/ClientFactory" cannot be 
completed.  
All contexts under java:comp/env are environment contexts and are read-only.
at 
com.ibm.ws.naming.java.javaURLContextImpl.isThisContextUpdatable(javaURLContextImpl.java:238)
at 
com.ibm.ws.naming.urlbase.UrlContextImpl.bind(UrlContextImpl.java:210)
at 
com.ibm.ws.naming.urlbase.UrlContextImpl.bind(UrlContextImpl.java:344)
at javax.naming.InitialContext.bind(InitialContext.java:371)
at 
org.apache.servicemix.jbi.framework.ClientFactory.start(ClientFactory.java:84)
at 
org.apache.servicemix.jbi.container.JBIContainer.start(JBIContainer.java:597)
at 
org.apache.servicemix.jbi.container.SpringJBIContainer.afterPropertiesSet(SpringJBIContainer.java:79)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1057)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1024)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:421)
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:245)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:140)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:242)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156)
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346)
at 
org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156)
at 
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246)
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184)
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
at 
com.ibm.ws.wswebcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:621)
at 
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:275)
at com.ibm.ws.wswebcontainer.webapp.WebApp.initialize(WebApp.java:273)
at 
com.ibm.ws.wswebcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:88)
at 
com.ibm.ws.wswebcontainer.VirtualHost.addWebApplication(VirtualHost.java:157)
at 
com.ibm.ws.wswebcontainer.WebContainer.addWebApp(WebContainer.java:655)
at 
com.ibm.ws.wswebcontainer.WebContainer.a

[jira] Updated: (GERONIMO-2887) Hook up injections for jetty and app client

[David Jencks (JIRA)]

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

David Jencks updated GERONIMO-2887:
---

Attachment: GERONIMO-2887.patch

Early version for jetty.  There's a problem finding remote ejb references still 
to work out, the @Remote and @Local annotations are on the bean class, not the 
interface, and these bean classes aren't being looked at by out ClassFinder.

> Hook up injections for jetty and app client
> ---
>
> Key: GERONIMO-2887
> URL: https://issues.apache.org/jira/browse/GERONIMO-2887
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 2.0
>
> Attachments: GERONIMO-2887.patch
>
>
> Now all the annotations are getting put into the xml dd.  We need to actually 
> use this info to do the injections for jetty and the app client.

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

[jira] Created: (GERONIMO-2887) Hook up injections for jetty and app client

[David Jencks (JIRA)]

Hook up injections for jetty and app client
---

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


Now all the annotations are getting put into the xml dd.  We need to actually 
use this info to do the injections for jetty and the app client.

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