Re: Move trunk, tags and branches to server/*
+1On 8/16/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I think we should move the top-level trunk, tags and branches toserver/*. This will make the top-level of our repository moreconsistent.Specifically, I think we should:svn mkdir https://svn.apache.org/repos/asf/geronimo/serversvn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tagssvn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunksvn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branchesAnd then update the pom's in server/trunk to reflect the new locationfor scm tags.--jason-- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMODEVTOOLS-100) publishing hundreds of web projects / dependencies - GUI usability
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-100?page=comments#action_12428324 ] Oleg Gusakov commented on GERONIMODEVTOOLS-100: --- This issue, though reported as critical is a real show stopper for us. If we cannot efficiently publish 2-3 hundred applications, using the plugin does not make too much sense. What kind of metadata can we use to create a hierarchy out of those projects? Maybe go by dependency graph and publish/remove projects by dependency layers? What kind of metadata could be added to a project via WTP features? > publishing hundreds of web projects / dependencies - GUI usability > -- > > Key: GERONIMODEVTOOLS-100 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-100 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k >Reporter: Oleg Gusakov >Priority: Critical > > When there are several hundred projects, publishing/removing them from > Geronimo becomes a tedious task. > We need a clearer GUI to address that, probably some kind of hierarchical > markup in the project metadata. Or combine that with Maven POM metadata ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2328) Why GBeans - reinventing the wheel?
Why GBeans - reinventing the wheel? --- Key: GERONIMO-2328 URL: http://issues.apache.org/jira/browse/GERONIMO-2328 Project: Geronimo Issue Type: Wish Security Level: public (Regular issues) Affects Versions: Wish List Reporter: Oleg Gusakov Guys - why spend time reinventing the wheen with GBean container? One of the key values of Geronimo was stated as "bring the best of open technologies together rather than rewriting them". And one of the most fundamental features - initialization/configuration container - writing it from scratch and making all errors once again? Containers have been around since early days of civilization - pico and nano containers, JBoss'es MBeans, microcontainer, Spring to name a few And the father of them all - plexus: has been around for a decade - simple, reliable, proven. Why not just take plexus and spend efforts on something really new and exiting? You use Maven for the build, so you already have some kind of exposure to it. Throw in classwords - and Geronimo rules! No headaches from half cooked products. And not deviating from the stated principles :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Graduate to a TLP?
+1 from me, too david jencks On Aug 1, 2006, at 9:14 AM, Brian McCallister wrote: I'd like to start the ball rolling to have ActiveMQ graduate to a top level project at Apache. The original intent was to become a sub-project of Geronimo, but I think that this would be a disservice to ActiveMQ, which is quite capable of standing on it's own, and therefore, should be a project in itsef rather than expanding the G umbrella. Looking over the incubator checklist, everything seems to have been completed, we have been making releases (a good sign that a project has it together) and I do believe it is time :-) Thoughts? -Brian
[jira] Created: (GERONIMO-2327) Need to encode colons for JACC web permissions
Need to encode colons for JACC web permissions -- Key: GERONIMO-2327 URL: http://issues.apache.org/jira/browse/GERONIMO-2327 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1.1, 1.2 Reporter: Alan Cabrera Assigned To: Alan Cabrera Fix For: 1.1.1, 1.2 Need to encode colons for JACC web permissions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Graduate to a TLP?
On 8/1/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
I'd like to start the ball rolling to have ActiveMQ graduate to a top
level project at Apache.
The original intent was to become a sub-project of Geronimo, but I
think that this would be a disservice to ActiveMQ, which is quite
capable of standing on it's own, and therefore, should be a project
in itsef rather than expanding the G umbrella.
Looking over the incubator checklist, everything seems to have been
completed, we have been making releases (a good sign that a project
has it together) and I do believe it is time :-)
+1 to graduation and +1 to TLP status.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Move trunk, tags and branches to server/*
On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I think we should move the top-level trunk, tags and branches to
server/*. This will make the top-level of our repository more
consistent.
Specifically, I think we should:
svn mkdir https://svn.apache.org/repos/asf/geronimo/server
svn mv https://svn.apache.org/repos/asf/geronimo/tags https://
svn.apache.org/repos/asf/geronimo/server/tags
svn mv https://svn.apache.org/repos/asf/geronimo/trunk https://
svn.apache.org/repos/asf/geronimo/server/trunk
svn mv https://svn.apache.org/repos/asf/geronimo/branches https://
svn.apache.org/repos/asf/geronimo/server/branches
And then update the pom's in server/trunk to reflect the new location
for scm tags.
+1
This has been needed or a while.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
[jira] Commented: (GERONIMODEVTOOLS-99) need to publish web project dependencies outside of WAR
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99?page=comments#action_12428320 ] Oleg Gusakov commented on GERONIMODEVTOOLS-99: -- added a comment to GERONIMO-1526 > need to publish web project dependencies outside of WAR > --- > > Key: GERONIMODEVTOOLS-99 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, 32/64 bit >Reporter: Oleg Gusakov > Assigned To: Sachin Patel >Priority: Blocker > Fix For: 1.x > > > In our use case for geronimo plugin we need to be able to deploy WAR project > dependencies outside of WAR. The best place seems to SharedLib deployer. > Dependencies to deploy include: > - Eclipse WAR project references to other Eclipse projects > - external JAR files, attached to the project and/ot it's dependencies > - external dependencies supplied by Maven plugin from project's POM file. > This is almost identical to the previous one. > All dependencies need to be deployed "in place" for efficiency reasons. > Binary dependencies do not change often and can reside in one classloader. > Eclipse projects, on the other hand, change a lot and could be subjected to > hot redeployment, so they probably should reside in their own set of > classloaders. > Please consider for implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1526) Allow module builders to support building configuraiton from non-j2ee structure.
[
http://issues.apache.org/jira/browse/GERONIMO-1526?page=comments#action_12428319
]
Oleg Gusakov commented on GERONIMO-1526:
If you look at the issue from a little wider angle - it has nothing to do with
any "exceptions" to JavaEE structure. JavaEE defines resolution structure for
some pre-defined module types - EAR, WAR. But it also adhears to JavaSE
classloading mechanism: looking for a class - ask parent classloader. Of cause
- we made it more flexible here by allowing to first check module's classloader
cache as an option.
So in essence what's stated here as well as in GERONIMODEVTOOLS-99 which seems
to be blocked because of this one - make regular module builder flexible, able
to resolve resources from either remote folder ("in-place deployment") and most
problems go away.
The only real issue that may need to be solved - in IDE environment standard
EAR or WAR structure may be split into physically different locations before
it's finalized by the build process. In this case module builder has to do real
"building" - assemble those pieces togerther into a compiant structure. The
easiest solution to that might be, say, using OS level hack - symbolic links on
the filesystem level. (Don't know if it's possible unde windows, though)
> Allow module builders to support building configuraiton from non-j2ee
> structure.
>
>
> Key: GERONIMO-1526
> URL: http://issues.apache.org/jira/browse/GERONIMO-1526
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 1.1.1
>Reporter: Sachin Patel
>Priority: Critical
> Fix For: 1.x
>
>
> See the section Geronimo Runtime Requirements in the link for a detailed
> description
> http://cwiki.apache.org/GMOxDOC11/geronimo-eclipse-plugin-development-roadmap.html
> In summary...
> - The module builders should not assume and cannot be passed in a jar file.
> - The module builders should not locate resources by assuming that the root
> location passed in is an J2EE file structure
> - Need to provide an abstraction of an ear/module one impl which would be by
> default is a J2EE structure, otherwise support a pluggable method to allow
> support for different IDEs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12428302 ] Paul McMahan commented on GERONIMO-2326: Seems to only be a problem in the jetty assembly. Tomcat works ok. > unable to deploy a database pool > > > Key: GERONIMO-2326 > URL: http://issues.apache.org/jira/browse/GERONIMO-2326 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.2, 1.1.1 >Reporter: Bill Dudney > > Trying to deploy a jdbc datasource leads to a blank screen and the following > stack trace in the log. > The issue appears to be that URLPatternSpec does not like the URL generated > by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES > array. > java.lang.IllegalArgumentException: Qualifier patterns must be present when > first URLPattern is an exact pattern > at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) > at > javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:83) > at > org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Graduate to a TLP?
+1's from: Guillaume Nodet James Strachan Rob Davies Aaron Mulder Hiram Chirino Alan Cabrera Dain Sundstrom Jason Dillon Adrian Co David Jencks Brian McCallister No -1 or 0 votes cast. I'll start drafting something for the incubator vote. -Brian On Aug 1, 2006, at 9:14 AM, Brian McCallister wrote: I'd like to start the ball rolling to have ActiveMQ graduate to a top level project at Apache. The original intent was to become a sub-project of Geronimo, but I think that this would be a disservice to ActiveMQ, which is quite capable of standing on it's own, and therefore, should be a project in itsef rather than expanding the G umbrella. Looking over the incubator checklist, everything seems to have been completed, we have been making releases (a good sign that a project has it together) and I do believe it is time :-) Thoughts? -Brian
Re: Graduate to a TLP?
+1 from me :-) On Aug 1, 2006, at 9:14 AM, Brian McCallister wrote: I'd like to start the ball rolling to have ActiveMQ graduate to a top level project at Apache. The original intent was to become a sub-project of Geronimo, but I think that this would be a disservice to ActiveMQ, which is quite capable of standing on it's own, and therefore, should be a project in itsef rather than expanding the G umbrella. Looking over the incubator checklist, everything seems to have been completed, we have been making releases (a good sign that a project has it together) and I do believe it is time :-) Thoughts? -Brian
[jira] Resolved: (SM-542) NPE occurs in ODE-BPE when undeploying and redeploying the loan broker demo.
[ https://issues.apache.org/activemq/browse/SM-542?page=all ] Adrian Co resolved SM-542. -- Resolution: Fixed fixed. > NPE occurs in ODE-BPE when undeploying and redeploying the loan broker demo. > > > Key: SM-542 > URL: https://issues.apache.org/activemq/browse/SM-542 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-bpe >Affects Versions: 3.0-M2 >Reporter: Adrian Co > Assigned To: Adrian Co > Fix For: 3.0-M3 > > > NPE occurs in the ODE-BPE class when undeploying, redeploying, and then > running the loan broker demo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move trunk, tags and branches to server/*
+1, it's gotten a bit awkward the way we have it now. -David On Aug 15, 2006, at 3:03 PM, Jason Dillon wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: Console JACC Security Error in 1.1.1
I found the problem and will fix it tonight. Regards, Alan Aaron Mulder wrote: I'm not sure if this is related to the recent web app security fix or not. I hacked the build enough that I got the 1.1.1 server running. I went to the console, went to the database pool screen, selected that I wanted to create a new pool, filled out the name and DB type on that screen and hit submit, and got the error below. I have no idea why it only came up on that submission and not any of the previous ones (though it was the first POST request I think). Thanks, Aaron 18:19:51,940 WARN [/console] /console/portal/services/services_jdbc/_rp_services_jdbc_row1_col1_p1_adapterDisplayName/1_TranQL0x8Generic0x8JDBC0x8Resource0x8Adapter/_rp_services_jdbc_row1_col1_p1_rarPath/1_tranql0x3tranql-connector0x310x220x3rar/_rp_services_jdbc_row1_col1_p1_mode/1_params/_rp_services_jdbc_row1_col1_p1_driverClass/1_com0x2mysql0x2jdbc0x2Driver/_pm_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_dbtype/1_MySQL/_rp_services_jdbc_row1_col1_p1_urlPrototype/1_jdbc%3Amysql%3A0x30x3%7BHost%7D%3A%7BPort%7D0x3%7BDatabase%7D/_st_services_jdbc_row1_col1_p1/normal/_ps_services_jdbc_row1_col1_p1/normal/_pid/services_jdbc_row1_col1_p1/_md_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_name/1_JPAPool: java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:83) at org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:194) at org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:607) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Re: JPA Plugin Status
Grrr, I'm missing mail again -- pulled it from the archives. Thanks, Dain, for pointing out there was a message for me. On 8/15/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > David, > > I am releasing the specs as a 1.1.1 release due to some changes in jacc. Do you want to include the > changes to JPA there? That would be great. In fact all the jee5_exp specs could be released. The related specifications went final so we should be good to go. -David On Aug 15, 2006, at 4:17 AM, David Blevins wrote: I got OpenJPA to run with my JPA code. So we're looking real good. On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had some bad signatures and was missing a few exception classes. I fixed those and managed to get OpenJPA to compile and run with our JPA jar rather than the CDDL version they use. If you try to build and run this, you'll be held up by a couple things: For me its: - Still missing the some JNDI stuff Dain is working on (mentioned earlier in the thread). - Need the plugin goop But when that is there, this should run for ejbs or servlets in 1.1.1 and maybe 1.1 (should work). My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. I'm sure we can figure something out. I'll give it some more thought tomorrow, time for bed now -David
Re: Move trunk, tags and branches to server/*
+1...good first step Jason Dillon wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https://svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https://svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https://svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Possible blocker for 1.1.1 -- console broken
Bill Dudney found a problem with the console -- see GERONIMO-2326I've been able to reproduce it on branches/1.1 so I expect it is also a problem on 1.1.1. I think the problem only occurs when you try to deploy a non-xa driver, which then includes a database url with lots of colons in the servlet/portlet url. These colons don't work with the new fixes alan put in to the web app security.I think the solution is to encode the db urls, but I'm not sure when the url is being constructed nor if the encoding should be our responsibility or pluto's If any console experts such as Aaron have any ideas that would be great.As a completely separate issue it looks like the work in rev 412804 did not make it into trunk... I'm getting worried about drift between the versions.thanksdavid jencks
Re: Move trunk, tags and branches to server/*
On Aug 15, 2006, at 5:03 PM, Dain Sundstrom wrote: +1 to Jason's original proposal I agree david jencks -dain On Aug 15, 2006, at 3:17 PM, Jason Dillon wrote: I have not read anything to that affect... and would not recommend doing that. Top-level directories with the standard svn trunk, tags and branches is what I think will work out best for the long run. --jason On Aug 15, 2006, at 3:07 PM, Aaron Mulder wrote: Sounds OK to me, though I thought there had been some talk about something more like trunk/server trunk/other trunk/another server/branches server/tags other/branches other/tags another/branches another/tags Or something like that -- where all the trunks were together but all the branches and tags were separate. Or am I making that up? Thanks, Aaron On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ]
David Jencks updated GERONIMO-2326:
---
Affects Version/s: 1.1.1
I've just reproduced the problem on branches/1.1 trying for a derby embedded
pool. I think the problem is the same in both versions. Most likely xa pools
won't have this problem (derby network xa didnt for me)
IMO the problem is that we are generating URLs that have : characters in them
from the jdbc url: here's an example:
RequestURI=/console/portal/services/services_jdbc/_rp_services_jdbc_row1_col1_p1_adapterDisplayName/1_TranQL0x8Generic0x8JDBC0x8Resource0x8Adapter/_rp_services_jdbc_row1_col1_p1_rarPath/1_tranql0x3tranql-connector0x310x220x3rar/_rp_services_jdbc_row1_col1_p1_mode/1_params/_rp_services_jdbc_row1_col1_p1_driverClass/1_org0x2apache0x2derby0x2jdbc0x2EmbeddedDriver/_pm_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_dbtype/1_Derby0x8embedded/_rp_services_jdbc_row1_col1_p1_urlPrototype/1_jdbc:derby:{Database}/_st_services_jdbc_row1_col1_p1/normal/_ps_services_jdbc_row1_col1_p1/normal/_pid/services_jdbc_row1_col1_p1/_md_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_name/1_test2
Here's the bad part:
1_p1_urlPrototype/1_jdbc:derby:{Database}
I think the solution is likely to be to encode this stuff. I haven't figured
out if we or pluto should be doing the encoding
> unable to deploy a database pool
>
>
> Key: GERONIMO-2326
> URL: http://issues.apache.org/jira/browse/GERONIMO-2326
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.2, 1.1.1
>Reporter: Bill Dudney
>
> Trying to deploy a jdbc datasource leads to a blank screen and the following
> stack trace in the log.
> The issue appears to be that URLPatternSpec does not like the URL generated
> by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES
> array.
> java.lang.IllegalArgumentException: Qualifier patterns must be present when
> first URLPattern is an exact pattern
> at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98)
> at
> javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:83)
> at
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322)
> at
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:552)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2326) unable to deploy a database pool
unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move trunk, tags and branches to server/*
+1 to Jason's original proposal -dain On Aug 15, 2006, at 3:17 PM, Jason Dillon wrote: I have not read anything to that affect... and would not recommend doing that. Top-level directories with the standard svn trunk, tags and branches is what I think will work out best for the long run. --jason On Aug 15, 2006, at 3:07 PM, Aaron Mulder wrote: Sounds OK to me, though I thought there had been some talk about something more like trunk/server trunk/other trunk/another server/branches server/tags other/branches other/tags another/branches another/tags Or something like that -- where all the trunks were together but all the branches and tags were separate. Or am I making that up? Thanks, Aaron On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
[jira] Commented: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=comments#action_12428272 ] Bill Dudney commented on GERONIMO-2325: --- to test the patch - 1) start the server 2) log into the console 3) deploy new 4) choose any deployable jar file (i was using modules/j2ee-builder/target/test-ear14/test-ejb-jar.jar) if you get an error about the DefaultDatasource not found the patch worked if you get a stack trace on the console with a ClassNotFoundException the patch did not work > unable to deploy from console with m2 build > --- > > Key: GERONIMO-2325 > URL: http://issues.apache.org/jira/browse/GERONIMO-2325 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Attachments: 2325-console.patch > > > deploy-new is unable to deploy anything with the m2 build because of missing > dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=all ] Jason Dillon reassigned GERONIMO-2325: -- Assignee: Jason Dillon > unable to deploy from console with m2 build > --- > > Key: GERONIMO-2325 > URL: http://issues.apache.org/jira/browse/GERONIMO-2325 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Jason Dillon > Attachments: 2325-console.patch > > > deploy-new is unable to deploy anything with the m2 build because of missing > dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2325) unable to deploy from console with m2 build
[ http://issues.apache.org/jira/browse/GERONIMO-2325?page=all ] Bill Dudney updated GERONIMO-2325: -- Attachment: 2325-console.patch apply the patch from geronimo > unable to deploy from console with m2 build > --- > > Key: GERONIMO-2325 > URL: http://issues.apache.org/jira/browse/GERONIMO-2325 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: Bill Dudney > Attachments: 2325-console.patch > > > deploy-new is unable to deploy anything with the m2 build because of missing > dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2325) unable to deploy from console with m2 build
unable to deploy from console with m2 build --- Key: GERONIMO-2325 URL: http://issues.apache.org/jira/browse/GERONIMO-2325 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney deploy-new is unable to deploy anything with the m2 build because of missing dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=all ] David Jencks resolved GERONIMO-2313. Fix Version/s: 1.1.2 Resolution: Fixed Sample app works, lets see if I can get the user who found the problem to test this out. > Subject not propagated correctly between web app and ejb > > > Key: GERONIMO-2313 > URL: http://issues.apache.org/jira/browse/GERONIMO-2313 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1, 1.1.1, 1.1.x >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.1.2, 1.2 > > Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, > GERONIMO-2313-openejb.diff, GERONIMO-2313.diff > > > With a web app with security, that calls an ejb, isCallerInRole in the ejb > always returns false. > this is caused by the web app not setting nextCaller and the ejb interceptors > shifting nextCaller to currentCaller, so when the isCallerInRole is tested > there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 3)
+1 On 15 Aug 2006, at 21:42, Brian McCallister wrote: +1 -Brian On Aug 8, 2006, at 1:35 PM, Hiram Chirino wrote: Some NOTICE file issues were found in the 2nd release candidate of the 4.0.2 build. I have cut and RC 3 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=comments#action_12428262 ] David Jencks commented on GERONIMO-2313: Alan agrees that this is a reasonable direction to go in to fix this problem. G trunk rev 431706 openejb2 trunk rev 2854 Merging with 1.1 required some manual work, much of it from the TCM removal and openejb configuration work dain did. The sample/test app attached works properly with the 1.1 modifications. G 1.1 branch rev 431735 openejb2 2.1 branch rev 2855 > Subject not propagated correctly between web app and ejb > > > Key: GERONIMO-2313 > URL: http://issues.apache.org/jira/browse/GERONIMO-2313 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1, 1.1.1, 1.1.x >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, > GERONIMO-2313-openejb.diff, GERONIMO-2313.diff > > > With a web app with security, that calls an ejb, isCallerInRole in the ejb > always returns false. > this is caused by the web app not setting nextCaller and the ejb interceptors > shifting nextCaller to currentCaller, so when the isCallerInRole is tested > there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: TCK, Trunk & M2
On Aug 15, 2006, at 4:30 PM, Alan D. Cabrera wrote: Seriously, I'm not sure what I can mention on a public list. Are you on the TCK list? Yup, if you know... please post it to that list. --jason
Re: XBean and QDox
Sweet. This will be nice. Regards, Alan Dain Sundstrom wrote: Yep is just works. -dain On Aug 14, 2006, at 7:27 PM, Dan Diephouse wrote: Alan D. Cabrera wrote: James Strachan wrote: On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. Can I debug retrotranslated code in JDK14? Regards, Alan Yes. Dain did a whole bunch of experiments on this if you want to know more details. From what I understand they went quite well. - Dan --Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: TCK, Trunk & M2
Jason Dillon wrote: What needs to be done to get the the TCK running on m2 builds of trunk? Lets wrap that up and nuke the m1 build. --jason I could tell you but then I would have to kill you. :) Seriously, I'm not sure what I can mention on a public list. Are you on the TCK list? Regards, Alan
Re: JIRA Permissions
Hi Tim and welcome. I've added you to the Geronimo-contributors group. This should allow you to assign JIRA's to yourself. Please remember to communicate on the dev list (dev@geronimo.apache.org) about what you are working on and use that same channel for collaborating with other developers. Version 1.1.1 is currently closed and the JIRA's there will be moved out to a later version number. Is there some area of interest you have in Geronimo? Tim McConnell wrote: Hi, I'm new to the Geronimo project and would like to start working on JIRA issues to help expedite my learning curve. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the Geronimo project ?? Thanks much. Tim McConnell
1.1.1 Status (rc1 coming)
We have worked through the build issues and have an rc1 ready for review. I am waiting for the TCK to finish on it this evening and will make the first rc available tomorrow or so. Apologies for the delays but there were some last minute JIRAs and some issues with packaging of the jars that needed to be addressed. Hopefully each new release will be getting easier. 1.1.1 is almost there. Thanks and look for an announce tomorrow.
Re: New car-maven-plugin issue
Trying to build a plugin to integrate ServiceMix in G 1.1,i' ve just seen that the deployer is unable to handle snapshots in m2 repo, as they are deployed with a timestamped name and notwith the SNAPSHOT version. For example, http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/servicemix-core/3.0-incubating-SNAPSHOT/servicemix-core-3.0-incubating-20060815.104506-23.jar Not being able to use snapshots is not very friendly when you are developing ;)Is this an oversight or did I miss something ? On 8/13/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: So I can build Plugin A (quartz-scheduler). But the build for PluginB (quartz-deployer) which depends on Plugin A fails to create the CARwith an error like this:INFO] [ERROR] FATAL ERROR[INFO] [INFO] org.gplugins.quartz.QuartzScheduler in classloadergplugins/quartz-deployer/0.3/car[INFO] [INFO] Tracejava.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler inclassloader gplugins/quartz-deployer/0.3/car...at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java :76)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java :290)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:211)So it's saying that a quartz-deployer GBean can't find aquartz-scheduler class. Now, both the POM for quartz-deployer and theplan for quartz-deployer include an entry for the quartz-scheduler CAR:POM:gpluginsquartz-schedulerprovided cartarget/plan/plan.xml: gpluginsquartz-scheduler car And when I deploy the quartz-deployer JAR by hand using the plan attarget/plan/plan.xml, then it works fine.What I don't understand is, how can service-config-builder not load the quartz-scheduler CAR dependency and then claim that the classesare missing? If it loaded the dependency, the classes should be there(e.g. it works if deployed to a real server). If it didn't load the dependency, why didn't it get a missing dependency error?Thanks, Aaron-- Cheers,Guillaume Nodet
JIRA Permissions
Hi, I'm new to the Geronimo project and would like to start working on JIRA issues to help expedite my learning curve. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the Geronimo project ?? Thanks much. Tim McConnell
Re: XBean and QDox
Would we loose that cool "slurp in all the javadoc and make documentation" feature? Guessing we'd have to re-implement that somehow. -David On Aug 13, 2006, at 2:22 PM, Guillaume Nodet wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? -- Cheers, Guillaume Nodet
Re: Move trunk, tags and branches to server/*
I have not read anything to that affect... and would not recommend doing that. Top-level directories with the standard svn trunk, tags and branches is what I think will work out best for the long run. --jason On Aug 15, 2006, at 3:07 PM, Aaron Mulder wrote: Sounds OK to me, though I thought there had been some talk about something more like trunk/server trunk/other trunk/another server/branches server/tags other/branches other/tags another/branches another/tags Or something like that -- where all the trunks were together but all the branches and tags were separate. Or am I making that up? Thanks, Aaron On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: Move trunk, tags and branches to server/*
Sounds OK to me, though I thought there had been some talk about something more like trunk/server trunk/other trunk/another server/branches server/tags other/branches other/tags another/branches another/tags Or something like that -- where all the trunks were together but all the branches and tags were separate. Or am I making that up? Thanks, Aaron On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: JPA Plugin Status
On 8/15/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: David, I am releasing the specs as a 1.1.1 release due to some changes in jacc. Do you want to include the changes to JPA there? For my 2 cents, that would be great! Thanks, Aaron David Blevins wrote: > I got OpenJPA to run with my JPA code. So we're looking real good. > > On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: > >> So far, it's just got a TopLink provider, but if people want to copy >> that to create providers for Cayenne or OpenJPA or whatever, that >> would be great. It basically just needs to have a customized name and >> ClassPath, though I'm assuming any provider we integrate with will be >> compatible with the Geronimo JPA spec JAR (currently >> org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) > > OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had > some bad signatures and was missing a few exception classes. I fixed > those and managed to get OpenJPA to compile and run with our JPA jar > rather than the CDDL version they use. > >> If you try to build and run this, you'll be held up by a couple things: > > For me its: > - Still missing the some JNDI stuff Dain is working on (mentioned > earlier in the thread). > - Need the plugin goop > > But when that is there, this should run for ejbs or servlets in 1.1.1 > and maybe 1.1 (should work). > >> My goal is to have a release of this plugin with sufficient user >> documentation when G 1.1.1 is released. It would be great to have >> some open source JPA providers for that release too. >> >> I also started talking to David B about the JPA work being done in >> OpenEJB, and I think we're agreed that we probably don't need two such >> plugins for G 1.1.x, so hopefully we can work toward a unification as >> we move forward. > > I'm sure we can figure something out. I'll give it some more thought > tomorrow, time for bed now > > -David > > > >
Re: New car-maven-plugin issue
On 8/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Did you get this resolved with the jar scope == provided? The problem with this one appears to be that the car-maven-plugin class loader can't access JARs inside CARs, so it can't load a proper class loader for WARs (with WEB-INF/lib/*.jar), RARs (with embedded JARs), EARs, or service modules that were deployed with a JAR and a plan. This is not a problem with the online deployer (the normal deploy tool) because the CARs it uses are unpacked, but the car-maven-plugin gets packed CARs from the local M2 repo. The workaround in my case was to deploy the service modules as plan-only modules with a dependency on an external JAR. This wasn't my preference because it means there are more files to download when installing the plugin, but it gets past the problem for now (since the external JARs are not packed they can be added to the class loader successfully). As far as I know there really isn't a good workaround for any module that depends on a WAR, RAR, or EAR. For example, we may not be able to auto-generate a plugin that adds a screen to the console, because it depends on the console EAR. David J had some thoughts about how to address this (which I've forgotten, but perhaps a class loader that silently unpacks modules to temp dirs or successfully reads JAR-within-JAR entries). I think Dain has talked about this kind of this before too. Still, no ETA. Thanks, Aaron On Aug 13, 2006, at 6:17 AM, Aaron Mulder wrote: > So I can build Plugin A (quartz-scheduler). But the build for Plugin > B (quartz-deployer) which depends on Plugin A fails to create the CAR > with an error like this: > > INFO] > -- > -- > [ERROR] FATAL ERROR > [INFO] > -- > -- > [INFO] org.gplugins.quartz.QuartzScheduler in classloader > gplugins/quartz-deployer/0.3/car > [INFO] > -- > -- > [INFO] Trace > java.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler in > classloader gplugins/quartz-deployer/0.3/car > ... >at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo > (GBeanInfo.java:76) >at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanDa > ta(ServiceConfigBuilder.java:295) >at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans( > ServiceConfigBuilder.java:290) >at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi > guration(ServiceConfigBuilder.java:256) >at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi > guration(ServiceConfigBuilder.java:211) > > So it's saying that a quartz-deployer GBean can't find a > quartz-scheduler class. Now, both the POM for quartz-deployer and the > plan for quartz-deployer include an entry for the quartz-scheduler > CAR: > > POM: > > >gplugins >quartz-scheduler >provided >car > > > target/plan/plan.xml: > > >gplugins >quartz-scheduler >car > > > And when I deploy the quartz-deployer JAR by hand using the plan at > target/plan/plan.xml, then it works fine. > > What I don't understand is, how can service-config-builder not load > the quartz-scheduler CAR dependency and then claim that the classes > are missing? If it loaded the dependency, the classes should be there > (e.g. it works if deployed to a real server). If it didn't load the > dependency, why didn't it get a missing dependency error? > > Thanks, > Aaron
Move trunk, tags and branches to server/*
I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: New car-maven-plugin issue
Did you get this resolved with the jar scope == provided? --jason On Aug 13, 2006, at 6:17 AM, Aaron Mulder wrote: So I can build Plugin A (quartz-scheduler). But the build for Plugin B (quartz-deployer) which depends on Plugin A fails to create the CAR with an error like this: INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] org.gplugins.quartz.QuartzScheduler in classloader gplugins/quartz-deployer/0.3/car [INFO] -- -- [INFO] Trace java.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler in classloader gplugins/quartz-deployer/0.3/car ... at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo (GBeanInfo.java:76) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanDa ta(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans( ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi guration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi guration(ServiceConfigBuilder.java:211) So it's saying that a quartz-deployer GBean can't find a quartz-scheduler class. Now, both the POM for quartz-deployer and the plan for quartz-deployer include an entry for the quartz-scheduler CAR: POM: gplugins quartz-scheduler provided car target/plan/plan.xml: gplugins quartz-scheduler car And when I deploy the quartz-deployer JAR by hand using the plan at target/plan/plan.xml, then it works fine. What I don't understand is, how can service-config-builder not load the quartz-scheduler CAR dependency and then claim that the classes are missing? If it loaded the dependency, the classes should be there (e.g. it works if deployed to a real server). If it didn't load the dependency, why didn't it get a missing dependency error? Thanks, Aaron
TCK, Trunk & M2
What needs to be done to get the the TCK running on m2 builds of trunk? Lets wrap that up and nuke the m1 build. --jason
[jira] Commented: (GERONIMO-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12428239
]
Jason Dillon commented on GERONIMO-2206:
Status on this?
> examples configs [jsp-examples, servlets-examples]
> --
>
> Key: GERONIMO-2206
> URL: http://issues.apache.org/jira/browse/GERONIMO-2206
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: buildsystem
>Affects Versions: 1.2
>Reporter: Prasad Kashyap
> Assigned To: Prasad Kashyap
> Fix For: 1.2
>
> Attachments: examples-configs.patch
>
>
> patch enables the following configs
> - jsp-examples-jetty
> - jsp-examples-tomcat
> - servlet-examples-tomcat
> It also puts config option to the car-maven-plugin of
> console configs.
> servlets-examples-jetty config gives me the following error:
> {noformat}
> [INFO] Could not load servlet class
> compressionFilters.CompressionFilterTestServlet
> compressionFilters.CompressionFilterTestServlet in classloader
> org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=all ] Jason Dillon closed GERONIMO-2071. -- Resolution: Fixed m2 migration work is for the most part finished. If anything is left, please open a new issue to track. > Move Geronimo build to M2 (new 1.2 trunk) > - > > Key: GERONIMO-2071 > URL: http://issues.apache.org/jira/browse/GERONIMO-2071 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Prasad Kashyap > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: applications.patch, applications.patch.zip, configs.log, > configs.log, configs.patch, configs.patch, deploy-tool.patch, > deploy-tool.patch, deployment-plugin.patch, deployment-plugin.patch, > geronimo-deployment-plugin-RTC-VOTE.2.patch, > geronimo-deployment-plugin-RTC-VOTE.patch, geronimo.patch, geronimo.patch, > geronimo.patch, m2-plugins.patch, modules.patch, modules.patch, mvn.log, > openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, > openejb.patch, openejb.patch, pom.xml, pom.xml > > > A lot of work for moving Geronimo build to M2 was done under G-851. > (http://issues.apache.org/jira/browse/GERONIMO-851) > The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and > hence the migration work needs to be done here again. This JIRA will seek to > consolidate the work that was done under G-851 and all it's subtasks. > The patch(es) here will be submitted under the RTC guidelines. Future patches > for migration will have to be applied on top of this one. This patch will > contain the parent pom, modules, openejb, configs, m2-plugins > Any issues/concerns about migrating some pieces are well documented in G-851 > with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Jason Dillon closed GERONIMO-2067. -- Resolution: Fixed m2 migration work is for the most part finished. If anything is left, please open a new issue to track. > Configs migration to M2 > --- > > Key: GERONIMO-2067 > URL: http://issues.apache.org/jira/browse/GERONIMO-2067 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 > Environment: All >Reporter: Anita Kulshreshtha > Assigned To: Jason Dillon > Fix For: 1.2 > > Attachments: applications.patch, applications.patch, configs.log, > configs.log, configs.log, configs.log, configs.patch, configs.patch, > configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, > configs.patch, configs.patch, console-configs.patch, etc.patch, etc.patch, > hot-deployer.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, > m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, > modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch, pom.patch, > pom.xml > > > To build these configurations use packaging plugin GERONIMO-1740. This patch > builds non openejb and non jetty configurations. > This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2300) Use jar or assembly plugin to generate classpath/manifest bits for stuff in bin/*
[ http://issues.apache.org/jira/browse/GERONIMO-2300?page=all ] Jason Dillon closed GERONIMO-2300. -- Fix Version/s: 1.2 Resolution: Fixed Added explicit classpath based on m2 artifact to car plugin, since jar/assembly does not allow fine control over the prefix > Use jar or assembly plugin to generate classpath/manifest bits for stuff in > bin/* > - > > Key: GERONIMO-2300 > URL: http://issues.apache.org/jira/browse/GERONIMO-2300 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Jason Dillon > Assigned To: Jason Dillon > Fix For: 1.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2225) The M2 build no longer inserts META-INF/geronimo-plugin.xml into the CARs
[ http://issues.apache.org/jira/browse/GERONIMO-2225?page=all ] Jason Dillon closed GERONIMO-2225. -- Resolution: Fixed This is fixed > The M2 build no longer inserts META-INF/geronimo-plugin.xml into the CARs > - > > Key: GERONIMO-2225 > URL: http://issues.apache.org/jira/browse/GERONIMO-2225 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: Jason Dillon > Assigned To: Jason Dillon >Priority: Blocker > Fix For: 1.2 > > > The M2 build no longer inserts META-INF/geronimo-plugin.xml into the CARs > that have src/conf/geronimo-plugin.xml. There was handling for this in the > M1 build (e.g. for the welcome app and other examples). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JPA Plugin Status
David, I am releasing the specs as a 1.1.1 release due to some changes in jacc. Do you want to include the changes to JPA there? David Blevins wrote: I got OpenJPA to run with my JPA code. So we're looking real good. On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had some bad signatures and was missing a few exception classes. I fixed those and managed to get OpenJPA to compile and run with our JPA jar rather than the CDDL version they use. If you try to build and run this, you'll be held up by a couple things: For me its: - Still missing the some JNDI stuff Dain is working on (mentioned earlier in the thread). - Need the plugin goop But when that is there, this should run for ejbs or servlets in 1.1.1 and maybe 1.1 (should work). My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. I'm sure we can figure something out. I'll give it some more thought tomorrow, time for bed now -David
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 3)
+1 -Brian On Aug 8, 2006, at 1:35 PM, Hiram Chirino wrote: Some NOTICE file issues were found in the 2nd release candidate of the 4.0.2 build. I have cut and RC 3 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (GERONIMODEVTOOLS-94) Importing archives with non qualified plans cannot be opened with the editor
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-94?page=comments#action_12428204 ] Sachin Patel commented on GERONIMODEVTOOLS-94: -- Please open a different jira on this. > Importing archives with non qualified plans cannot be opened with the editor > > > Key: GERONIMODEVTOOLS-94 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-94 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: Windows XP + AG 1.1 + Devtools 1.1 >Reporter: Lin Sun > Assigned To: Sachin Patel > > This looks like a defect. I seem to have forgot to implement support for > importing non-qualified plans for 1.1. (i.e Running SchemaConversionUtil on > 1.1 plans). > On Aug 1, 2006, at 3:00 PM, Lin Sun wrote: > Hi there, > Has anyone been able to running jar or ear from within eclipse using the > devtools 1.1? > I have a MDB sample (from confluence) and I managed to get it running using > devtools 1.0 within eclipse. However, when I import my jar file in, the > openejb-jar.xml cannot be read by the Geronimo application deployment plan > editor. In the past experience, this is a pre-requisite before I can deploy > anything to Geronimo server in Eclipse. > I also tried to create a dummy EJB project and the default openejb-jar.xml > cannot be opened by the Geronimo application deployment plan editor either. > Similar prob with the EAR project. > I am wondering if this is a known limitation of the 1.1 version of devtools > project? Seems I can only get war project running... > Thanks, Lin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-94) Importing archives with non qualified plans cannot be opened with the editor
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-94?page=comments#action_12428203 ] Lin Sun commented on GERONIMODEVTOOLS-94: - I still have similar prob. The MDB openejb-jar.xml plan actually contains the fully qualified tags but it cannot be opened with the geornimo plan editor. Similar with a new openejb-jar.xml file created by default using the create new ejb project wizard. > Importing archives with non qualified plans cannot be opened with the editor > > > Key: GERONIMODEVTOOLS-94 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-94 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: Windows XP + AG 1.1 + Devtools 1.1 >Reporter: Lin Sun > Assigned To: Sachin Patel > > This looks like a defect. I seem to have forgot to implement support for > importing non-qualified plans for 1.1. (i.e Running SchemaConversionUtil on > 1.1 plans). > On Aug 1, 2006, at 3:00 PM, Lin Sun wrote: > Hi there, > Has anyone been able to running jar or ear from within eclipse using the > devtools 1.1? > I have a MDB sample (from confluence) and I managed to get it running using > devtools 1.0 within eclipse. However, when I import my jar file in, the > openejb-jar.xml cannot be read by the Geronimo application deployment plan > editor. In the past experience, this is a pre-requisite before I can deploy > anything to Geronimo server in Eclipse. > I also tried to create a dummy EJB project and the default openejb-jar.xml > cannot be opened by the Geronimo application deployment plan editor either. > Similar prob with the EAR project. > I am wondering if this is a known limitation of the 1.1 version of devtools > project? Seems I can only get war project running... > Thanks, Lin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build problems with SerivceMix
Thanks a lot. I will try it. I truly appreciate the help. Mahbub. Philip Dodds-2 wrote: > > See the Building information on the website - > > http://www.servicemix.org/site/building.html > > Note that it recently changed for the coming M3. > > P > > On 8/15/06, Mahbubur <[EMAIL PROTECTED]> wrote: >> >> Hello All, >> >> I am a newbie to the world of ServiceMix. I have downloaded the >> ServiceMix >> source from: >> >>apache-servicemix-3.0-M2-incubating >> >> and the maven-2.0.4 >> >> When I am trying to build with the following command: >> >>mvn -Dmaven.test.skip=true install >> >> I am getting the following messages. Would anyone let me know what I >> should >> (or should not) be doing? >> >> Thanks a lot in advance. >> >> [INFO] Scanning for projects... >> [INFO] Reactor build order: >> [INFO] ServiceMix >> [INFO] ServiceMix :: JBI >> [INFO] ServiceMix :: Services >> [INFO] ServiceMix :: Core >> [INFO] ServiceMix :: Components >> [INFO] ServiceMix :: Common >> [INFO] ServiceMix :: SOAP >> [INFO] ServiceMix :: Console >> [INFO] ServiceMix :: Tooling >> [INFO] ServiceMix :: Maven2 :: JBI Plugin >> [INFO] ServiceMix :: HTTP >> [INFO] ServiceMix :: BPE >> [INFO] ServiceMix :: JMS >> [INFO] ServiceMix :: JSR-181 Service Engine >> [INFO] ServiceMix :: WS-Notification Service Engine >> [INFO] ServiceMix :: Lightweight container Service Engine >> [INFO] ServiceMix :: SCA Service Engine >> [INFO] ServiceMix :: Web >> [INFO] ServiceMix :: EIP >> [INFO] ServiceMix :: ITests >> [INFO] ServiceMix :: BeanFlow >> [INFO] ServiceMix :: Maven2 :: Archetypes :: BindingComponent >> [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceEngine >> [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceUnit >> [INFO] ServiceMix :: Maven2 :: Archetypes :: ServiceAssembly >> [INFO] ServiceMix :: Samples >> [INFO] ServiceMix :: Samples :: WSDL first >> [INFO] ServiceMix :: Samples :: WSDL first :: JSR181 >> [INFO] ServiceMix :: Samples :: WSDL first :: HTTP >> [INFO] ServiceMix :: Samples :: WSDL first :: SA >> [INFO] Servicemix :: Assembly >> Downloading: >> http://servicemix.org/m2-repo/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar >> [WARNING] Unable to get resource from repository servicemix-m2-repo >> (http://servicemix.org/m2-repo) >> Downloading: >> http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar >> [WARNING] Unable to get resource from repository servicemix-distribution >> (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) >> Downloading: >> http://repo1.maven.org/maven2/org/apache/servicemix/tooling/jbi-maven-plugin/1.0-M2-incubating/jbi-maven-plugin-1.0-M2-incubating.jar >> [WARNING] Unable to get resource from repository central >> (http://repo1.maven.org/maven2) >> [INFO] >> >> [ERROR] BUILD ERROR >> [INFO] >> >> [INFO] Plugin could not be found - check that the goal name is correct: >> Unable to download the artifact from any repository >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.servicemix.tooling >> -DartifactId=jbi-maven-plugin \ >> -Dversion=1.0-M2-incubating -Dpackaging=maven-plugin >> -Dfile=/path/to/file >> >> >> >> org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> servicemix-m2-repo (http://servicemix.org/m2-repo), >> servicemix-distribution >> (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) >> >> >> org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:1.0-M2-incubating >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> servicemix-m2-repo (http://servicemix.org/m2-repo), >> servicemix-distribution >> (http://incubator.apache.org/dist/servicemix-3.0-M2-incubating/m2) >> >> [INFO] >> >> [INFO] For more information, run Maven with the -e switch >> [INFO] >> >> [INFO] Total time: 10 seconds >> [INFO] Finished at: Tue Aug 15 09:40:14 CDT 2006 >> [INFO] Final Memory: 5M/159M >> [INFO] >> >> >> -- >> View this message in context: >> http://www.nabble.com/Build-problems-with-SerivceMix-tf2109810.html#a5816326 >> Sent from the ServiceMix - Dev forum at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Build-problems-with-SerivceMix-tf2109810.htm
[jira] Updated: (GERONIMODEVTOOLS-102) Can't create Web project in eclipse without exception thrown
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-102?page=all ] Sachin Patel updated GERONIMODEVTOOLS-102: -- I cannot reproduce this on the latest WTP 1.5.1 integration driver. > Can't create Web project in eclipse without exception thrown > > > Key: GERONIMODEVTOOLS-102 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-102 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: Using WASCE version: > wasce_ibm142sdk_setup-1.0.1.2-ia32win.zip >Reporter: Chuck Bridgfham > > When selecting the WAS CE adapter, and Finishing Web Creation wizard... an > error dialog shows this message: > "Failed while installing Dynamic Web Module 2.4. > Cannot nest 'D:IBM/WebSphere/AppServerCommunityEdition/lib/endorsed' inside > library 'D:IBM/WebSphere/AppServerCommunityEdition/lib' > " -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-102) Can't create Web project in eclipse without exception thrown
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-102?page=all ] Sachin Patel updated GERONIMODEVTOOLS-102: -- Sorry, I didn't clarrify, CE defects shouldn't be opened here as this is only for the Geronimo adapter. However I assume that the problem exists on the Geronimo adapter as well, if so could you provide updated info? > Can't create Web project in eclipse without exception thrown > > > Key: GERONIMODEVTOOLS-102 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-102 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: Using WASCE version: > wasce_ibm142sdk_setup-1.0.1.2-ia32win.zip >Reporter: Chuck Bridgfham > > When selecting the WAS CE adapter, and Finishing Web Creation wizard... an > error dialog shows this message: > "Failed while installing Dynamic Web Module 2.4. > Cannot nest 'D:IBM/WebSphere/AppServerCommunityEdition/lib/endorsed' inside > library 'D:IBM/WebSphere/AppServerCommunityEdition/lib' > " -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] james strachan updated AMQ-855: --- Patch Info: [Patch Available] setting the patch available flag > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, > ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] james strachan reopened AMQ-855: The issue was resolved before Vadim attached more patches > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, > ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-102) Can't create Web project in eclipse without exception thrown
Can't create Web project in eclipse without exception thrown Key: GERONIMODEVTOOLS-102 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-102 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.1.0 Environment: Using WASCE version: wasce_ibm142sdk_setup-1.0.1.2-ia32win.zip Reporter: Chuck Bridgfham When selecting the WAS CE adapter, and Finishing Web Creation wizard... an error dialog shows this message: "Failed while installing Dynamic Web Module 2.4. Cannot nest 'D:IBM/WebSphere/AppServerCommunityEdition/lib/endorsed' inside library 'D:IBM/WebSphere/AppServerCommunityEdition/lib' " -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: XBean and QDox
Yep is just works. -dain On Aug 14, 2006, at 7:27 PM, Dan Diephouse wrote: Alan D. Cabrera wrote: James Strachan wrote: On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. Can I debug retrotranslated code in JDK14? Regards, Alan Yes. Dain did a whole bunch of experiments on this if you want to know more details. From what I understand they went quite well. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
improved tooling/runtime integration
So one of the big things we need to improve is our integration with our tooling and the runtime. If anyone had gotten a chance to read the section Geronimo Runtime Requirements in the following cwiki page it gives an overview of one of the problems we need to solve.http://cwiki.apache.org/GMOxDOC11/geronimo-eclipse-plugin-development-roadmap.htmlI've opened the following JIRAs which incorporate this and we really need to get this support in by 1.2. I think this is a substantial change and if anyone has any input on the least descructive way to approach this, your input is greatly appreciated.http://issues.apache.org/jira/browse/GERONIMO-2324 (Allow in-place and exploded jar support for sharedlib)- For this what about having a simple file inside shared lib that has entries for external jars/directories?http://issues.apache.org/jira/browse/GERONIMO-1526 (Allow module builders to support building config from non-j2ee structure)- For this I'm going to go through the earconfig builder and web builder since I think these are the big areas of impact and provide of list of problem areas that may need to be abstracted out. From there we can discuss if and how the interface should be changed. The other issue is how the implementation used can be controlled by the client. At first I thought we could just provide a new element in the g-module plan, but after thinking about it I don't think this is a good idea, since it would require a developers plan to be re-modified when moving from development to production. So I think we need to be able to set the ear implementation to be used somehow outside of the plan. Since JSR88 is being used to deploy with the eclipse plugin, I'd prefer to set it via the deployment manager. Thoughts? -sachin
[jira] Updated: (GERONIMODEVTOOLS-99) need to publish web project dependencies outside of WAR
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99?page=all ] Sachin Patel updated GERONIMODEVTOOLS-99: - Fix Version/s: 1.x > need to publish web project dependencies outside of WAR > --- > > Key: GERONIMODEVTOOLS-99 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, 32/64 bit >Reporter: Oleg Gusakov > Assigned To: Sachin Patel >Priority: Blocker > Fix For: 1.x > > > In our use case for geronimo plugin we need to be able to deploy WAR project > dependencies outside of WAR. The best place seems to SharedLib deployer. > Dependencies to deploy include: > - Eclipse WAR project references to other Eclipse projects > - external JAR files, attached to the project and/ot it's dependencies > - external dependencies supplied by Maven plugin from project's POM file. > This is almost identical to the previous one. > All dependencies need to be deployed "in place" for efficiency reasons. > Binary dependencies do not change often and can reside in one classloader. > Eclipse projects, on the other hand, change a lot and could be subjected to > hot redeployment, so they probably should reside in their own set of > classloaders. > Please consider for implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMODEVTOOLS-99) need to publish web project dependencies outside of WAR
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99?page=all ] Sachin Patel reassigned GERONIMODEVTOOLS-99: Assignee: Sachin Patel > need to publish web project dependencies outside of WAR > --- > > Key: GERONIMODEVTOOLS-99 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, 32/64 bit >Reporter: Oleg Gusakov > Assigned To: Sachin Patel >Priority: Blocker > Fix For: 1.x > > > In our use case for geronimo plugin we need to be able to deploy WAR project > dependencies outside of WAR. The best place seems to SharedLib deployer. > Dependencies to deploy include: > - Eclipse WAR project references to other Eclipse projects > - external JAR files, attached to the project and/ot it's dependencies > - external dependencies supplied by Maven plugin from project's POM file. > This is almost identical to the previous one. > All dependencies need to be deployed "in place" for efficiency reasons. > Binary dependencies do not change often and can reside in one classloader. > Eclipse projects, on the other hand, change a lot and could be subjected to > hot redeployment, so they probably should reside in their own set of > classloaders. > Please consider for implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1526) Allow module builders to support building configuraiton from non-j2ee structure.
[ http://issues.apache.org/jira/browse/GERONIMO-1526?page=all ] Sachin Patel updated GERONIMO-1526: --- Summary: Allow module builders to support building configuraiton from non-j2ee structure. (was: Suppot for running applications directly from a development enviornment) Description: See the section Geronimo Runtime Requirements in the link for a detailed description http://cwiki.apache.org/GMOxDOC11/geronimo-eclipse-plugin-development-roadmap.html In summary... - The module builders should not assume and cannot be passed in a jar file. - The module builders should not locate resources by assuming that the root location passed in is an J2EE file structure - Need to provide an abstraction of an ear/module one impl which would be by default is a J2EE structure, otherwise support a pluggable method to allow support for different IDEs. was:In order for the runtime to have better integration for a tooling/development environment we need the runtime to be able to run modules and their resources directly from a users development environment without having to package it. Currently, if a single source file changes the entire EAR must be exported and redeployed. This is not a long term solution and in past experiences this can lead to severe performance issues hindering a users development experience. Affects Version/s: 1.1.1 (was: 1.x) Assignee: (was: Sachin Patel) Priority: Critical (was: Major) > Allow module builders to support building configuraiton from non-j2ee > structure. > > > Key: GERONIMO-1526 > URL: http://issues.apache.org/jira/browse/GERONIMO-1526 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1.1 >Reporter: Sachin Patel >Priority: Critical > Fix For: 1.x > > > See the section Geronimo Runtime Requirements in the link for a detailed > description > http://cwiki.apache.org/GMOxDOC11/geronimo-eclipse-plugin-development-roadmap.html > In summary... > - The module builders should not assume and cannot be passed in a jar file. > - The module builders should not locate resources by assuming that the root > location passed in is an J2EE file structure > - Need to provide an abstraction of an ear/module one impl which would be by > default is a J2EE structure, otherwise support a pluggable method to allow > support for different IDEs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Fix For: 1.x The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: loan broaker example fails
please find attached the patch for the pom.xml and bin.xml of apache-servicemix. I found a commented out dependecySet, which contained a lot of jars for lib/optional. It looks like these jars were used in earlier incarnation of servicemix. Could they be used for via mvn profiles, such as a full build or a reduced one? I am not sure whether maven profiles could be easily used inside the assembly plugin, but at least an assembly for all optional libraries should be possible. http://www.nabble.com/user-files/320/loan-broaker.patch loan-broaker.patch Klaus. gnodet wrote: > > Adding these jars in the lib/optional should be easily done by changing > the > apache-servicemix/src/assembly/bin.xml config file, and maybe the > apache-servicemix/pom.xml to add these dependencies. > > On 8/15/06, Klaus Alfert <[EMAIL PROTECTED]> wrote: >> >> >> My parallel experiment supports your statement - it is not enough to add >> it >> to the service unit. >> >> So, the proper way is to extend the pom of the components you mention in >> the >> issue? I'll give it a try if it is ok with you. >> >> Klaus. >> >> >> gnodet wrote: >> > >> > On 8/15/06, Klaus Alfert <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> Thanks for your quick answer. >> >> >> >> It works, after I added also commons-collection: there was a >> dependency >> >> to >> >> CursorableLinkedList. >> >> >> >> Could this issue resolved by adding the two libraries to the service >> >> unit? >> >> In that case I could work out a patch for the pom of the loan broaker >> >> example. >> > >> > >> > This is not so easy. >> > activemq is in the container classloader and commons-pool / >> > commons-collection >> > are loaded from this classloader. >> > The only way is to add them to the container classloader or to change >> > classloader >> > delegation and add activemq, commons-pool and commons-collection to the >> SU >> > classloader. >> > >> > >> > Klaus. >> >> >> >> >> >> >> >> gnodet wrote: >> >> > >> >> > This is a know problem, see >> >> > http://issues.apache.org/activemq/browse/SM-520 >> >> > As a workaround, just put the commons-pool in the ./lib/optional >> folder >> >> of >> >> > ServiceMix. >> >> > >> >> > On 8/15/06, Klaus Alfert <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> I had yesterday some deployment problems with a simple JMS service >> >> >> assembly, >> >> >> where the jms connection factory was not found. Since my assembly >> uses >> >> >> JMS >> >> >> with lw-container, I took a deeper look into the loan broaker >> >> examples. >> >> >> But >> >> >> the loan broaker example failed with a similar error. >> >> >> >> >> >> What I have done is: >> >> >> - svn update of servicemix >> >> >> - build servicemix with mvn, >> >> >> - unpack the apache-servicemix-3.0-incubating-SNAPSHOT.tar.gz from >> >> >> trunk/apache-service/target >> >> >> - run bin/servicemix >> >> >> - build the loan broaker example with mvn as described in the >> README >> >> >> >> >> >> My environemnt is: SuSE Linux 10.1 with jdk 1.5.0_06-b05. >> >> >> >> >> >> Please find below the output from maven. >> >> >> >> >> >> Cheers, Klaus. >> >> >> [CUT CUT CUT] >> >> > >> >> > -- >> >> > Cheers, >> >> > Guillaume Nodet >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/loan-broaker-example-fails-tf2108018.html#a5811290 >> >> Sent from the ServiceMix - Dev forum at Nabble.com. >> >> >> >> >> > >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/loan-broaker-example-fails-tf2108018.html#a5811443 >> Sent from the ServiceMix - Dev forum at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/loan-broaker-example-fails-tf2108018.html#a5812737 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: JPA Plugin Status
I got OpenJPA to run with my JPA code. So we're looking real good. On Aug 13, 2006, at 8:24 PM, Aaron Mulder wrote: So far, it's just got a TopLink provider, but if people want to copy that to create providers for Cayenne or OpenJPA or whatever, that would be great. It basically just needs to have a customized name and ClassPath, though I'm assuming any provider we integrate with will be compatible with the Geronimo JPA spec JAR (currently org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) OpenJPA and the Geronimo JPA spec jar weren't happy. Our JPA jar had some bad signatures and was missing a few exception classes. I fixed those and managed to get OpenJPA to compile and run with our JPA jar rather than the CDDL version they use. If you try to build and run this, you'll be held up by a couple things: For me its: - Still missing the some JNDI stuff Dain is working on (mentioned earlier in the thread). - Need the plugin goop But when that is there, this should run for ejbs or servlets in 1.1.1 and maybe 1.1 (should work). My goal is to have a release of this plugin with sufficient user documentation when G 1.1.1 is released. It would be great to have some open source JPA providers for that release too. I also started talking to David B about the JPA work being done in OpenEJB, and I think we're agreed that we probably don't need two such plugins for G 1.1.x, so hopefully we can work toward a unification as we move forward. I'm sure we can figure something out. I'll give it some more thought tomorrow, time for bed now -David
[jira] Created: (SM-543) NPE occurs in onMessage of JmsServiceComponent
NPE occurs in onMessage of JmsServiceComponent -- Key: SM-543 URL: https://issues.apache.org/activemq/browse/SM-543 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0-M2 Reporter: Adrian Co Assigned To: Adrian Co NPE occurs in JmsServiceComponent when it receives messages, but the component has not been actually started, hence the work manager has not been initalized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: AJAX and Geronimo
Paul,
I tried your suggestion by creating 2 webapps, 1 for
dojo toolkit and another that includes the toolkit and
it worked. Im just wondering if there is disparity
between 2 webapps where 1 uses the shared dojo toolkit
and another using its own. Right now I couldnt tell.
Thanks for the suggestion.
chris
--- Paul McMahan <[EMAIL PROTECTED]> wrote:
> Chris, Thanks for offering to help. Since you've
> already got a
> working Geronimo webapp that uses Dojo in
> GERONIMO-1823 I would love
> to see how this idea holds up. How about moving the
> Dojo library from
> your webapp into separate webapp available at the
> context root "/dojo"
> and then adjusting your webapp to point at it?
> Depending on how you
> referenced Dojo in your scripts and html you may
> have to include a
> line like:
> dojo.setModulePrefix("dojo",
> "/dojo");
> after you load dojo.js. I also figured out a way to
> dynamically load
> dojo.js from a javascript file (instead of html) if
> you that would
> help.
>
> To start the Dojo webapp and make its resources
> available you would
> also need to add a line to your webapps
> geronimo-web.xml like
>
>
> dojo
> dojo-toolkit
> war
>
>
> Does that sound reasonable? Feel free to take this
> idea and run with
> it, get creative, etc :-)
>
> Best wishes,
> Paul
>
> On 8/14/06, Chris Cardona <[EMAIL PROTECTED]>
> wrote:
> > This is a good idea Paul. I'm not exactly sure how
> you
> > would implement it but let me know if I can help
> with
> > anything (testing, dev, docs, etc.). This will
> > definitely help those who wanted to develop Ajax
> > enabled apps in G. Also nice to have is if we can
> find
> > a way to do the same thing for DWR if it's
> possible.
> >
> > Cheers,
> > chris
> >
> >
> > --- Paul McMahan <[EMAIL PROTECTED]> wrote:
> >
> > > Dojo is a popular open source AJAX library
> that's
> > > available under the
> > > BSD and Academic Free licenses. The DayTrader
> folks
> > > use it in the web
> > > UI they recently announced on the Geronimo dev
> list
> > > and Chris used it
> > > in the nice LDAP UI he did for GERONIMO-1823. I
> > > would also like to
> > > start introducing some use of it into the
> Geronimo
> > > admin console when
> > > its appropriate to do so.
> > >
> > > The way that developers usually incorporate an
> AJAX
> > > library into their
> > > applications is by making a copy of its static
> files
> > > (javascript, css,
> > > gifs, etc) in their webapp and referencing them
> from
> > > their servlets
> > > and JSPs. The obvious downside is that each
> > > application has a
> > > separate copy of the AJAX library, increasing
> the
> > > server's overall
> > > disk footprint (Dojo is ~3mb) and preventing the
> > > browser from using a
> > > single copy of the library files from its cache.
> > > Another downside is
> > > that the AJAX library can't be upgraded
> > > independently from the web
> > > application.
> > >
> > > I think it would be great if Geronimo could
> provide
> > > a more AJAX
> > > friendly development environment by helping
> solve
> > > these problems. One
> > > idea is that Geronimo could include the Dojo
> library
> > > as a native,
> > > standalone webapp with its AJAX library files
> laid
> > > out so that other
> > > applications can point at from their HTML.
> > > Referencing it in
> > > geronimo-web.xml would cause Geronimo to start
> it up
> > > and make its
> > > files available at some predetermined context
> root,
> > > say /dojo.
> > > Referencing it with a versionless moduleId would
> > > make sure the most
> > > recent version is always used. So AJAX enabling
> > > your application in
> > > Geronimo would be a simple as "add this line to
> your
> > > geronimo-web.xml".
> > >
> > > Does this sound like a good idea? Any
> suggestions
> > > or concerns?
> > > Perhaps this could be done as a plugin instead
> of a
> > > native module?
> > >
> > > Best wishes,
> > > Paul
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Created: (SM-542) NPE occurs in ODE-BPE when undeploying and redeploying the loan broker demo.
NPE occurs in ODE-BPE when undeploying and redeploying the loan broker demo. Key: SM-542 URL: https://issues.apache.org/activemq/browse/SM-542 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Affects Versions: 3.0-M2 Reporter: Adrian Co Assigned To: Adrian Co Fix For: 3.0-M3 NPE occurs in the ODE-BPE class when undeploying, redeploying, and then running the loan broker demo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-523) Provide security integration with Geronimo
[ https://issues.apache.org/activemq/browse/SM-523?page=all ] Guillaume Nodet updated SM-523: --- Fix Version/s: (was: 3.0-M3) > Provide security integration with Geronimo > -- > > Key: SM-523 > URL: https://issues.apache.org/activemq/browse/SM-523 > Project: ServiceMix > Issue Type: Bug > Components: geronimo >Reporter: Guillaume Nodet > > We need an implementation of Crypto which uses geronimo KeystoreInstance -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-870) Broker fails to deliver messages after restart
[
https://issues.apache.org/activemq/browse/AMQ-870?page=comments#action_36783 ]
Anders Bengtsson commented on AMQ-870:
--
I've tried the same test-case with 4.0.2 RC3, which fails too, but in a very
different way. With 4.0.2 RC3 there is some other problem with the restart,
which causes the test to hang instead of failing.
> Broker fails to deliver messages after restart
> --
>
> Key: AMQ-870
> URL: https://issues.apache.org/activemq/browse/AMQ-870
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.1
> Environment: java version "1.5.0_07", Ubuntu Linux 6.06
>Reporter: Anders Bengtsson
> Assigned To: Rob Davies
> Attachments: debug-output.txt, TestFailingReconnectScenario.java
>
>
> We're running two networked brokers, B1 and B2, with a producer connected to
> B1 and a consumer to B2. Forwarding messages through this initially works
> fine.
> If we re-start broker B2, everything seems to re-connect, but we no longer
> get any messages to the consumer.
> If we instead re-start broker B1, everything works fine.
> I've attached a JUnit test-case illustrating the two scenarios, a working
> re-start of B1 and a breaking re-start of B2.
> Also attached is parts of a log from running the unit test.
> I'm suspicious about log lines like these, but don't know if they are related
> to the problem:
> [2006-08-08 14:36:16] DEBUG: [DemandForwardingBridge] Ignoring sub
> ConsumerInfo
> {commandId = 4, responseRequired = true, consumerId =
> ID:descartes-49241-1155040510241-5:2:1:1, destination = topic://SOME.TOPIC,
> prefetchSize = 32766, maximumPendingMessageLimit = 0, browser = false,
> dispatchAsync = false, selector = null, subcriptionName = null, noLocal =
> false, exclusive = false, retroactive = false, priority = 0, brokerPath =
> [ID:descartes-49241-1155040510241-1:5], optimizedAcknowledge = false,
> noRangeAcks = false, additionalPredicate = null} already subscribed to
> matching destination
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (XBEAN-17) Fix informations for xbean project
[ http://issues.apache.org/jira/browse/XBEAN-17?page=all ] Guillaume Nodet closed XBEAN-17. Fix Version/s: 2.6 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Tue Aug 15 00:11:49 2006 New Revision: 431547 URL: http://svn.apache.org/viewvc?rev=431547&view=rev Log: XBEAN-17: fix mailing lists, main url > Fix informations for xbean project > -- > > Key: XBEAN-17 > URL: http://issues.apache.org/jira/browse/XBEAN-17 > Project: XBean > Issue Type: Task >Affects Versions: 2.4 >Reporter: Guillaume Nodet > Assigned To: Guillaume Nodet > Fix For: 2.6 > > > - "Project Mailing Lists" have the wrong email address > - Please consider using the apache ids for the committers. > - Project summary has wrong url (http://xbean.org) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Changing keystore type for Jetty
Hello, Could you please tell me how can I change keystore type for Jetty? I'm trying to replace Jetty SSL keystore type with PKCS12 by adding the parameter to config.xml: ... PKCS12 0.0.0.0 8443 ... It works fine for Tomcat, but for Jetty I get the following error log: [*> ] 43% 72s Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/jetty/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) ... Caused by: java.lang.IllegalStateException: Attribute is not persistent Attribute Name: keystoreType, Type: class java.lang.String, GBeanInstance: Jetty Connector HTTPS at org.apache.geronimo.gbean.runtime.GBeanAttribute.setPersistentValue(GBeanAttribute.java:355) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:749) at org.apache.geronimo.gbean.runtime.GBeanInstance.(GBeanInstance.java:367) ... 17 more Is it at all possible to change the keystore type for Jetty HTTPS gbean? Nellya Udovichenko, Intel Middleware Products Division
