Re: Why Confluence cannot not be used as a wiki, and how it mightbe fixed
I will belive it when I see it. In the mean time, changing the layout not to render user specific mumbo jumbo by default should take care of 90% of the problem. --jason -Original Message- From: Hernan Cunico <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 22:45:23 To:dev@geronimo.apache.org Subject: Re: Why Confluence cannot not be used as a wiki, and how it might be fixed In terms of performance, Atlassian team is working on a "Confluence Massive" that will run in a cluster. That should not only address performance but also high availability. Does anybody have more details on this? Cheers! Hernan Aaron Mulder wrote: > I'm not sure how to interpret this; are Ken/Noel suggesting that we > should stop using Confluence for the time being, or just that there > are more obstacles to get it fully implemented than were initially > expected? > > Thanks, > Aaron > > On 2/3/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > >>Forwarding to the dev@ list with permission. This >>is where it belongs. >>-- >>#kenP-)} >> >>Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ >>Author, developer, opinionist http://Apache-Server.Com/ >> >>"Millennium hand and shrimp!" >> >> >> >>-- Forwarded message -- >>From: "Noel J. Bergman" <[EMAIL PROTECTED]> >>To: "Hernan Cunico" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >>Date: Fri, 3 Feb 2006 10:08:19 -0500 >>Subject: Why Confluence cannot not be used as a wiki, and how it might be >>fixed >>To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't >>be used as a *primary* project website if slashdotting is likely." Read >>"slashdotting" as heavy load, and we experience sufficient load on the Wiki >>to make caching mandatory. >> >>See: >>http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach >>ing+Proxy+Server >> >>The comment: >> >> "The main problem with the reverse-proxy solution is that every >> Confluence page is built dynamically for whichever user is >> currently accessing it." >> >>is a typical indicator of a common problem in many dynamic content systems, >>which all too often neglect the fact that 99.999+% of all traffic is going >>to be relatively static and anonymous. Dynamic does not mean ephemeral, and >>that distinction is missed all too often. >> >>The facts are that most Wiki access is anonymous, and Wiki content is almost >>entirely static and should be cachable. Confluence intentionally breaks >>caches, and that behavior needs to be fixed. There are a number of possible >>solutions. >> >>One way, and just a simple one, since there are others, would be for >>anonymous and authenticated access could have different URLs, e.g., >>mydomain.tld/confluence/anon/ for the public, and >>mydomain.tld/confluence/auth/ for authenticated users. That would permit >>the vast majority of accesses to be cached. "WAIT", you say, "What about >>when someone edits the page under the /auth/ path? Won't that cause a >>problem for viewers in the /anon/ path?" Not if the URLs are properly >>designed, and the system is supporting Conditional Get. The /anon/ path >>should be handling Conditional Get based upon the timestamp of the page >>resource. So most GET requests will simply return 304, unless the page has >>been changed, in which case the updated resource can be returned and cached. >> >>So these are technical issues (Joshua Slive outlined other, related, ones), >>and the ball has been in Atlassian's court to provide some resolution. >> >>--- Noel >> >> >> >> > >
Re: Oracle XA RAR for G1.0?
Good point. Although I suspect it won't matter. I'll take a look at that and update as appropriate. Thanks Aaron Mulder wrote: If the RAR is specific to the driver, don't we want to compile against a JDK 1.4 driver not a JDK 1.2 driver? Thanks, Aaron On 2/3/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think David means that it has not been extensively tested and so there are no gurantees that you'll simply be able to drop it in. I'm currently working on a DB2 XA RAR and am still working out some kinks. It should work well, we're just not sure its been testd enough to know that it does. I looked on CodeHaus and it appears that Jeremy had not previous released a SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 classes12.jar. I've published it and it is called tranql/rars/tranql-connector-oracle-xa-1.0-SNAPSHOT.rar If someone can try this out then that would be excellent. I have only compiled it and not tested it so caveat emptor. lichtner wrote: On Fri, 3 Feb 2006, David Jencks wrote: It is likely to work if you build it. However I don't know that it has been used in the last year or more, so I won't make any promises. Matt might have tried it, I don't know. We have been a bit reluctant to publish it without more evidence that it works well. Why would it not work well? When I was in my last job I remember getting that rar to work with mysql xa, so it probably also works with Oracle xa.
Re: TranQL, M2, Transitive Deps
My guess is that most of these are dependencies for testing. In that case, tranql should mark them with test. That way they will m2 will not try to download them. -dain On Feb 3, 2006, at 8:41 PM, Aaron Mulder wrote: On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote: Is the tranql pom you refer to autogenerated from the m1 project.xml? If so would you consider writing m2 poms that actually compile the tranql connectors? I don't know. I just told Maven I wanted the RAR and it fetched it, and somehow all the baggage came along, so I'm kind of leaping to the conclusion the the TranQL Connector POM specifies more dependencies than I actually want. At any rate, I will consider anything, given arbitrary time. How about for now I put in a JIRA? :) Thanks, Aaron On Feb 3, 2006, at 8:07 PM, Aaron Mulder wrote: So I tried creating a Maven 2 EAR that pulls in the TranQL Connector RAR. When Maven built the EAR, it pulled gobs of other 3rd party libraries into my EAR: commons-*, axion, various Geronimo specs, etc. Needless to say I don't want that, I only want the actual RAR added to my EAR. I assume to fix this we should change all those dependencies to scope=provided or scope=compile or something like that in the TranQL Connector POM, since you shouldn't need them at runtime, right? I mean, IMO anything you need at runtime (other than the spec classes), the RAR should include within itself, not have transitive runtime dependencies on. Any complaints if I make a JIRA for this? Thanks, Aaron
Re: TranQL, M2, Transitive Deps
On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote: > Is the tranql pom you refer to autogenerated from the m1 > project.xml? If so would you consider writing m2 poms that actually > compile the tranql connectors? I don't know. I just told Maven I wanted the RAR and it fetched it, and somehow all the baggage came along, so I'm kind of leaping to the conclusion the the TranQL Connector POM specifies more dependencies than I actually want. At any rate, I will consider anything, given arbitrary time. How about for now I put in a JIRA? :) Thanks, Aaron > On Feb 3, 2006, at 8:07 PM, Aaron Mulder wrote: > > > So I tried creating a Maven 2 EAR that pulls in the TranQL Connector > > RAR. When Maven built the EAR, it pulled gobs of other 3rd party > > libraries into my EAR: commons-*, axion, various Geronimo specs, etc. > > Needless to say I don't want that, I only want the actual RAR added to > > my EAR. > > > > I assume to fix this we should change all those dependencies to > > scope=provided or scope=compile or something like that in the TranQL > > Connector POM, since you shouldn't need them at runtime, right? I > > mean, IMO anything you need at runtime (other than the spec classes), > > the RAR should include within itself, not have transitive runtime > > dependencies on. > > > > Any complaints if I make a JIRA for this? > > > > Thanks, > > Aaron > >
Re: TranQL, M2, Transitive Deps
Is the tranql pom you refer to autogenerated from the m1 project.xml? If so would you consider writing m2 poms that actually compile the tranql connectors? thanks david jencks On Feb 3, 2006, at 8:07 PM, Aaron Mulder wrote: So I tried creating a Maven 2 EAR that pulls in the TranQL Connector RAR. When Maven built the EAR, it pulled gobs of other 3rd party libraries into my EAR: commons-*, axion, various Geronimo specs, etc. Needless to say I don't want that, I only want the actual RAR added to my EAR. I assume to fix this we should change all those dependencies to scope=provided or scope=compile or something like that in the TranQL Connector POM, since you shouldn't need them at runtime, right? I mean, IMO anything you need at runtime (other than the spec classes), the RAR should include within itself, not have transitive runtime dependencies on. Any complaints if I make a JIRA for this? Thanks, Aaron
[jira] Closed: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=all ] Jeff Genender closed GERONIMO-1480: --- Fix Version: (was: 1.0.1) Resolution: Fixed Fixed. Added BeforeAfters and removed the old valves. Added a Listener to run on dispatch only. Sending tomcat/src/java/org/apache/geronimo/tomcat/GeronimoStandardContext.java Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor/BeforeAfter.java Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor/ComponentContextBeforeAfter.java Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor/InstanceContextBeforeAfter.java Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor/PolicyContextBeforeAfter.java Adding tomcat/src/java/org/apache/geronimo/tomcat/interceptor/TransactionContextBeforeAfter.java Sending tomcat/src/java/org/apache/geronimo/tomcat/listener/DispatchListener.java Sending tomcat/src/java/org/apache/geronimo/tomcat/realm/TomcatGeronimoRealm.java Deleting tomcat/src/java/org/apache/geronimo/tomcat/valve/ComponentContextValve.java Adding tomcat/src/java/org/apache/geronimo/tomcat/valve/GeronimoBeforeAfterValve.java Deleting tomcat/src/java/org/apache/geronimo/tomcat/valve/InstanceContextValve.java Deleting tomcat/src/java/org/apache/geronimo/tomcat/valve/PolicyContextValve.java Deleting tomcat/src/java/org/apache/geronimo/tomcat/valve/TransactionContextValve.java Transmitting file data . Committed revision 374759. > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke(
TranQL, M2, Transitive Deps
So I tried creating a Maven 2 EAR that pulls in the TranQL Connector RAR. When Maven built the EAR, it pulled gobs of other 3rd party libraries into my EAR: commons-*, axion, various Geronimo specs, etc. Needless to say I don't want that, I only want the actual RAR added to my EAR. I assume to fix this we should change all those dependencies to scope=provided or scope=compile or something like that in the TranQL Connector POM, since you shouldn't need them at runtime, right? I mean, IMO anything you need at runtime (other than the spec classes), the RAR should include within itself, not have transitive runtime dependencies on. Any complaints if I make a JIRA for this? Thanks, Aaron
Re: Spring support in Geronimo
Ha... This app is so coupled to WAS5 its not funny. Using com.ibm classes all over the place :-( --jason -Original Message- From: David Jencks <[EMAIL PROTECTED]> Date: Fri, 3 Feb 2006 19:43:17 To:dev@geronimo.apache.org Subject: Re: Spring support in Geronimo On Feb 3, 2006, at 5:37 PM, Jason Dillon wrote: > On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote: >> I don't think you'll be able to see anything in a jndi viewer since >> we don't have a global jndi context > > :-( > > >> Have you tried using my SpringTransactionManager instead of spring's >> JtaTransactionManager? > > Where is your mythical SpringTransactionManager? modules/spring > > >> Is your ejb clearly labelled for BMT? If so, the UT should be there >> if you are accessing spring from the ejb in the same thread as the >> ejb call and spring is not changing any of the initial context system >> properties. > > Um... for the record its not really my bean... I was just given this > app that runs on WAS5 and asked to make it run on Geronimo. > > And, it looks like they are all Container managed > (Container is everywhere). > yikes, you are not supposed to be able to get UT in a CMT ejb. Your app should not work on any j2ee compliant app server :-) thanks david jencks > * * * > > What Spring and Hibernate need is a way to get a handle on the > containers TXM. I had just tried using the > org.springframework.transaction.jta.JtaTransactionManager. But did > not get very far with testing this stuff out because every 10 minutes > someone comes by and bugs me for something... :-( > > --jason
Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
In terms of performance, Atlassian team is working on a "Confluence Massive" that will run in a cluster. That should not only address performance but also high availability. Does anybody have more details on this? Cheers! Hernan Aaron Mulder wrote: I'm not sure how to interpret this; are Ken/Noel suggesting that we should stop using Confluence for the time being, or just that there are more obstacles to get it fully implemented than were initially expected? Thanks, Aaron On 2/3/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: Forwarding to the dev@ list with permission. This is where it belongs. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -- Forwarded message -- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "Hernan Cunico" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Date: Fri, 3 Feb 2006 10:08:19 -0500 Subject: Why Confluence cannot not be used as a wiki, and how it might be fixed To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't be used as a *primary* project website if slashdotting is likely." Read "slashdotting" as heavy load, and we experience sufficient load on the Wiki to make caching mandatory. See: http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach ing+Proxy+Server The comment: "The main problem with the reverse-proxy solution is that every Confluence page is built dynamically for whichever user is currently accessing it." is a typical indicator of a common problem in many dynamic content systems, which all too often neglect the fact that 99.999+% of all traffic is going to be relatively static and anonymous. Dynamic does not mean ephemeral, and that distinction is missed all too often. The facts are that most Wiki access is anonymous, and Wiki content is almost entirely static and should be cachable. Confluence intentionally breaks caches, and that behavior needs to be fixed. There are a number of possible solutions. One way, and just a simple one, since there are others, would be for anonymous and authenticated access could have different URLs, e.g., mydomain.tld/confluence/anon/ for the public, and mydomain.tld/confluence/auth/ for authenticated users. That would permit the vast majority of accesses to be cached. "WAIT", you say, "What about when someone edits the page under the /auth/ path? Won't that cause a problem for viewers in the /anon/ path?" Not if the URLs are properly designed, and the system is supporting Conditional Get. The /anon/ path should be handling Conditional Get based upon the timestamp of the page resource. So most GET requests will simply return 304, unless the page has been changed, in which case the updated resource can be returned and cached. So these are technical issues (Joshua Slive outlined other, related, ones), and the ball has been in Atlassian's court to provide some resolution. --- Noel
Re: Spring support in Geronimo
On Feb 3, 2006, at 5:37 PM, Jason Dillon wrote: On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote: I don't think you'll be able to see anything in a jndi viewer since we don't have a global jndi context :-( Have you tried using my SpringTransactionManager instead of spring's JtaTransactionManager? Where is your mythical SpringTransactionManager? modules/spring Is your ejb clearly labelled for BMT? If so, the UT should be there if you are accessing spring from the ejb in the same thread as the ejb call and spring is not changing any of the initial context system properties. Um... for the record its not really my bean... I was just given this app that runs on WAS5 and asked to make it run on Geronimo. And, it looks like they are all Container managed (Container is everywhere). yikes, you are not supposed to be able to get UT in a CMT ejb. Your app should not work on any j2ee compliant app server :-) thanks david jencks * * * What Spring and Hibernate need is a way to get a handle on the containers TXM. I had just tried using the org.springframework.transaction.jta.JtaTransactionManager. But did not get very far with testing this stuff out because every 10 minutes someone comes by and bugs me for something... :-( --jason
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
Bruce Snyder wrote:
On 2/3/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
I'll look through the user guide although checking at the current site I count
only 15 pages. I am
wondering if it is worth to invest in xdoc and multiplying the number of files
and complexity when
this site is relatively simple to maintain in HTML directly (static pages + low
number of pages).
All of the site docs are in xdoc format already. I'll check in what
I've got so all you need to do is run:
maven site
And it will build the Geronimo site using Maven and my start on it. A
word of warning, I have not yet begun to apply the Epiq CSS.
I forgot to include this link. Check out the URL below to see what my
work produces so far:
https://svn.apache.org/repos/asf/geronimo/site/docs
Earlier today I did a svn co on the /site and started on "learn" how the site was built. I also
started to move some css styles over. So far I'm struggling with the banner and menu on the top.
I'll get a sample out as soon as I have something "decent".
Cheers!
Hernan
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Proposed solution for the configId dilemma
I talked with Dain some more and we laid out some steps to follow, I put them on the confluence wiki: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/ configId If people would like me to summarize changes and progress on the dev list as well I will attempt to do that. I hope to have a proposal for schema changes in the next day or so. Please get ready to review and criticize it :-) thanks david jencks On Feb 2, 2006, at 6:42 PM, David Jencks wrote: After a long discussion on IRC we may have a proposal for the configId dilemma. People: Dain and I will work to implement this Timeframe: for the next week, then we will see where we are svn tags: we'll make a branch off 1.0. If we succeed, the merge of our work and 1.0 will become 1.1 and we will not release 1.0.1. Then we'll merge into trunk. Goal: make version Id optional almost everywhere: certainly in any normal user plan. xml changes: eliminate configId and parentId attributes: there is already the element to replace parentId, and introduce a new configId element to replace the configid attribute. This will have the same structure as dependencies, imports, etc. For all these tags except configId version will be optional. Introduce a new element (name up for grabs :-) that creates a dependency on the named configuration but does not add it to the set of classloader parents. This would have the dependency type with optional version. eliminate direct specification of gbean names in gbeans and in gbean reference patterns. Replace specification of e.g. groupId/artifactId/version/car with foo bar 1.0 where any of these is optional. There may be changes in the meaning of gbean name specifications, see the resolution process described later. problems with this: - configId can appear in module or application. We think that the configId resolution process described later will be able to resolve the meaning - there are a few gbeans that don't have as many object name keys, such as the jsr-77 beans for the server and jvm. I don't know how to deal with these yet. GBean name changes: Change the configuration gbean names to have separate groupId, artifactId, and version keys. We might need to separate out a version in every gbean name but think this is unlikely. File system changes: adopt a maven2 repository structure for the geronimo repo. algorithm changes: 1. resolving parents (imports) and config-dependencies. These both involve finding a configuration given only partial information. The config-store is going to need to be queriable to some extent and we will need some kind of resolution strategy in case there is more than one match. Starting from a plan, resolving the parents and config-dependencies recursively results (when combined) with a directed acyclic graph of configurations (configDAG). 2. resolving gbean references. This part is still open to considerable modification, but some parts are clear. We start with a partially specified object name: typically we will have a name key, a j2eeType key, and a partial specification of the configId. We start by resolving the configId by a depth first search of the configDAG until we find a match. Depending on whether the target configuration is for an ear or anything else, we can determine if the configId is the J2EEApplication or J2EEModule key for the name. We can then look for names matching the rest of the specification. Discussion of algorithm changes: Currently there are 2 kinds of name resolution: "link" resolution that typically starts in the current module and then if not matched looks in any module with J2EEApplication="null", and exact specification where you specify several name components and the rest are the same as the gbean with the reference. There is also specifying an entire name explicitly (possibly with wildcards). We plan to eliminate the whole-name option. We think that we can replace both the other resolution methods with the method just outlined, where the search path for resolution is not the whole server but the configDAG. For me, this requires more study to be completely confident that it will work but I am very hopeful. An unusual situation that requires a reference out of the configDAG: It is possible for a config A to have a gbean X and a config B to have a gbean Y where both X and Y reference the other gbean, so long as at least one of the references is multi-valued. In order to allow for this, it has to be possible to specify a reference pattern in some way that is not resolved at deploy time. This is an extremely unusual situation and complex xml should be acceptable here. Console changes: Several console portlets let you construct a plan. These need to be modified to allow you to specify groupid, artifactId, and version explicitly. The version can default to a timestamp. The gro
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
I'm going to remove my original -1 from this thread and vote +1 for it. My apologies for helping to create this major ruckus. This type of heated discussion does not help build communities and cross community interactions that would benefit all of us in many ways. That is especially so because this has partly become ServiceMix vs. WS .. which is terrible because that's not what the discussions should be about at all. In any case, the WS project is BIG at the moment and I'd personally -1 any proposal to add 20+ more committers to our already overloaded committer list. So, if the ServiceMix folks feel that a BPEL engine needs to be near to their heart, then I'm all for it. I realize that my knowledge of JBI isn't enough to have a strong position on the technical rationale for it but am happy to defer to folks likes James, Dan, Aron and others that obviously do. I'm not on the Geronimo PMC and so have no part of this vote formally. When this finds its way into a vote on the Incubator PMC (which I'm on) I will read the proposal and vote on it; assuming it meets the criteria of not being code thrown over the wall, etc. etc. I'll be +1. Good luck folks .. I'll keep an eye on it and look to participate where possible and appropriate. Sanjiva. On Fri, 2006-02-03 at 14:18 -0800, Alan D. Cabrera wrote: > Cc'ing the incubator list since Dims is no longer on the Geronimo and > ServiceMix lists. > > > Regards, > Alan > > On 2/3/2006 2:05 PM, Aaron Mulder wrote: > > >Holy crap! What a mess this thread is! I'm not used to being like > >the cool voice of reason. :) > > > >For my 2 cents, a JBI container without BPEL is a hard sell, so I'd go > >a long way to see one available for ServiceMix. > > > >Based on our Geronimo experience, I suspect it would be easier to > >build the two together and then spin off a working BPEL engine down > >the road, rather than call them nominally independent projects but in > >truth have them so tightly linked during development that you can't > >realistically use one without the other and there's a lot of fuss > >about having the latest SNAPSHOT of this not work against HEAD of that > >and so on. > > > >So here's my +1 to include the BPEL donation in ServiceMix, but I > >won't argue too strenuously if people want to bring it into Geronimo > >instead (assuming we get the latest Geronimo/ServiceMix integration > >code from Guillaume! :) On the other hand, I think it might be a bit > >awkward as a standalone project from day 1. > > > >Thanks, > >Aaron > > > >On 2/3/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: > > > > > >>After some thought about this, I will give it a +1. > >> > >>We're seeing a lot of overlap lately between the WS-* folks and the J2EE > >>folks. Like lots of projects lately, I don't think this code donation > >>fits strictly into one category. And to say that it strictly belongs one > >>place or another is a mistake. > >> > >>I think the Sybase and ServiceMix people have made it clear that they > >>are dedicated to working on this. I know the ws-* people are stretched > >>with the many many specs to implement, so from a practical standpoint I > >>think the ServiceMix location works. Lets closely monitor the community > >>and see where it goes. At a future date we can readdress the location. > >> > >>Regarding other developers and overlapping projects, I would just like > >>to make it clear that we still definitely welcome other people and their > >>involvement. Accepting this donation into ServiceMix does not preclude > >>any involvement with others. If we need to package things different or > >>provide different interfaces or whatever, its all up for discussion and > >>patches > >> > >>- Dan > >> > >> > >>James Strachan wrote: > >> > >> > >>>We have received the generous donation of a complete and working BPE > >>>engine to the ServiceMix project... > >>>http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL > >>> PROTECTED] > >>> > >>> > >>>the contributor has offered to donate to Apache & complete the > >>>necessary software grants & IP clearance and to work with us on > >>>integrating it into ServiceMix. > >>> > >>>For those of you maybe not aware; ServiceMIx is an ESB project defined > >>>around JBI (JSR 208) the JCP standard API to integration components > >>>along with being the standard container model for a BPE. ServiceMix > >>>already has the JBI container and has a suite of JBI integration > >>>components already for smart routing, transformation, rules, > >>>scripting, auditing etc... > >>>http://incubator.apache.org/servicemix/Components > >>> > >>>So it makes complete sense to add a BPE to that component suite. Note > >>>that since ServiceMix already has integration components to Apache > >>>Axis and Apache Tuscany, the integration of the BPE with ServiceMix > >>>should benefit those projects too (with Apache Synapse possibly too > >>>via the Axis integration - though we need to work on that one a bit). > >>
Re: Spring support in Geronimo
On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote: > I don't think you'll be able to see anything in a jndi viewer since > we don't have a global jndi context :-( > Have you tried using my SpringTransactionManager instead of spring's > JtaTransactionManager? Where is your mythical SpringTransactionManager? > Is your ejb clearly labelled for BMT? If so, the UT should be there > if you are accessing spring from the ejb in the same thread as the > ejb call and spring is not changing any of the initial context system > properties. Um... for the record its not really my bean... I was just given this app that runs on WAS5 and asked to make it run on Geronimo. And, it looks like they are all Container managed (Container is everywhere). * * * What Spring and Hibernate need is a way to get a handle on the containers TXM. I had just tried using the org.springframework.transaction.jta.JtaTransactionManager. But did not get very far with testing this stuff out because every 10 minutes someone comes by and bugs me for something... :-( --jason
Re: Spring support in Geronimo
I don't think you'll be able to see anything in a jndi viewer since we don't have a global jndi context Have you tried using my SpringTransactionManager instead of spring's JtaTransactionManager? Is your ejb clearly labelled for BMT? If so, the UT should be there if you are accessing spring from the ejb in the same thread as the ejb call and spring is not changing any of the initial context system properties. thanks david jencks On Feb 3, 2006, at 5:01 PM, Jason Dillon wrote: Is a JTA UserTransaction supposed to be bound as java:comp/UserTransaction, from inside a EAR/EJB context? I'm getting unhappy exceptions like: Caused by: org.springframework.transaction.TransactionSystemException: JTA UserTransaction is not available at JNDI location [java:comp/UserTransaction]; nested exception is javax.naming.NameNotFoundException: UserTransaction at org.springframework.transaction.jta.JtaTransactionManager.lookupUserTr ansaction(JtaTransactionManager.java:359) at org.springframework.transaction.jta.JtaTransactionManager.afterPropert iesSet(JtaTransactionManager.java:312) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanF actory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1065) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanF actory.createBean(AbstractAutowireCapableBeanFactory.java:343) ... 65 more I've been meaning to download a JNDI viewer so I can actually see what's in there. --jason
[STOP] FUD Clarification
Greg Wilkins wrote: I disagree that all contributions must go via the incubator. This is clearly within the scope of servicemix and there is no need to develope a community around this code. All code contributions MUST be vetted by the incubator PMC. Only a PMC is authorized by the board to accept code grants (so the Foo project PMC then accepts a code contribution, and hands it off under IP Clearance to the Incubator PMC for approval.) A PPMC is NOT a PMC, and therefore does not have the legal authority granted by the Board to accept code grants on behalf of the foundation. They may indicate they desire to accept a specific code grant, and request that the Incubator PMC ratify their choice.
Re: Spring support in Geronimo
Only in an EJB using bean managed transactions. -dain On Feb 3, 2006, at 5:01 PM, Jason Dillon wrote: Is a JTA UserTransaction supposed to be bound as java:comp/UserTransaction, from inside a EAR/EJB context? I'm getting unhappy exceptions like: Caused by: org.springframework.transaction.TransactionSystemException: JTA UserTransaction is not available at JNDI location [java:comp/UserTransaction]; nested exception is javax.naming.NameNotFoundException: UserTransaction at org.springframework.transaction.jta.JtaTransactionManager.lookupUserTr ansaction(JtaTransactionManager.java:359) at org.springframework.transaction.jta.JtaTransactionManager.afterPropert iesSet(JtaTransactionManager.java:312) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanF actory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1065) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanF actory.createBean(AbstractAutowireCapableBeanFactory.java:343) ... 65 more I've been meaning to download a JNDI viewer so I can actually see what's in there. --jason
Re: Spring support in Geronimo
Is a JTA UserTransaction supposed to be bound as java:comp/UserTransaction, from inside a EAR/EJB context? I'm getting unhappy exceptions like: Caused by: org.springframework.transaction.TransactionSystemException: JTA UserTransaction is not available at JNDI location [java:comp/UserTransaction]; nested exception is javax.naming.NameNotFoundException: UserTransaction at org.springframework.transaction.jta.JtaTransactionManager.lookupUserTransaction(JtaTransactionManager.java:359) at org.springframework.transaction.jta.JtaTransactionManager.afterPropertiesSet(JtaTransactionManager.java:312) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1065) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:343) ... 65 more I've been meaning to download a JNDI viewer so I can actually see what's in there. --jason
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
Ic... for some reason I had expected to find the maven1 artifacts under 'geronimo-spec' still. Thanks for pointing this out. :-) --jason On 2/3/06, Brett Porter <[EMAIL PROTECTED]> wrote: > cvs.apache.org/repository is for snapshots only an dis not mirrored. > > www.apache.org/dist/java-repository is for releases and is both > mirrored as part of the normal release mirroring, and synced to > ibiblio. > > - Brett > > On 2/4/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > On 2/3/2006 2:57 PM, David Blevins wrote: > > > > > > > > On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote: > > > > > >> Why aren't the spec jars for 1.0 published to the Maven 1 central repo > > >> in addition to the central Maven 2 repo? > > >> > > > > > > fyi, http://www.apache.org/dist/java-repository/ > > > org.apache.geronimo.specs/jars/ > > > > Uh oh. How is that different than the URL that I just mentioned? > > > > > > Regards, > > Alan > > > > > > > > >
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
Ok, I need to update the POM. Thanks. Regards, Alan On 2/3/2006 4:23 PM, Brett Porter wrote: cvs.apache.org/repository is for snapshots only an dis not mirrored. www.apache.org/dist/java-repository is for releases and is both mirrored as part of the normal release mirroring, and synced to ibiblio. - Brett On 2/4/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: On 2/3/2006 2:57 PM, David Blevins wrote: On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote: Why aren't the spec jars for 1.0 published to the Maven 1 central repo in addition to the central Maven 2 repo? fyi, http://www.apache.org/dist/java-repository/ org.apache.geronimo.specs/jars/ Uh oh. How is that different than the URL that I just mentioned? Regards, Alan
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
cvs.apache.org/repository is for snapshots only an dis not mirrored. www.apache.org/dist/java-repository is for releases and is both mirrored as part of the normal release mirroring, and synced to ibiblio. - Brett On 2/4/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > On 2/3/2006 2:57 PM, David Blevins wrote: > > > > > On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote: > > > >> Why aren't the spec jars for 1.0 published to the Maven 1 central repo > >> in addition to the central Maven 2 repo? > >> > > > > fyi, http://www.apache.org/dist/java-repository/ > > org.apache.geronimo.specs/jars/ > > Uh oh. How is that different than the URL that I just mentioned? > > > Regards, > Alan > > > >
Re: [VOTE-RESULT] Yoko - A CORBA Server Sub-Project Proposal - PASSED
On 1/31/2006 8:23 PM, Alan D. Cabrera wrote: Noel J. Bergman wrote, On 1/31/2006 7:27 PM: Alan, Could you folks turn up some additional Mentors? We have not adopted a formal policy to require more than one --- yet --- but I'd like to see more than one. Sure, good idea. The only person who's stepped up and volunteered is Geir. Is there anyone else? Are two mentors enough? Regards, Alan
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> Does that mean that Hernan should keep working or stop?
It really doesn't matter to me. I was simply trying to get the Epiq
CSS applied in a fast and easy manner. Being that the Geronimo website
is already in xdoc format, I just figured Maven was the easiest way to
do this. And after spending only about 10 mins, I had produced this:
http://people.apache.org/~bsnyder/geronimo/site/docs/
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: ActiveMQ directory as peer to geronimo-1.0 directory?
On 2/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > Any idea why an ActiveMQ directory gets created as a peer to the > top-level geronimo-1.0 directory. Looks like this directory contains > message state, and I'd expect to see it under > geronimo-1.0/var/activemq. > > Is this a known issue? Any reason why the directory is not under var? I hadn't noticed it before, and if that's true, I'd say there's likely no reason it's not under /var other than we haven't taken a close enough look at what goes where. As we're talking about supporting multiple servers out of the same installation, though, I'd think that definitely needs to go under /var. Want to create a JIRA? Thanks, Aaron
Re: Oracle XA RAR for G1.0?
If the RAR is specific to the driver, don't we want to compile against a JDK 1.4 driver not a JDK 1.2 driver? Thanks, Aaron On 2/3/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I think David means that it has not been extensively tested and so there are > no > gurantees that you'll simply be able to drop it in. I'm currently working on > a > DB2 XA RAR and am still working out some kinks. It should work well, we're > just > not sure its been testd enough to know that it does. > > I looked on CodeHaus and it appears that Jeremy had not previous released a > SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 > classes12.jar. > > I've published it and it is called > tranql/rars/tranql-connector-oracle-xa-1.0-SNAPSHOT.rar > > If someone can try this out then that would be excellent. I have only > compiled > it and not tested it so caveat emptor. > > lichtner wrote: > > On Fri, 3 Feb 2006, David Jencks wrote: > > > > > >>It is likely to work if you build it. However I don't know that it > >>has been used in the last year or more, so I won't make any > >>promises. Matt might have tried it, I don't know. We have been a > >>bit reluctant to publish it without more evidence that it works well. > > > > > > Why would it not work well? When I was in my last job I remember getting > > that rar to work with mysql xa, so it probably also works with Oracle xa. > > > > > > >
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
On 2/3/2006 2:57 PM, David Blevins wrote: On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote: Why aren't the spec jars for 1.0 published to the Maven 1 central repo in addition to the central Maven 2 repo? fyi, http://www.apache.org/dist/java-repository/ org.apache.geronimo.specs/jars/ Uh oh. How is that different than the URL that I just mentioned? Regards, Alan
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Sanjiva Weerawarana wrote: Hi James, We're not sucking in another project. Its a contribution of code only. How is this any different than has already happened on Geronimo, Agila (twister), Harmony etc? Geronimo is not an incubating project and hence can bring more stuff in. The Agila/Twister merger was done thru the incubator (and is still ongoing and IMO unlikely to complete). Harmony- I'm not sure what you're referring to (I haven't followed it much). In harmony we're bringing in donations from people who are contributing to our primary mission, creating a fully working implementation of J2SE. That means that implementations of both the VM and the class libraries, and that is what is being donated and accepted. geir
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
The Maven 1 central repo *is* the maven 2 central repo. I expect they just have a different group ID to what you expect. I suggest all the old ones (and any releases inadvertently added) should be removed from cvs.apache.org to have people move to the released versions. - Brett On 2/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > Why aren't the spec jars for 1.0 published to the Maven 1 central repo > in addition to the central Maven 2 repo? > > --jason >
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote: Why aren't the spec jars for 1.0 published to the Maven 1 central repo in addition to the central Maven 2 repo? fyi, http://www.apache.org/dist/java-repository/ org.apache.geronimo.specs/jars/ -David
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
how does that make any sense? Davanum Srinivas wrote: Then start the BPEL project under Geronimo. *NOT* under ServiceMix. -- dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: On 3 Feb 2006, at 15:08, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. No, it is not worth looking at them, if the intent is to use them as precedents of a process some are finding objectionable. Saying, 'They did it so why can't we?' is not appropriate. I guess I didn't explain myself well there at all Ken sorry. (I'm full of cold :( ). I was just trying to say I'd rather see large, successful communities form first, then if need be parts of the project are split off if they become so wildly successful by themselves. So I was trying to show some examples of projects which maybe could have benefited from starting inside a larger, less granular project/community first rather than starting small and dwindling then being merged back together again due to inactivity. e.g. both Geronimo and Jakarta Commons have a broad range of components inside them - many of which are reusable by themselves - in both cases the courser grained projects helped grow a larger more diverse community IMHO. James --- http://radio.weblogs.com/0112098/ -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Rodent of Unusual Size wrote: This is all hypothetical; I don't know if there *are* people who'd want to work on it but not ServiceMix, and I have to take on faith the remarks that there are other packages that would like a BPEL engine without ServiceMix attached. I don't think you need much faith to believe that a BPEL engine is general purpose. I think that there are several projects at the ASF that have interest and would benefit from participation in such an beastie. geir
Re: Geronimo Specs for 1.0 only published to Maven 2 repo?
On 2/3/2006 2:49 PM, Jason Dillon wrote: Why aren't the spec jars for 1.0 published to the Maven 1 central repo in addition to the central Maven 2 repo? They seem to be in http://cvs.apache.org/repository/org.apache.geronimo.specs/jars/. Regards, Alan
Geronimo Specs for 1.0 only published to Maven 2 repo?
Why aren't the spec jars for 1.0 published to the Maven 1 central repo in addition to the central Maven 2 repo? --jason
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Cc'ing the incubator list since Dims is no longer on the Geronimo and ServiceMix lists. Regards, Alan On 2/3/2006 2:05 PM, Aaron Mulder wrote: Holy crap! What a mess this thread is! I'm not used to being like the cool voice of reason. :) For my 2 cents, a JBI container without BPEL is a hard sell, so I'd go a long way to see one available for ServiceMix. Based on our Geronimo experience, I suspect it would be easier to build the two together and then spin off a working BPEL engine down the road, rather than call them nominally independent projects but in truth have them so tightly linked during development that you can't realistically use one without the other and there's a lot of fuss about having the latest SNAPSHOT of this not work against HEAD of that and so on. So here's my +1 to include the BPEL donation in ServiceMix, but I won't argue too strenuously if people want to bring it into Geronimo instead (assuming we get the latest Geronimo/ServiceMix integration code from Guillaume! :) On the other hand, I think it might be a bit awkward as a standalone project from day 1. Thanks, Aaron On 2/3/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: After some thought about this, I will give it a +1. We're seeing a lot of overlap lately between the WS-* folks and the J2EE folks. Like lots of projects lately, I don't think this code donation fits strictly into one category. And to say that it strictly belongs one place or another is a mistake. I think the Sybase and ServiceMix people have made it clear that they are dedicated to working on this. I know the ws-* people are stretched with the many many specs to implement, so from a practical standpoint I think the ServiceMix location works. Lets closely monitor the community and see where it goes. At a future date we can readdress the location. Regarding other developers and overlapping projects, I would just like to make it clear that we still definitely welcome other people and their involvement. Accepting this donation into ServiceMix does not preclude any involvement with others. If we need to package things different or provide different interfaces or whatever, its all up for discussion and patches - Dan James Strachan wrote: We have received the generous donation of a complete and working BPE engine to the ServiceMix project... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL PROTECTED] the contributor has offered to donate to Apache & complete the necessary software grants & IP clearance and to work with us on integrating it into ServiceMix. For those of you maybe not aware; ServiceMIx is an ESB project defined around JBI (JSR 208) the JCP standard API to integration components along with being the standard container model for a BPE. ServiceMix already has the JBI container and has a suite of JBI integration components already for smart routing, transformation, rules, scripting, auditing etc... http://incubator.apache.org/servicemix/Components So it makes complete sense to add a BPE to that component suite. Note that since ServiceMix already has integration components to Apache Axis and Apache Tuscany, the integration of the BPE with ServiceMix should benefit those projects too (with Apache Synapse possibly too via the Axis integration - though we need to work on that one a bit). Also having a BPE fully integrated into Geronimo via the JBI container would mean that we could start to orchestrate pretty much everything in the Geronimo stack! I'm certainly very excited by this move... [ ] +1 accept the donation into the ServiceMix incubator project [ ] 0 don't mind either way [ ] -1 I object because: ... Here's my +1 James --- http://radio.weblogs.com/0112098/ -- Dan Diephouse Envoi Solutions LLC http://envoisolutions.com http://netzooid.com/blog
Re: Oracle XA RAR for G1.0?
Awesome. I will given 'em a shot. Thanks :-) --jason On 2/3/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I think David means that it has not been extensively tested and so there are > no > gurantees that you'll simply be able to drop it in. I'm currently working on > a > DB2 XA RAR and am still working out some kinks. It should work well, we're > just > not sure its been testd enough to know that it does. > > I looked on CodeHaus and it appears that Jeremy had not previous released a > SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 > classes12.jar. > > I've published it and it is called > tranql/rars/tranql-connector-oracle-xa-1.0-SNAPSHOT.rar > > If someone can try this out then that would be excellent. I have only > compiled > it and not tested it so caveat emptor. > > lichtner wrote: > > On Fri, 3 Feb 2006, David Jencks wrote: > > > > > >>It is likely to work if you build it. However I don't know that it > >>has been used in the last year or more, so I won't make any > >>promises. Matt might have tried it, I don't know. We have been a > >>bit reluctant to publish it without more evidence that it works well. > > > > > > Why would it not work well? When I was in my last job I remember getting > > that rar to work with mysql xa, so it probably also works with Oracle xa. > > > > > > >
ActiveMQ directory as peer to geronimo-1.0 directory?
Any idea why an ActiveMQ directory gets created as a peer to the top-level geronimo-1.0 directory. Looks like this directory contains message state, and I'd expect to see it under geronimo-1.0/var/activemq. Is this a known issue? Any reason why the directory is not under var? --jason
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Holy crap! What a mess this thread is! I'm not used to being like the cool voice of reason. :) For my 2 cents, a JBI container without BPEL is a hard sell, so I'd go a long way to see one available for ServiceMix. Based on our Geronimo experience, I suspect it would be easier to build the two together and then spin off a working BPEL engine down the road, rather than call them nominally independent projects but in truth have them so tightly linked during development that you can't realistically use one without the other and there's a lot of fuss about having the latest SNAPSHOT of this not work against HEAD of that and so on. So here's my +1 to include the BPEL donation in ServiceMix, but I won't argue too strenuously if people want to bring it into Geronimo instead (assuming we get the latest Geronimo/ServiceMix integration code from Guillaume! :) On the other hand, I think it might be a bit awkward as a standalone project from day 1. Thanks, Aaron On 2/3/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: > After some thought about this, I will give it a +1. > > We're seeing a lot of overlap lately between the WS-* folks and the J2EE > folks. Like lots of projects lately, I don't think this code donation > fits strictly into one category. And to say that it strictly belongs one > place or another is a mistake. > > I think the Sybase and ServiceMix people have made it clear that they > are dedicated to working on this. I know the ws-* people are stretched > with the many many specs to implement, so from a practical standpoint I > think the ServiceMix location works. Lets closely monitor the community > and see where it goes. At a future date we can readdress the location. > > Regarding other developers and overlapping projects, I would just like > to make it clear that we still definitely welcome other people and their > involvement. Accepting this donation into ServiceMix does not preclude > any involvement with others. If we need to package things different or > provide different interfaces or whatever, its all up for discussion and > patches > > - Dan > > > James Strachan wrote: > > We have received the generous donation of a complete and working BPE > > engine to the ServiceMix project... > > http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL > > PROTECTED] > > > > > > the contributor has offered to donate to Apache & complete the > > necessary software grants & IP clearance and to work with us on > > integrating it into ServiceMix. > > > > For those of you maybe not aware; ServiceMIx is an ESB project defined > > around JBI (JSR 208) the JCP standard API to integration components > > along with being the standard container model for a BPE. ServiceMix > > already has the JBI container and has a suite of JBI integration > > components already for smart routing, transformation, rules, > > scripting, auditing etc... > > http://incubator.apache.org/servicemix/Components > > > > So it makes complete sense to add a BPE to that component suite. Note > > that since ServiceMix already has integration components to Apache > > Axis and Apache Tuscany, the integration of the BPE with ServiceMix > > should benefit those projects too (with Apache Synapse possibly too > > via the Axis integration - though we need to work on that one a bit). > > > > Also having a BPE fully integrated into Geronimo via the JBI container > > would mean that we could start to orchestrate pretty much everything > > in the Geronimo stack! I'm certainly very excited by this move... > > > > > > [ ] +1 accept the donation into the ServiceMix incubator project > > [ ] 0 don't mind either way > > [ ] -1 I object because: ... > > > > > > Here's my +1 > > > > James > > --- > > http://radio.weblogs.com/0112098/ > > > > > -- > Dan Diephouse > Envoi Solutions LLC > http://envoisolutions.com > http://netzooid.com/blog > >
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 2/3/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> > On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> >
> > > I'll look through the user guide although checking at the current site I
> > > count only 15 pages. I am
> > > wondering if it is worth to invest in xdoc and multiplying the number of
> > > files and complexity when
> > > this site is relatively simple to maintain in HTML directly (static pages
> > > + low number of pages).
> >
> > All of the site docs are in xdoc format already. I'll check in what
> > I've got so all you need to do is run:
> >
> > maven site
> >
> > And it will build the Geronimo site using Maven and my start on it. A
> > word of warning, I have not yet begun to apply the Epiq CSS.
>
> I forgot to include this link. Check out the URL below to see what my
> work produces so far:
>
> https://svn.apache.org/repos/asf/geronimo/site/docs
Sorry! My apologies, the URL above is wrong. Below is the correct one:
http://people.apache.org/~bsnyder/geronimo/site/docs/
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Mulder wrote: > I'm not sure how to interpret this; are Ken/Noel suggesting that we > should stop using Confluence for the time being, or just that there > are more obstacles to get it fully implemented than were initially > expected? Probably the latter. I wasn't aware of the performance aspect. What's up now is figuring out how to be able to use it for docco *development*, but something more robust for docco *reference*. Until we have a plan for that, leaving things the way they are right now is safest -- but that's only an interim thing. Bear in mind that the concern may extend beyond Confluence; if the system is getting hammered, *all* services it provides are going to suffer. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+PRNZrNPMCpn3XdAQLQdAQAm/+9/YjOnS/d82a95hI89/M/IB0u82JT GcweECRO7NjRekR4fHMZgjl66vyr8Qo1EB3saf82Rmjwgyh+6F7Ja6RX4H5g4qmr 1dBh5ciYrrph+8yuNAsuEc4ahGf/d4YDodw1q4HOQUxOUe8p1BuMZ0H/6U+7VHnn oqCVTA3RcRQ= =Tzrw -END PGP SIGNATURE-
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
Does that mean that Hernan should keep working or stop?
Bruce Snyder wrote:
On 2/3/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Feb 3, 2006, at 12:13 PM, Bruce Snyder wrote:
On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
I am investigating the source for the geronimo.apache.org site and
see that this site, and AFAICT
all apache sites, is based on XML templates that use ant to build
the HTML based on vsl stylesheets.
Is this a *RULE* or we can use HTML and CSS directly?
We can do whatever we prefer and I would prefer that we create a Maven
website. It's pretty easy to do and I'm very familiar with it. All it
requires are xdocs formatted documention as outlined in the Maven 1.1
user guide.
I was really hoping that we could use maven 2 to build the website.
I believe that Jason van Zyl started work on converting the epiq
template to a maven site template.
I'll ping Jason about it.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
[jira] Commented: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=comments#action_12365134 ] David Jencks commented on GERONIMO-1518: This patch doesn't work very well for me. The first time I tried jetty I got a server that starts but the console didn't work (got the first page but could not log in). I tried tomcat and got exceptions in the "log" window during installation. The resulting server did not start due to missing geronimo-spec/geronimo-spec-corba/2.3-rc4/jar . Then I tried jetty again and got the same wont start due to missing geronimo-spec/geronimo-spec-corba/2.3-rc4/jar error. I dont think that trying to copy the dependencies by hand will work because it is impossible to maintain the dependency info in the installer synchronized with the geronimo-service.xml files /the classpath in the actual configurations. I think that using the assembly plugin code to install cars from a repo inside the installer jar is the only approach that will work, even short term. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- 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: Why Confluence cannot not be used as a wiki, and how it might be fixed
I'm not sure how to interpret this; are Ken/Noel suggesting that we should stop using Confluence for the time being, or just that there are more obstacles to get it fully implemented than were initially expected? Thanks, Aaron On 2/3/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > Forwarding to the dev@ list with permission. This > is where it belongs. > -- > #kenP-)} > > Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ > Author, developer, opinionist http://Apache-Server.Com/ > > "Millennium hand and shrimp!" > > > > -- Forwarded message -- > From: "Noel J. Bergman" <[EMAIL PROTECTED]> > To: "Hernan Cunico" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > Date: Fri, 3 Feb 2006 10:08:19 -0500 > Subject: Why Confluence cannot not be used as a wiki, and how it might be > fixed > To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't > be used as a *primary* project website if slashdotting is likely." Read > "slashdotting" as heavy load, and we experience sufficient load on the Wiki > to make caching mandatory. > > See: > http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach > ing+Proxy+Server > > The comment: > > "The main problem with the reverse-proxy solution is that every > Confluence page is built dynamically for whichever user is > currently accessing it." > > is a typical indicator of a common problem in many dynamic content systems, > which all too often neglect the fact that 99.999+% of all traffic is going > to be relatively static and anonymous. Dynamic does not mean ephemeral, and > that distinction is missed all too often. > > The facts are that most Wiki access is anonymous, and Wiki content is almost > entirely static and should be cachable. Confluence intentionally breaks > caches, and that behavior needs to be fixed. There are a number of possible > solutions. > > One way, and just a simple one, since there are others, would be for > anonymous and authenticated access could have different URLs, e.g., > mydomain.tld/confluence/anon/ for the public, and > mydomain.tld/confluence/auth/ for authenticated users. That would permit > the vast majority of accesses to be cached. "WAIT", you say, "What about > when someone edits the page under the /auth/ path? Won't that cause a > problem for viewers in the /anon/ path?" Not if the URLs are properly > designed, and the system is supporting Conditional Get. The /anon/ path > should be handling Conditional Get based upon the timestamp of the page > resource. So most GET requests will simply return 304, unless the page has > been changed, in which case the updated resource can be returned and cached. > > So these are technical issues (Joshua Slive outlined other, related, ones), > and the ball has been in Atlassian's court to provide some resolution. > > --- Noel > > > >
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>
> > I'll look through the user guide although checking at the current site I
> > count only 15 pages. I am
> > wondering if it is worth to invest in xdoc and multiplying the number of
> > files and complexity when
> > this site is relatively simple to maintain in HTML directly (static pages +
> > low number of pages).
>
> All of the site docs are in xdoc format already. I'll check in what
> I've got so all you need to do is run:
>
> maven site
>
> And it will build the Geronimo site using Maven and my start on it. A
> word of warning, I have not yet begun to apply the Epiq CSS.
I forgot to include this link. Check out the URL below to see what my
work produces so far:
https://svn.apache.org/repos/asf/geronimo/site/docs
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> I'll look through the user guide although checking at the current site I
> count only 15 pages. I am
> wondering if it is worth to invest in xdoc and multiplying the number of
> files and complexity when
> this site is relatively simple to maintain in HTML directly (static pages +
> low number of pages).
All of the site docs are in xdoc format already. I'll check in what
I've got so all you need to do is run:
maven site
And it will build the Geronimo site using Maven and my start on it. A
word of warning, I have not yet begun to apply the Epiq CSS.
> > If you have a user account at the ASF you can publish HTML from
> > http://people.apache.org/ and this can be used as a test spot for the
> > site.
>
> I'm a "simple mortal", not a committer :) don't write have access.
>
> In fact, subject aside, not being a committer I can't join the infra dist
> list neither to follow up
> on the confluence thread.
I think we should look into getting you committer status at least for
the site directory which is here:
https://svn.apache.org/repos/asf/geronimo/site
Are there opinions on this from anyone else?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> On Feb 3, 2006, at 12:13 PM, Bruce Snyder wrote:
>
> > On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> >
> >> I am investigating the source for the geronimo.apache.org site and
> >> see that this site, and AFAICT
> >> all apache sites, is based on XML templates that use ant to build
> >> the HTML based on vsl stylesheets.
> >> Is this a *RULE* or we can use HTML and CSS directly?
> >
> > We can do whatever we prefer and I would prefer that we create a Maven
> > website. It's pretty easy to do and I'm very familiar with it. All it
> > requires are xdocs formatted documention as outlined in the Maven 1.1
> > user guide.
>
> I was really hoping that we could use maven 2 to build the website.
> I believe that Jason van Zyl started work on converting the epiq
> template to a maven site template.
I'll ping Jason about it.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
Bruce Snyder wrote:
On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
I am investigating the source for the geronimo.apache.org site and see that
this site, and AFAICT
all apache sites, is based on XML templates that use ant to build the HTML
based on vsl stylesheets.
Is this a *RULE* or we can use HTML and CSS directly?
We can do whatever we prefer and I would prefer that we create a Maven
website. It's pretty easy to do and I'm very familiar with it. All it
requires are xdocs formatted documention as outlined in the Maven 1.1
user guide.
I'll look through the user guide although checking at the current site I count only 15 pages. I am
wondering if it is worth to invest in xdoc and multiplying the number of files and complexity when
this site is relatively simple to maintain in HTML directly (static pages + low number of pages).
Is it planned to have a *trunk* for the site being updated in svn. What is the
process for updating
the web site?
The current site is here:
https://svn.apache.org/repos/asf/geronimo/site
and I was going to continue working there with the intention of
checking in any of the work toward the Maven website.
It will also be cool to have a *test* URL where everybody can see the progress
of the upgrade and
provide feedback to the new L&F and structure.
If you have a user account at the ASF you can publish HTML from
http://people.apache.org/ and this can be used as a test spot for the
site.
I'm a "simple mortal", not a committer :) don't write have access.
In fact, subject aside, not being a committer I can't join the infra dist list neither to follow up
on the confluence thread.
Cheers!
Hernan
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On Feb 3, 2006, at 12:13 PM, Bruce Snyder wrote: On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: I am investigating the source for the geronimo.apache.org site and see that this site, and AFAICT all apache sites, is based on XML templates that use ant to build the HTML based on vsl stylesheets. Is this a *RULE* or we can use HTML and CSS directly? We can do whatever we prefer and I would prefer that we create a Maven website. It's pretty easy to do and I'm very familiar with it. All it requires are xdocs formatted documention as outlined in the Maven 1.1 user guide. I was really hoping that we could use maven 2 to build the website. I believe that Jason van Zyl started work on converting the epiq template to a maven site template. -dain
Re: Spring support in Geronimo
This looks like it should work. I think there is some chance that it would work even better if we provided a transaction manager that wraps our transactioncontextmanager, but it's too early in the morning for me to think straight about it. If you get into problem with connections not being returned to the pool let me know and I will think about it harder. Thanks David... its too early for me too (at 12:20pm :-P) How do you provide access to the jdbc connection? By declaring a resource-ref in the j2ee component that is calling hibernate, or some other way? The datasource(s) are accessed by a resource-ref, from a EAR->EJB, which then delegates to Spring which links up the application code to Hibernate DAOs. * * * I have yet yo try this out yet... its gonna be a fun friday... oh boy :-\ --jason
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
Hernan, I'm not sure about the rule but I think it is understood by folks. IIRC Geir did the current horrible WebSite so he can comment better than I can :-) When you check out the website the URL is https://svn.apache.org/repos/asf/geronimo/site In that directory there are instructions on how to deploy it so it becomes live. I think Bruce was doing the work on his http://people.apache.org/~bsnyder account for folks to look at so I expect you could do your work elsewhere so long as its temporary. If you have something that you'd like folks to see and lack the ability to host it somewhere I'd be happy to put it on my account and coordinate updates with you. Hernan Cunico wrote: Hi All, I am investigating the source for the geronimo.apache.org site and see that this site, and AFAICT all apache sites, is based on XML templates that use ant to build the HTML based on vsl stylesheets. Is this a *RULE* or we can use HTML and CSS directly? Is it planned to have a *trunk* for the site being updated in svn. What is the process for updating the web site? It will also be cool to have a *test* URL where everybody can see the progress of the upgrade and provide feedback to the new L&F and structure. Cheers! Hernan Original Message Subject: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq Date: Thu, 02 Feb 2006 11:39:31 -0500 From: Hernan Cunico <[EMAIL PROTECTED]> To: dev@geronimo.apache.org References: <[EMAIL PROTECTED]> Hi Bruce, the new look & feel is great. When/how can we move forward. In addition to the new template we should focus on re-structuring and updating the content. I volunteer to work on this update, how can I help? Cheers! Hernan Bruce Snyder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1538?page=all ] Bruce Snyder updated GERONIMO-1538: --- Description: See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/ was: See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/ I've emailed Glenn Wheaton from Epiq asking him to attach the new stylesheets and imagery so that he can grant the ASF a license to the content. Update the website to use the new look and feel from Epiq - Key: GERONIMO-1538 URL: http://issues.apache.org/jira/browse/GERONIMO-1538 Project: Geronimo Type: Improvement Components: website Reporter: Bruce Snyder Assignee: Bruce Snyder See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/
Re: [Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
On 2/3/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> I am investigating the source for the geronimo.apache.org site and see that
> this site, and AFAICT
> all apache sites, is based on XML templates that use ant to build the HTML
> based on vsl stylesheets.
> Is this a *RULE* or we can use HTML and CSS directly?
We can do whatever we prefer and I would prefer that we create a Maven
website. It's pretty easy to do and I'm very familiar with it. All it
requires are xdocs formatted documention as outlined in the Maven 1.1
user guide.
> Is it planned to have a *trunk* for the site being updated in svn. What is
> the process for updating
> the web site?
The current site is here:
https://svn.apache.org/repos/asf/geronimo/site
and I was going to continue working there with the intention of
checking in any of the work toward the Maven website.
> It will also be cool to have a *test* URL where everybody can see the
> progress of the upgrade and
> provide feedback to the new L&F and structure.
If you have a user account at the ASF you can publish HTML from
http://people.apache.org/ and this can be used as a test spot for the
site.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
[Fwd: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq]
Hi All, I am investigating the source for the geronimo.apache.org site and see that this site, and AFAICT all apache sites, is based on XML templates that use ant to build the HTML based on vsl stylesheets. Is this a *RULE* or we can use HTML and CSS directly? Is it planned to have a *trunk* for the site being updated in svn. What is the process for updating the web site? It will also be cool to have a *test* URL where everybody can see the progress of the upgrade and provide feedback to the new L&F and structure. Cheers! Hernan Original Message Subject: Re: [jira] Updated: (GERONIMO-1538) Update the website to use the new look and feel from Epiq Date: Thu, 02 Feb 2006 11:39:31 -0500 From: Hernan Cunico <[EMAIL PROTECTED]> To: dev@geronimo.apache.org References: <[EMAIL PROTECTED]> Hi Bruce, the new look & feel is great. When/how can we move forward. In addition to the new template we should focus on re-structuring and updating the content. I volunteer to work on this update, how can I help? Cheers! Hernan Bruce Snyder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1538?page=all ] Bruce Snyder updated GERONIMO-1538: --- Description: See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/ was: See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/ I've emailed Glenn Wheaton from Epiq asking him to attach the new stylesheets and imagery so that he can grant the ASF a license to the content. Update the website to use the new look and feel from Epiq - Key: GERONIMO-1538 URL: http://issues.apache.org/jira/browse/GERONIMO-1538 Project: Geronimo Type: Improvement Components: website Reporter: Bruce Snyder Assignee: Bruce Snyder See the example of the new look and feel for the site here: http://people.apache.org/~bsnyder/geronimo/site/
[jira] Updated: (GERONIMO-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Paul McMahan updated GERONIMO-1572: --- Geronimo Info: [Patch Available] > Adjust the admin console app so that if the user does not have cookies > enabled, the application presents a custom error page or popup telling the > user that cookies must be enabled (instead of allowing the browser to present > a default 408 error page) > - > > Key: GERONIMO-1572 > URL: http://issues.apache.org/jira/browse/GERONIMO-1572 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Environment: All environments > Reporter: Steve Whitlatch > Assignee: Paul McMahan > Priority: Minor > Attachments: GERONIMO-1572.patch > > Just a suggestion: In Geronimo's administration console application, adjust > its behavior so that rather than dispalying an HTTP Status 408 error message, > display a custom error page or popup with a message stating that for the > application to work properly cookies must be enabled (that is, if that is > actually the case). I found that to be the case. -- 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-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Paul McMahan updated GERONIMO-1572: --- Attachment: GERONIMO-1572.patch attaching a patch for the login page that will check to see if cookies are enabled and if not inform the user that logging into the console requires them to be enabled. > Adjust the admin console app so that if the user does not have cookies > enabled, the application presents a custom error page or popup telling the > user that cookies must be enabled (instead of allowing the browser to present > a default 408 error page) > - > > Key: GERONIMO-1572 > URL: http://issues.apache.org/jira/browse/GERONIMO-1572 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Environment: All environments > Reporter: Steve Whitlatch > Assignee: Paul McMahan > Priority: Minor > Attachments: GERONIMO-1572.patch > > Just a suggestion: In Geronimo's administration console application, adjust > its behavior so that rather than dispalying an HTTP Status 408 error message, > display a custom error page or popup with a message stating that for the > application to work properly cookies must be enabled (that is, if that is > actually the case). I found that to be the case. -- 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-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies mus
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Paul McMahan reassigned GERONIMO-1572: -- Assign To: Paul McMahan > Adjust the admin console app so that if the user does not have cookies > enabled, the application presents a custom error page or popup telling the > user that cookies must be enabled (instead of allowing the browser to present > a default 408 error page) > - > > Key: GERONIMO-1572 > URL: http://issues.apache.org/jira/browse/GERONIMO-1572 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Environment: All environments > Reporter: Steve Whitlatch > Assignee: Paul McMahan > Priority: Minor > > Just a suggestion: In Geronimo's administration console application, adjust > its behavior so that rather than dispalying an HTTP Status 408 error message, > display a custom error page or popup with a message stating that for the > application to work properly cookies must be enabled (that is, if that is > actually the case). I found that to be the case. -- 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] accept donation of a business process engine into the ServiceMix project
After some thought about this, I will give it a +1. We're seeing a lot of overlap lately between the WS-* folks and the J2EE folks. Like lots of projects lately, I don't think this code donation fits strictly into one category. And to say that it strictly belongs one place or another is a mistake. I think the Sybase and ServiceMix people have made it clear that they are dedicated to working on this. I know the ws-* people are stretched with the many many specs to implement, so from a practical standpoint I think the ServiceMix location works. Lets closely monitor the community and see where it goes. At a future date we can readdress the location. Regarding other developers and overlapping projects, I would just like to make it clear that we still definitely welcome other people and their involvement. Accepting this donation into ServiceMix does not preclude any involvement with others. If we need to package things different or provide different interfaces or whatever, its all up for discussion and patches - Dan James Strachan wrote: We have received the generous donation of a complete and working BPE engine to the ServiceMix project... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL PROTECTED] the contributor has offered to donate to Apache & complete the necessary software grants & IP clearance and to work with us on integrating it into ServiceMix. For those of you maybe not aware; ServiceMIx is an ESB project defined around JBI (JSR 208) the JCP standard API to integration components along with being the standard container model for a BPE. ServiceMix already has the JBI container and has a suite of JBI integration components already for smart routing, transformation, rules, scripting, auditing etc... http://incubator.apache.org/servicemix/Components So it makes complete sense to add a BPE to that component suite. Note that since ServiceMix already has integration components to Apache Axis and Apache Tuscany, the integration of the BPE with ServiceMix should benefit those projects too (with Apache Synapse possibly too via the Axis integration - though we need to work on that one a bit). Also having a BPE fully integrated into Geronimo via the JBI container would mean that we could start to orchestrate pretty much everything in the Geronimo stack! I'm certainly very excited by this move... [ ] +1 accept the donation into the ServiceMix incubator project [ ] 0 don't mind either way [ ] -1 I object because: ... Here's my +1 James --- http://radio.weblogs.com/0112098/ -- Dan Diephouse Envoi Solutions LLC http://envoisolutions.com http://netzooid.com/blog
[jira] Created: (GERONIMODEVTOOLS-59) React to configID changes
React to configID changes - Key: GERONIMODEVTOOLS-59 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-59 Project: Geronimo-Devtools Type: Task Components: eclipse-plugin Reporter: Sachin Patel -- 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: Question regard to org.activemq.network.jms package
Hi Hiram: What do I need to include in this patch? Just the source code for my classes? Thanks Fan Li -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: Friday, February 03, 2006 10:12 AM To: activemq-dev@geronimo.apache.org Subject: Re: Question regard to org.activemq.network.jms package Hi Fan, If you submit a patch, we would be glad to add them to the next release. Regards, Hiram On Feb 3, 2006, at 1:07 PM, Li, Fan wrote: > Hi: > > I am currently working on a project that would create a bridge that > enables the communication of applications written using our messaging > system to those applications written using ActiveMQ. The ActiveMQ > package org.activemq.network.jms provides most of the functionalities > I needed in my project. However, I believe that ActiveMQ only provide > foreign Topic to ActiveMQ Topic and foreign Queue to ActiveMQ Queue > bridges, but my project has the need for Queue to Topic and Topic to > Queue bridges. I am going to write my own classes for these, but I am > wondering if ActiveMQ would provide these functionalities in the > future. > > Thanks > Fan Li > >
Re: Question regard to org.activemq.network.jms package
Hi Fan, If you submit a patch, we would be glad to add them to the next release. Regards, Hiram On Feb 3, 2006, at 1:07 PM, Li, Fan wrote: Hi: I am currently working on a project that would create a bridge that enables the communication of applications written using our messaging system to those applications written using ActiveMQ. The ActiveMQ package org.activemq.network.jms provides most of the functionalities I needed in my project. However, I believe that ActiveMQ only provide foreign Topic to ActiveMQ Topic and foreign Queue to ActiveMQ Queue bridges, but my project has the need for Queue to Topic and Topic to Queue bridges. I am going to write my own classes for these, but I am wondering if ActiveMQ would provide these functionalities in the future. Thanks Fan Li
Question regard to org.activemq.network.jms package
Hi: I am currently working on a project that would create a bridge that enables the communication of applications written using our messaging system to those applications written using ActiveMQ. The ActiveMQ package org.activemq.network.jms provides most of the functionalities I needed in my project. However, I believe that ActiveMQ only provide foreign Topic to ActiveMQ Topic and foreign Queue to ActiveMQ Queue bridges, but my project has the need for Queue to Topic and Topic to Queue bridges. I am going to write my own classes for these, but I am wondering if ActiveMQ would provide these functionalities in the future. Thanks Fan Li
Re: gbuild: continuum upgrade
On Feb 2, 2006, at 8:57 PM, David Blevins wrote: We may get a few false build failed messages in the next couple hours, please disregard them. I'll give an "all clear" when all the projects have run. ALL CLEAR -David
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
I do agree with your point James, communities built around a narrow scope are harder to grow and attracting new commiters can become hazardous. However my feeling is that the failure of Agila in attracting new committers (for now) is mostly due to a lack of public exposure and not really to BPEL having a narrow scope. Besides, even if there aren't many committers working on Agila yet, there are people using it. I'm not sure I have any weight at all in this discussion, however I can't see why a BPEL implementation would be developed as part of a JBI implementation. JBI is made to integrate nicely with many components (rules engines, scripting, soap and jms layers, ...), does that mean that all these components should be developed under the ServiceMix umbrella? I don't believe so. My 2 cents. >On 3 Feb 2006, at 16:13, Rodent of Unusual Size wrote:>> Incidentally its worth looking at other projects at Apache like Agila>> and various projects on http://ws.apache.org like EWS, Mirae, Muse,>> WSRF, TSIK etc which are kinda quiet, some near dormant. Making>> projects too small and too granular can sometimes harm the chances of>> creating a vibrant community. Just as the some folks in the WS PMC>> are starting to consider collapsing projects together due to>> inactivity, I think we should stay open to the idea of creating less>> granular projects that can build a thriving community to start with>> then, if the community decides, split things off later if something>> becomes so popular it deserves its own project.>> James, bearing in mind the *content* of Dims questions above,> rather than how he phrased them, would you please expand on> the above to address how Dims apparently interpreted it?The point I was trying to make above has nothing to do with ws-folksor anyone involved in the projects - apologies if my cold-inducedramblings caused any offence. It was more just a general observationon project size and community growth. Its hard growing communities;it takes a lot of time and effort. Projects can be too broad(Jakarta) and too granular - but sometimes its easier to buildcommunity inside a single project with one overall aim (Geronimo forJ2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utilitycode etc) than to have lots of smaller projects.James---http://radio.weblogs.com/0112098/- Show quoted text --To unsubscribe, e-mail: [EMAIL PROTECTED] additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=all ] erik daughtrey updated GERONIMO-1568: - Attachment: installer-delete-car-files.patch This patch applies to branches/1.0 only. The resultant cleanup after an installer based install is about 25MB. > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-delete-car-files.patch > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- 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: Spring support in Geronimo
This looks like it should work. I think there is some chance that it
would work even better if we provided a transaction manager that
wraps our transactioncontextmanager, but it's too early in the
morning for me to think straight about it. If you get into problem
with connections not being returned to the pool let me know and I
will think about it harder. How do you provide access to the jdbc
connection? By declaring a resource-ref in the j2ee component that
is calling hibernate, or some other way?
thanks
david jencks
On Feb 3, 2006, at 12:42 AM, Jason Dillon wrote:
It looks like you can be the first to test out my new
SpringTransactionManager :-). It wraps our
TransactionContextManager in a PlatformTransactionManager
subclass. You need to give it 2 constructor args, the kernel name
and the tcm object name. The normal values are in the comments in
the class.
Aight... kick it down yo.
What does Hibernate need? Can it work off a spring tm or does it
need something else?
I think it wants a special lookup class... I wrote one up tonight
based on comments to the dev list a while ago... creating a proxy
to the TransactionManager instance. I have yet to test it though.
If you can come up with some kind of spring app that ought to work
and uses the spring tm I would be able to test and perhaps debug
my code :-)
I might be able to come up with something simple... though right
now first priority is to just get something... anything working
inside of Geronimo so our SE dept. can test it.
Anyways, looks like spring needs a Geronimo version like:
http://www.springframework.org/docs/api/org/springframework/
transaction/jta/WebSphereTransactionManagerFactoryBean.html
I've yet to look at what this puppy does.
And Hibernate needs a Geronimo version of:
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/
hibernate/transaction/JOTMTransactionManagerLookup.java?
rev=1.1&view=auto
This is what I wrote and will be testing out tomorrow.
package com.solidusnetworks.utils.geronimo;
import java.util.Properties;
import javax.transaction.TransactionManager;
import javax.management.ObjectName;
import net.sf.hibernate.HibernateException;
import net.sf.hibernate.transaction.TransactionManagerLookup;
import org.apache.geronimo.kernel.Kernel;
import org.apache.geronimo.kernel.KernelRegistry;
/**
* Provides lookup of the Geronimo (1.0) transaction manager.
*
* @version $Id$ $Date$
* @author mailto:[EMAIL PROTECTED]">Jason
Dillon
*/
public class GeronimoTransactionManagerLookup
implements TransactionManagerLookup
{
public static final String TXM_GBEAN_NAME =
"geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-
server/1.0/
car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionMa
nager";
public static final String USER_TXN_NAME = "java:comp/
UserTransaction";
public TransactionManager getTransactionManager(final Properties
props) throws HibernateException {
try {
//
// FIXME: This is probably not work when Geronimo
versions change... :-(
//
ObjectName TM_NAME = new ObjectName(TXM_GBEAN_NAME);
Kernel kernel = KernelRegistry.getSingleKernel();
return (TransactionManager) kernel.getProxyManager
().createProxy(TM_NAME, TransactionManager.class);
}
catch (Exception e) {
throw new HibernateException("Failed to lookup Geronimo
transaction manager", e);
}
}
public String getUserTransactionName() {
return USER_TXN_NAME;
}
}
--jason
[jira] Updated: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=all ] erik daughtrey updated GERONIMO-1568: - Geronimo Info: [Patch Available] Description: Changed version. Deleting the car files is a work-around for now and will be done for 1.0.1. was: Version: (was: 1.1) > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- 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] accept donation of a business process engine into the ServiceMix project
On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > community inside a single project with one overall aim (Geronimo for > J2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utility > code etc) than to have lots of smaller projects. Is ServiceMix intended to be a TLP, or will it continue to be a sub-project of Geronimo? This email leads me to believe that ServiceMix might not have a strong overlap with J2EE - which is Geronimo's mission. Hence, might a new TLP be best? -- justin
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 16:13, Rodent of Unusual Size wrote: Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. Making projects too small and too granular can sometimes harm the chances of creating a vibrant community. Just as the some folks in the WS PMC are starting to consider collapsing projects together due to inactivity, I think we should stay open to the idea of creating less granular projects that can build a thriving community to start with then, if the community decides, split things off later if something becomes so popular it deserves its own project. James, bearing in mind the *content* of Dims questions above, rather than how he phrased them, would you please expand on the above to address how Dims apparently interpreted it? The point I was trying to make above has nothing to do with ws-folks or anyone involved in the projects - apologies if my cold-induced ramblings caused any offence. It was more just a general observation on project size and community growth. Its hard growing communities; it takes a lot of time and effort. Projects can be too broad (Jakarta) and too granular - but sometimes its easier to build community inside a single project with one overall aim (Geronimo for J2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utility code etc) than to have lots of smaller projects. James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Ken, I apologize!!! it's just like hitting your head on a brick wall and going around in circles. James, I hereby remove my -1 on the contrib to ServiceMix. Go ahead and do anything you want, however you want, i don't care anymore. If Ken or Noel or any other Geronimo or Incubator PMC member wants to do something then that's their call. Am not going to be part of this any more. thanks, dims On 2/3/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Davanum Srinivas wrote: > > Just what do you define the community as? ws-folks don't count? what > > mentor says does not count? existing Agila folks don't count? Looks > > like the definition of community is everyone who says yes to you and > > everyone else is not part of the community? > > Whoa, whoa, whoa! Let's slow down even more. That's not > an acceptable tone; it's a major escalation. Dims, please > don't infer the worst motives or insults! > > I don't see a direct correlation between the quoted message > and the response above. I assume you're referring, at one > remove, to this by James: > > > Incidentally its worth looking at other projects at Apache like Agila > > and various projects on http://ws.apache.org like EWS, Mirae, Muse, > > WSRF, TSIK etc which are kinda quiet, some near dormant. Making > > projects too small and too granular can sometimes harm the chances of > > creating a vibrant community. Just as the some folks in the WS PMC > > are starting to consider collapsing projects together due to > > inactivity, I think we should stay open to the idea of creating less > > granular projects that can build a thriving community to start with > > then, if the community decides, split things off later if something > > becomes so popular it deserves its own project. > > James, bearing in mind the *content* of Dims questions above, > rather than how he phrased them, would you please expand on > the above to address how Dims apparently interpreted it? > - -- > #kenP-)} > > Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ > Author, developer, opinionist http://Apache-Server.Com/ > > "Millennium hand and shrimp!" > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQCVAwUBQ+OBFZrNPMCpn3XdAQKmSwQAm/tUOt8X2FNfpbz7IbcLVKokJvlRrtZH > 55pij+60OozD893j8sso7jMl9/EY2yYIwDT1mTrqSLMXdW1vZH+Oj2gGbdDwiSPN > nPwgTrenr8seLb7UlGMUr20MOsVKCQ3/ArteNFESQ75X2U+FrM5bKUU9Sj7p92x5 > eySACXAaC1A= > =qOu+ > -END PGP SIGNATURE- > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: > > The TM is in a single download-able jar all by itself; so you can > download only what you need. e.g. here's the latest snapshot of just > the transaction manager... > > We use the same approach in ServiceMix; we make lots of small modular > jars for the parts you need. e.g. here's the JBI component for > working with Tuscany... Thank you for the explanation and examples! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+ODHZrNPMCpn3XdAQKO8gP8Cm0Z3aZ7kKhw0nfXpujDz1ACFv+AjGV/ DJ9Ff0HpN8LNmw63rrB7KVhLI0094tQUlOC+tO10sgDs39ykqEitnndz72h06Eh/ GLiK4LPs3DfMekjHO7LZKwS6v/r6WfU32p9DiaBTvjYtUg0qHb1mGRt0WKutb8Ug ohimowLqMf8= =+hnF -END PGP SIGNATURE-
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Let me jump in here and say that I have to agree w/ Dims, Noel, et al here. We should be focusing on a good vendor experience not wrangling with new and "improved" ways to extend the incubation process, i.e. incubating under an incubating sub-project. To be frank, our new guests are scratching their heads. The incubation process has been honed over the years and is light but adequate. Sybase has explicitly expressed a desire for their technology donation to start in ServiceMix but I'm sure that Geronimo will do. I'll file the requisite paperwork. Let's focus on the *technical* merits of the donation. Let's move on. Regards, Alan On 2/3/2006 7:53 AM, Davanum Srinivas wrote: Then start the BPEL project under Geronimo. *NOT* under ServiceMix. -- dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: On 3 Feb 2006, at 15:08, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. No, it is not worth looking at them, if the intent is to use them as precedents of a process some are finding objectionable. Saying, 'They did it so why can't we?' is not appropriate. I guess I didn't explain myself well there at all Ken sorry. (I'm full of cold :( ). I was just trying to say I'd rather see large, successful communities form first, then if need be parts of the project are split off if they become so wildly successful by themselves. So I was trying to show some examples of projects which maybe could have benefited from starting inside a larger, less granular project/community first rather than starting small and dwindling then being merged back together again due to inactivity. e.g. both Geronimo and Jakarta Commons have a broad range of components inside them - many of which are reusable by themselves - in both cases the courser grained projects helped grow a larger more diverse community IMHO. James --- http://radio.weblogs.com/0112098/ -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Davanum Srinivas wrote: > Just what do you define the community as? ws-folks don't count? what > mentor says does not count? existing Agila folks don't count? Looks > like the definition of community is everyone who says yes to you and > everyone else is not part of the community? Whoa, whoa, whoa! Let's slow down even more. That's not an acceptable tone; it's a major escalation. Dims, please don't infer the worst motives or insults! I don't see a direct correlation between the quoted message and the response above. I assume you're referring, at one remove, to this by James: > Incidentally its worth looking at other projects at Apache like Agila > and various projects on http://ws.apache.org like EWS, Mirae, Muse, > WSRF, TSIK etc which are kinda quiet, some near dormant. Making > projects too small and too granular can sometimes harm the chances of > creating a vibrant community. Just as the some folks in the WS PMC > are starting to consider collapsing projects together due to > inactivity, I think we should stay open to the idea of creating less > granular projects that can build a thriving community to start with > then, if the community decides, split things off later if something > becomes so popular it deserves its own project. James, bearing in mind the *content* of Dims questions above, rather than how he phrased them, would you please expand on the above to address how Dims apparently interpreted it? - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+OBFZrNPMCpn3XdAQKmSwQAm/tUOt8X2FNfpbz7IbcLVKokJvlRrtZH 55pij+60OozD893j8sso7jMl9/EY2yYIwDT1mTrqSLMXdW1vZH+Oj2gGbdDwiSPN nPwgTrenr8seLb7UlGMUr20MOsVKCQ3/ArteNFESQ75X2U+FrM5bKUU9Sj7p92x5 eySACXAaC1A= =qOu+ -END PGP SIGNATURE-
Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Hi, I was just looking into these issues in regard to the activemq and servicemix sites. I really do like confluence a ton and would eventually like to see be part of the ASF infrastructure. What I would like is to just export the confluence content to a static site. This would allow us to also enhance/style/aggregate the content during the export so that nice looking project websites are the results. Regards, Hiram On Feb 3, 2006, at 10:40 AM, Rodent of Unusual Size wrote: Forwarding to the dev@ list with permission. This is where it belongs. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" See: http://confluence.atlassian.com/display/DOC/Running+Confluence +Behind+a+Cach ing+Proxy+Server The comment: "The main problem with the reverse-proxy solution is that every Confluence page is built dynamically for whichever user is currently accessing it." is a typical indicator of a common problem in many dynamic content systems, which all too often neglect the fact that 99.999+% of all traffic is going to be relatively static and anonymous. Dynamic does not mean ephemeral, and that distinction is missed all too often. The facts are that most Wiki access is anonymous, and Wiki content is almost entirely static and should be cachable. Confluence intentionally breaks caches, and that behavior needs to be fixed. There are a number of possible solutions. One way, and just a simple one, since there are others, would be for anonymous and authenticated access could have different URLs, e.g., mydomain.tld/confluence/anon/ for the public, and mydomain.tld/confluence/auth/ for authenticated users. That would permit the vast majority of accesses to be cached. "WAIT", you say, "What about when someone edits the page under the /auth/ path? Won't that cause a problem for viewers in the /anon/ path?" Not if the URLs are properly designed, and the system is supporting Conditional Get. The /anon/ path should be handling Conditional Get based upon the timestamp of the page resource. So most GET requests will simply return 304, unless the page has been changed, in which case the updated resource can be returned and cached. So these are technical issues (Joshua Slive outlined other, related, ones), and the ball has been in Atlassian's court to provide some resolution. --- Noel
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 15:38, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: To use an analogy from Geronimo. You can reuse the Transaction Manager inside Geronimo by itself without anything else from Geronimo. Everything developed within the Geronimo PMC is modular; you can use what you like. Modularity and reuse is a given on all the Geronimo projects I'm aware of (which is most of it). You can download just the parts you want? Or do you have to download the whole thing and only *use* the parts you want? If the latter, can you throw away the parts you don't need, or do you need to have them around? As an example, is the TM a single jar, or part of another? The TM is in a single download-able jar all by itself; so you can download only what you need. e.g. here's the latest snapshot of just the transaction manager... http://cvs.apache.org/repository/geronimo/jars/geronimo- transaction-1.1-SNAPSHOT.jar We use the same approach in ServiceMix; we make lots of small modular jars for the parts you need. e.g. here's the JBI component for working with Tuscany... http://svn.apache.org/repository/incubator-servicemix/jars/servicemix- sca-3.0-SNAPSHOT.jar James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Then start the BPEL project under Geronimo. *NOT* under ServiceMix. -- dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 15:08, Rodent of Unusual Size wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > James Strachan wrote: > >> > >> Incidentally its worth looking at other projects at Apache like Agila > >> and various projects on http://ws.apache.org like EWS, Mirae, Muse, > >> WSRF, TSIK etc which are kinda quiet, some near dormant. > > > > No, it is not worth looking at them, if the intent is to use > > them as precedents of a process some are finding objectionable. > > Saying, 'They did it so why can't we?' is not appropriate. > > I guess I didn't explain myself well there at all Ken sorry. (I'm > full of cold :( ). > I was just trying to say I'd rather see large, successful communities > form first, then if need be parts of the project are split off if > they become so wildly successful by themselves. So I was trying to > show some examples of projects which maybe could have benefited from > starting inside a larger, less granular project/community first > rather than starting small and dwindling then being merged back > together again due to inactivity. > > e.g. both Geronimo and Jakarta Commons have a broad range of > components inside them - many of which are reusable by themselves - > in both cases the courser grained projects helped grow a larger more > diverse community IMHO. > > James > --- > http://radio.weblogs.com/0112098/ > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 15:08, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. No, it is not worth looking at them, if the intent is to use them as precedents of a process some are finding objectionable. Saying, 'They did it so why can't we?' is not appropriate. I guess I didn't explain myself well there at all Ken sorry. (I'm full of cold :( ). I was just trying to say I'd rather see large, successful communities form first, then if need be parts of the project are split off if they become so wildly successful by themselves. So I was trying to show some examples of projects which maybe could have benefited from starting inside a larger, less granular project/community first rather than starting small and dwindling then being merged back together again due to inactivity. e.g. both Geronimo and Jakarta Commons have a broad range of components inside them - many of which are reusable by themselves - in both cases the courser grained projects helped grow a larger more diverse community IMHO. James --- http://radio.weblogs.com/0112098/
Why Confluence cannot not be used as a wiki, and how it might be fixed
Forwarding to the dev@ list with permission. This is where it belongs. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" --- Begin Message --- To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't be used as a *primary* project website if slashdotting is likely." Read "slashdotting" as heavy load, and we experience sufficient load on the Wiki to make caching mandatory. See: http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach ing+Proxy+Server The comment: "The main problem with the reverse-proxy solution is that every Confluence page is built dynamically for whichever user is currently accessing it." is a typical indicator of a common problem in many dynamic content systems, which all too often neglect the fact that 99.999+% of all traffic is going to be relatively static and anonymous. Dynamic does not mean ephemeral, and that distinction is missed all too often. The facts are that most Wiki access is anonymous, and Wiki content is almost entirely static and should be cachable. Confluence intentionally breaks caches, and that behavior needs to be fixed. There are a number of possible solutions. One way, and just a simple one, since there are others, would be for anonymous and authenticated access could have different URLs, e.g., mydomain.tld/confluence/anon/ for the public, and mydomain.tld/confluence/auth/ for authenticated users. That would permit the vast majority of accesses to be cached. "WAIT", you say, "What about when someone edits the page under the /auth/ path? Won't that cause a problem for viewers in the /anon/ path?" Not if the URLs are properly designed, and the system is supporting Conditional Get. The /anon/ path should be handling Conditional Get based upon the timestamp of the page resource. So most GET requests will simply return 304, unless the page has been changed, in which case the updated resource can be returned and cached. So these are technical issues (Joshua Slive outlined other, related, ones), and the ball has been in Atlassian's court to provide some resolution. --- Noel --- End Message ---
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: > > To use an analogy from Geronimo. You can reuse the Transaction > Manager inside Geronimo by itself without anything else from > Geronimo. Everything developed within the Geronimo PMC is modular; > you can use what you like. Modularity and reuse is a given on all the > Geronimo projects I'm aware of (which is most of it). You can download just the parts you want? Or do you have to download the whole thing and only *use* the parts you want? If the latter, can you throw away the parts you don't need, or do you need to have them around? As an example, is the TM a single jar, or part of another? - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+N5AJrNPMCpn3XdAQJ+jgP/eeNzqA+6PnwVCxA5CK2E1dgik+0+fPWX 0D1+ge1Pu8X3yFtnhDRBaKGOV+QgLPi9ftLZq5s6x8VOpy90FD9yFNThDe7pQE0C RQYNu1roEJyPhoD4v3cBnwVXrdaFscRtZM93cvABN3PebyB7B1stTbwx6uql4/vb rjWSvUV81Zc= =/73j -END PGP SIGNATURE-
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Just what do you define the community as? ws-folks don't count? what mentor says does not count? existing Agila folks don't count? Looks like the definition of community is everyone who says yes to you and everyone else is not part of the community? Part of the incubation process is to to generate interest, get people involved, make sure there is wider participation. A proposal and emails on the [EMAIL PROTECTED] are part of that process to get more people involved. Why is there so much resistance to doing that? When paul dropped in you asked him to work on Agila. Is this what you mean by increasing community participation? Is this how you do it? -- dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Davanum Srinivas wrote: > >> Why can't you treat an orchestration engine like a component like the > >> way you treat Axis or XFire? Why does the code have to live within > >> ServiceMix? Lot of us want a BPEL engine, we don't want a JBI > >> container. The code coming in does exactly that, it is a BPEL engine > >> and has no relation to JBI or Java for that matter. Why can't you > >> have > >> a separate project for BPEL and add glue code as a JBI component > >> EXACTLY the way you work with other projects like XFire? > > : > >> We seem to agree on the ends but not on the means. You like a very > >> good integration with a BPEL engine for ServiceMix. I like a very > >> good > >> BPEL engine for its own sake. Am sure we can find people on both > >> sides > >> and some who may like both objectives. > > > > An interesting point. There is no reason people in the ServiceMix > > couldn't also work on a BPEL project. But if we goes through with > > this as proposed, and someone wants a BPEL engine, is it going to > > be necessary to take all of ServiceMix along with it? > > Not at all. > > To use an analogy from Geronimo. You can reuse the Transaction > Manager inside Geronimo by itself without anything else from > Geronimo. Everything developed within the Geronimo PMC is modular; > you can use what you like. Modularity and reuse is a given on all the > Geronimo projects I'm aware of (which is most of it). > > Geronimo benefited greatly from one project to define the kernel, the > container, the transaction manager and the other components together > by one cohesive team - then running the TCKs on it all - than having > lots of little projects. I think the JBI community (container, > components, routers and orchestrators of componentes) can get the > same benefit of community growth. > > > > What > > about versioning? Is the idea that the BPEL bit within ServiceMix > > would be versioned/released separately? Or only when the thing > > of which it is a part is released? > > I prefer frequent releases of everything in a project as often as > possible personally but I'm sure if there's a need we could release > different modules at different times. Lets let the community decide. > > > > If the code is of use to more that ServiceMix, and/or there are > > people who'd like to work on it but aren't interested in working > > on any part of what ServiceMix is now, then it makes sense to > > me that it be a separate project. As proposed, anyone with an > > interest only in the BPEL aspect would have to join the ServiceMix > > community despite a lack of interest in it. > > > > This is all hypothetical; I don't know if there *are* people > > who'd want to work on it but not ServiceMix, and I have > > to take on faith the remarks that there are other packages > > that would like a BPEL engine without ServiceMix attached. > > Folks can work on the transaction manager in Geronimo and not worry > about the rest of it (and thats quite a bit 'rest' :); Similarly I > see no real harm with anyone joining ServiceMix (we're nice folks > really :). > > But if the community grows to a large enough size of only- > orchestration-engine-without-caring-about-JBI people, the Geronimo > PMC can always reconsider and consider splitting the projects up. But > that'd be a great problem to have; a large healthy community focussed > only on orchestration wishing to make its own way. Today we have only > folks interested in ServiceMix wanting to work on the code there - so > I'm hoping we can bootstrap the community there first - then who > knows, lets let the community (under the guidance of the Geronimo > PMC) decide. > > James > --- > http://radio.weblogs.com/0112098/ > > -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer-jar-refactor-1.0.1.patch This patch applies to 1.0.1 only. Disregard prior patch i.e. DO NOT USE installer-jar-refactor.patch. Thanks. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- 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-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Description: Change this issue to only apply to 1.0.1. Another issue will be created to address 1.1. was: Version: (was: 1.1) > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- 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] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Davanum Srinivas wrote: Why can't you treat an orchestration engine like a component like the way you treat Axis or XFire? Why does the code have to live within ServiceMix? Lot of us want a BPEL engine, we don't want a JBI container. The code coming in does exactly that, it is a BPEL engine and has no relation to JBI or Java for that matter. Why can't you have a separate project for BPEL and add glue code as a JBI component EXACTLY the way you work with other projects like XFire? : We seem to agree on the ends but not on the means. You like a very good integration with a BPEL engine for ServiceMix. I like a very good BPEL engine for its own sake. Am sure we can find people on both sides and some who may like both objectives. An interesting point. There is no reason people in the ServiceMix couldn't also work on a BPEL project. But if we goes through with this as proposed, and someone wants a BPEL engine, is it going to be necessary to take all of ServiceMix along with it? Not at all. To use an analogy from Geronimo. You can reuse the Transaction Manager inside Geronimo by itself without anything else from Geronimo. Everything developed within the Geronimo PMC is modular; you can use what you like. Modularity and reuse is a given on all the Geronimo projects I'm aware of (which is most of it). Geronimo benefited greatly from one project to define the kernel, the container, the transaction manager and the other components together by one cohesive team - then running the TCKs on it all - than having lots of little projects. I think the JBI community (container, components, routers and orchestrators of componentes) can get the same benefit of community growth. What about versioning? Is the idea that the BPEL bit within ServiceMix would be versioned/released separately? Or only when the thing of which it is a part is released? I prefer frequent releases of everything in a project as often as possible personally but I'm sure if there's a need we could release different modules at different times. Lets let the community decide. If the code is of use to more that ServiceMix, and/or there are people who'd like to work on it but aren't interested in working on any part of what ServiceMix is now, then it makes sense to me that it be a separate project. As proposed, anyone with an interest only in the BPEL aspect would have to join the ServiceMix community despite a lack of interest in it. This is all hypothetical; I don't know if there *are* people who'd want to work on it but not ServiceMix, and I have to take on faith the remarks that there are other packages that would like a BPEL engine without ServiceMix attached. Folks can work on the transaction manager in Geronimo and not worry about the rest of it (and thats quite a bit 'rest' :); Similarly I see no real harm with anyone joining ServiceMix (we're nice folks really :). But if the community grows to a large enough size of only- orchestration-engine-without-caring-about-JBI people, the Geronimo PMC can always reconsider and consider splitting the projects up. But that'd be a great problem to have; a large healthy community focussed only on orchestration wishing to make its own way. Today we have only folks interested in ServiceMix wanting to work on the code there - so I'm hoping we can bootstrap the community there first - then who knows, lets let the community (under the guidance of the Geronimo PMC) decide. James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: > > Incidentally its worth looking at other projects at Apache like Agila > and various projects on http://ws.apache.org like EWS, Mirae, Muse, > WSRF, TSIK etc which are kinda quiet, some near dormant. No, it is not worth looking at them, if the intent is to use them as precedents of a process some are finding objectionable. Saying, 'They did it so why can't we?' is not appropriate. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+Nx1ZrNPMCpn3XdAQIrfgP/S+k1/RDQqfCthNR5P2BLwctklAE7k/Df SIg3p0xuvYN9A+631mo4DSLFIORNkV1s5/pmG61k64uvTeJ3TGLEySQ1zVu6vDJQ TW5zwzE5XeOKVfjAjZbyWZJ+Hin81wr+/1DSD4ja609Q2ugxN21Qv7yHWvYwtD1p nRH1D+Mwemg= =rHW9 -END PGP SIGNATURE-
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Davanum Srinivas wrote: > Why can't you treat an orchestration engine like a component like the > way you treat Axis or XFire? Why does the code have to live within > ServiceMix? Lot of us want a BPEL engine, we don't want a JBI > container. The code coming in does exactly that, it is a BPEL engine > and has no relation to JBI or Java for that matter. Why can't you have > a separate project for BPEL and add glue code as a JBI component > EXACTLY the way you work with other projects like XFire? : > We seem to agree on the ends but not on the means. You like a very > good integration with a BPEL engine for ServiceMix. I like a very good > BPEL engine for its own sake. Am sure we can find people on both sides > and some who may like both objectives. An interesting point. There is no reason people in the ServiceMix couldn't also work on a BPEL project. But if we goes through with this as proposed, and someone wants a BPEL engine, is it going to be necessary to take all of ServiceMix along with it? What about versioning? Is the idea that the BPEL bit within ServiceMix would be versioned/released separately? Or only when the thing of which it is a part is released? If the code is of use to more that ServiceMix, and/or there are people who'd like to work on it but aren't interested in working on any part of what ServiceMix is now, then it makes sense to me that it be a separate project. As proposed, anyone with an interest only in the BPEL aspect would have to join the ServiceMix community despite a lack of interest in it. This is all hypothetical; I don't know if there *are* people who'd want to work on it but not ServiceMix, and I have to take on faith the remarks that there are other packages that would like a BPEL engine without ServiceMix attached. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+NxUJrNPMCpn3XdAQLsWgP/VWgCpIjhg5vD4oWxvUIbBkvi7kaPUQGU HbYXstl0P0ixjPkQ8OCM5IyT5uZBhwt2tIMN9g4cRDhmMbrZda5myzX/4um6SP4v xK2clPLSILmpCftilJcPS1YgLmCgq9U4Tp2LVJK5TtYejK6lLzIBqKtCnLTWmoN6 2Twfp/Ct5Uw= =3LV1 -END PGP SIGNATURE-
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Then by all means go ahead with a proposal to the Geronimo PMC asking to start a new incubation project for BPEL as you say that there is enough people to work on it. Not a backdoor "patch" to ServiceMix. BPEL can be used standalone and BPEL was not in scope of ServiceMix. A BPEL JBI Component is not a problem at all. But a full BPEL implementation is a problem. thanks, dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > I was speaking with my Geronimo PMC hat on thinking in general about > projects within the Geronimo PMC. > > James > > On 3 Feb 2006, at 14:26, Davanum Srinivas wrote: > > James, > > > > you can make those decisions when ServiceMix is a TLP of its own. > > Right now it's not. > > > > thanks, > > dims > > > > On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > >> On 3 Feb 2006, at 13:23, James Strachan wrote: > >>> On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: > So, bottom line, Please draw up a new proposal for a separate > project. > >>> > >>> So here's the thing; no-one involved (the folks donating the code > >>> and the committers on the ServiceMix project) want a new project. > >>> We all want to work in the single JBI project, ServiceMix where the > >>> JBI container and JBI components live and are developed, documented > >>> and tested together. We want a single, strong community around JBI. > >> > >> Incidentally its worth looking at other projects at Apache like Agila > >> and various projects on http://ws.apache.org like EWS, Mirae, Muse, > >> WSRF, TSIK etc which are kinda quiet, some near dormant. Making > >> projects too small and too granular can sometimes harm the chances of > >> creating a vibrant community. Just as the some folks in the WS PMC > >> are starting to consider collapsing projects together due to > >> inactivity, I think we should stay open to the idea of creating less > >> granular projects that can build a thriving community to start with > >> then, if the community decides, split things off later if something > >> becomes so popular it deserves its own project. > >> > >> James > >> --- > >> http://radio.weblogs.com/0112098/ > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Davanum Srinivas : http://wso2.com/blogs/ > > > James > --- > http://radio.weblogs.com/0112098/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
I was speaking with my Geronimo PMC hat on thinking in general about projects within the Geronimo PMC. James On 3 Feb 2006, at 14:26, Davanum Srinivas wrote: James, you can make those decisions when ServiceMix is a TLP of its own. Right now it's not. thanks, dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: On 3 Feb 2006, at 13:23, James Strachan wrote: On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: So, bottom line, Please draw up a new proposal for a separate project. So here's the thing; no-one involved (the folks donating the code and the committers on the ServiceMix project) want a new project. We all want to work in the single JBI project, ServiceMix where the JBI container and JBI components live and are developed, documented and tested together. We want a single, strong community around JBI. Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. Making projects too small and too granular can sometimes harm the chances of creating a vibrant community. Just as the some folks in the WS PMC are starting to consider collapsing projects together due to inactivity, I think we should stay open to the idea of creating less granular projects that can build a thriving community to start with then, if the community decides, split things off later if something becomes so popular it deserves its own project. James --- http://radio.weblogs.com/0112098/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
James, you can make those decisions when ServiceMix is a TLP of its own. Right now it's not. thanks, dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 13:23, James Strachan wrote: > > On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: > >> So, bottom line, Please draw up a new proposal for a separate > >> project. > > > > So here's the thing; no-one involved (the folks donating the code > > and the committers on the ServiceMix project) want a new project. > > We all want to work in the single JBI project, ServiceMix where the > > JBI container and JBI components live and are developed, documented > > and tested together. We want a single, strong community around JBI. > > Incidentally its worth looking at other projects at Apache like Agila > and various projects on http://ws.apache.org like EWS, Mirae, Muse, > WSRF, TSIK etc which are kinda quiet, some near dormant. Making > projects too small and too granular can sometimes harm the chances of > creating a vibrant community. Just as the some folks in the WS PMC > are starting to consider collapsing projects together due to > inactivity, I think we should stay open to the idea of creating less > granular projects that can build a thriving community to start with > then, if the community decides, split things off later if something > becomes so popular it deserves its own project. > > James > --- > http://radio.weblogs.com/0112098/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 13:23, James Strachan wrote: On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: So, bottom line, Please draw up a new proposal for a separate project. So here's the thing; no-one involved (the folks donating the code and the committers on the ServiceMix project) want a new project. We all want to work in the single JBI project, ServiceMix where the JBI container and JBI components live and are developed, documented and tested together. We want a single, strong community around JBI. Incidentally its worth looking at other projects at Apache like Agila and various projects on http://ws.apache.org like EWS, Mirae, Muse, WSRF, TSIK etc which are kinda quiet, some near dormant. Making projects too small and too granular can sometimes harm the chances of creating a vibrant community. Just as the some folks in the WS PMC are starting to consider collapsing projects together due to inactivity, I think we should stay open to the idea of creating less granular projects that can build a thriving community to start with then, if the community decides, split things off later if something becomes so popular it deserves its own project. James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-1577) Installer - User Interface changes
[ http://issues.apache.org/jira/browse/GERONIMO-1577?page=comments#action_12365077 ] Dave Colasurdo commented on GERONIMO-1577: -- The Izpack guy(s) are looking into item 1 (dependencies and indentation) and will get back to us on Monday. Their initial feedback looks promising. > Installer - User Interface changes > -- > > Key: GERONIMO-1577 > URL: http://issues.apache.org/jira/browse/GERONIMO-1577 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1, 1.1 > Reporter: Dave Colasurdo > > The Installer should consider changing the following: > 1) Represent the PacksPanel dependencies visually in a hierarchical tree > (I'm awaiting a rsp on ipack mailing list to see if this is possible) > 2) Suppress the dependencies box on the PacksPanel (I'm awaiting rsp on > iPack mailing list to see if this is possible) > 3) The Configuration Checkpoint page should include a list of all the > selected options and a summary of their combined sizes. Title on this page > ahould be updated to "Install Confirmation Panel" > 4) The Processing Panel - this panel shows up and executes afterit appears > that the install has already completed. Would be nice to have a better > description title on the page "Installing configurations and Applications" > and a better indication of success when the install completes. -- 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] accept donation of a business process engine into the ServiceMix project
James, "Why don't you join the Agila project then?" is not the right attitude. we are trying to be constructive. thanks, -- dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 13:45, Paul Fremantle wrote: > > James > > > > I'm sure you want a single strong community around JBI. But a BPEL > > is a > > specification that is completely independent of JBI and indeed of > > Java. > > You're talking about the BPEL XML language; I'm talking about a Java > based orchestration engine. > > > > If you make the argument that everything that can be potentially > > used as a > > JBI component is part of ServiceMix then you pretty much include > > every part > > of the JBI stack. > > I'm not arguing for everything that can *potentially* be used as a > JBI component, I'm saying everything that *should* be used as a JBI > component within a JBI container (in this case to orchestrate other > JBI components) should ideally be developed within the Apache JBI > community. > > > > A BPEL server is an excellent project for Apache. I for one am very > > excited > > about the possibility of engaging in that project . > > Why don't you join the Agila project then? > > > > I'm very keen for Sybase > > to donate this code. But you can make it integrate closely into > > ServiceMix > > without it being tightly coupled. > > Its not about coupling, its about what is the standards based > container and component model for a Java based orchestration engine. > Note that one of the whole points of JBI is that it defines a > component model so that any JBI component can run in any JBI > container such as ObjectWeb's Petals or Sun's OpenESB or any other > commercial JBI container. > > James > --- > http://radio.weblogs.com/0112098/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Why can't you treat an orchestration engine like a component like the way you treat Axis or XFire? Why does the code have to live within ServiceMix? Lot of us want a BPEL engine, we don't want a JBI container. The code coming in does exactly that, it is a BPEL engine and has no relation to JBI or Java for that matter. Why can't you have a separate project for BPEL and add glue code as a JBI component EXACTLY the way you work with other projects like XFire? Seriously James I've never seen anyone disagree (in any effective manner) with you on the list(s). Why is that? Is it because all decisions happen off-list and all that happens here is the love-fest as Sanjiva described? Community is not about borg-like ok-ing of proposals. We seem to agree on the ends but not on the means. You like a very good integration with a BPEL engine for ServiceMix. I like a very good BPEL engine for its own sake. Am sure we can find people on both sides and some who may like both objectives. Why can't we agree to make it work as a separate entity? If not at least tell us what your *shopping list* contains as to what other JBI components you are going to bring in by the time incubation is over? thanks, dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: > > James, > > > > There are 2 problems: > > - As a Geronimo PMC member i feel a BPEL implemenation is out-of-scope > > of what i voted for when i +1'ed incubation for ServiceMix. > > The proposal for ServiceMix clearly says... > http://wiki.apache.org/incubator/ServiceMixProposal > > its a JBI container and component suite. An orchestration engine is a > JBI component so I see this as perfectly within scope. In your vote > you never enumerated what JBI components the ServiceMix project could > and could not develop. Could you maybe give us a list now of what > components you did vote for? > > > > I don't > > like what's happening and the way you are doing it. > > Sorry about that, we're trying to fix it > > > > - Secondly, there just isnt enough information to make a decision one > > way or another. A proposal would clear up things like what the > > "supposed" community thinks about a road map for the future say "BPEL > > 2.0" > > > > So, bottom line, Please draw up a new proposal for a separate project. > > So here's the thing; no-one involved (the folks donating the code and > the committers on the ServiceMix project) want a new project. We all > want to work in the single JBI project, ServiceMix where the JBI > container and JBI components live and are developed, documented and > tested together. We want a single, strong community around JBI. > > James > --- > http://radio.weblogs.com/0112098/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 13:45, Paul Fremantle wrote: James I'm sure you want a single strong community around JBI. But a BPEL is a specification that is completely independent of JBI and indeed of Java. You're talking about the BPEL XML language; I'm talking about a Java based orchestration engine. If you make the argument that everything that can be potentially used as a JBI component is part of ServiceMix then you pretty much include every part of the JBI stack. I'm not arguing for everything that can *potentially* be used as a JBI component, I'm saying everything that *should* be used as a JBI component within a JBI container (in this case to orchestrate other JBI components) should ideally be developed within the Apache JBI community. A BPEL server is an excellent project for Apache. I for one am very excited about the possibility of engaging in that project . Why don't you join the Agila project then? I'm very keen for Sybase to donate this code. But you can make it integrate closely into ServiceMix without it being tightly coupled. Its not about coupling, its about what is the standards based container and component model for a Java based orchestration engine. Note that one of the whole points of JBI is that it defines a component model so that any JBI component can run in any JBI container such as ObjectWeb's Petals or Sun's OpenESB or any other commercial JBI container. James --- http://radio.weblogs.com/0112098/
[jira] Closed: (GERONIMO-1448) debug-tool does not work on Tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1448?page=all ] Kevan Miller closed GERONIMO-1448: -- Resolution: Fixed For some reason, Tomcat doesn't like /*. Setting to '/' fixes the problem. Trunk: Sendingapplications/jmxdebug/src/webapp/WEB-INF/web.xml Transmitting file data . Committed revision 374665. branches/1.0: Sending1.0/applications/jmxdebug/src/webapp/WEB-INF/web.xml Transmitting file data . Committed revision 374664. > debug-tool does not work on Tomcat > -- > > Key: GERONIMO-1448 > URL: http://issues.apache.org/jira/browse/GERONIMO-1448 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0 > Environment: Geronimo-1.0 > Reporter: Kevan Miller > Assignee: Kevan Miller > Fix For: 1.0.1, 1.1 > Attachments: Geronimo-1448.patch > > The debug console doesn't work when running Tomcat. The base page loads > successfully. However, when you click on a GBean, you get a 404: > HTTP Status 404 - /index.vm > type Status report > message /index.vm > description The requested resource (/index.vm) is not available. > Apache Tomcat/5.5.9 -- 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: Oracle XA RAR for G1.0?
I think David means that it has not been extensively tested and so there are no gurantees that you'll simply be able to drop it in. I'm currently working on a DB2 XA RAR and am still working out some kinks. It should work well, we're just not sure its been testd enough to know that it does. I looked on CodeHaus and it appears that Jeremy had not previous released a SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 classes12.jar. I've published it and it is called tranql/rars/tranql-connector-oracle-xa-1.0-SNAPSHOT.rar If someone can try this out then that would be excellent. I have only compiled it and not tested it so caveat emptor. lichtner wrote: On Fri, 3 Feb 2006, David Jencks wrote: It is likely to work if you build it. However I don't know that it has been used in the last year or more, so I won't make any promises. Matt might have tried it, I don't know. We have been a bit reluctant to publish it without more evidence that it works well. Why would it not work well? When I was in my last job I remember getting that rar to work with mysql xa, so it probably also works with Oracle xa.
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 13:02, Davanum Srinivas wrote: James, There are 2 problems: - As a Geronimo PMC member i feel a BPEL implemenation is out-of-scope of what i voted for when i +1'ed incubation for ServiceMix. The proposal for ServiceMix clearly says... http://wiki.apache.org/incubator/ServiceMixProposal its a JBI container and component suite. An orchestration engine is a JBI component so I see this as perfectly within scope. In your vote you never enumerated what JBI components the ServiceMix project could and could not develop. Could you maybe give us a list now of what components you did vote for? I don't like what's happening and the way you are doing it. Sorry about that, we're trying to fix it - Secondly, there just isnt enough information to make a decision one way or another. A proposal would clear up things like what the "supposed" community thinks about a road map for the future say "BPEL 2.0" So, bottom line, Please draw up a new proposal for a separate project. So here's the thing; no-one involved (the folks donating the code and the committers on the ServiceMix project) want a new project. We all want to work in the single JBI project, ServiceMix where the JBI container and JBI components live and are developed, documented and tested together. We want a single, strong community around JBI. James --- http://radio.weblogs.com/0112098/
Re: Why rewind? (Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
On 2 Feb 2006, at 20:51, Noel J. Bergman wrote: James Strachan wrote: Given it fits nicely with the existing ServiceMix incubation proposal I see no need for a new proposal for a donation of code to an existing incubating project. We don't start to incubate a chicken, and then import a barnyard under the same proposal, just because it fits well with a chicken. What I am hearing is that NOT that people don't want the new material, but that while it may fit with ServiceMix, it can also fit well with other projects, and they want to allow that separation. You may feel otherwise, although that is not clear to me from: I certainly do feel otherwise as do the folks donating the code and the other members of the ServiceMix project. Not really, its an orchestration engine for an ESB so as I've already said its very well suited to the ServiceMix project and first well within its scope. We have at least two (2) ESB projects here. Is this proposal really ServiceMix specific? An orchestration engine and JBI go together like a J2EE application server and a JTA provider (transaction manager). JBI (JSR 208) is the JCP standard container model for deploying integration services; so orchestration engines should expose themselves as a JBI component, be deployed within a JBI container and work with other JBI components (binding components or service engines to use JBI speak). ServiceMix is the only JBI project at Apache where it currently hosts a full JBI container and test suite together with a large collection of existing JBI components for various things (smart routing, audit, transformation, rules, scripting etc). So the aim is for the orchestration engine to become a JBI component deployable inside ServiceMix's JBI container that can then orchestrate other JBI components (such as the Axis or Tuscay JBI components - I'm sure in time we'll have a Synapse JBI component too). http://incubator.apache.org/servicemix/Components Note that I purposely avoided the ESB buzzword in that paragraph above as its a vague semi-meaningless term these days, like SOA and "component" :) James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
James, There are 2 problems: - As a Geronimo PMC member i feel a BPEL implemenation is out-of-scope of what i voted for when i +1'ed incubation for ServiceMix. I don't like what's happening and the way you are doing it. - Secondly, there just isnt enough information to make a decision one way or another. A proposal would clear up things like what the "supposed" community thinks about a road map for the future say "BPEL 2.0" So, bottom line, Please draw up a new proposal for a separate project. Yes, of course ServiceMix can embed it and use it just like it does XFire or Axis or XBean. No one is saying you can't distribute a BPEL enabled ServiceMix. It deserves good attention and TLC, which Agila is not getting, So a fresh start would enable more people to converge and work on. So please *STOP* the vote and work on a proposal and post it. thanks, dims On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > On 3 Feb 2006, at 11:33, Rodent of Unusual Size wrote: > > James Strachan wrote: > >> On 3 Feb 2006, at 09:18, Sanjiva Weerawarana wrote: > >> > >>> Absolutely -1: The first time I ever saw any of this topic was > >>> Wed, 1 Feb 2006 12:20:32 -0700 (Thu, 01:20 LKT) > >>> and now at > >>> Thu, 2 Feb 2006 16:22:28 + (22:22 LKT) > >>> you want to have a vote on it? You've GOT to be kidding. > >> > >> I called a vote to see what people thought about it, particularly the > >> project sponsor, the geronimo PMC. > > > > You don't vote to get opinions or discussion. The actual > > text being voted on was: > > > > "accept the donation into the ServiceMix incubator project" > > The contributors want to donate their code to the ServiceMix > community and all indications are that the ServiceMix community want > to accept the code and want to work with the contributors; so I > thought it was right to seek approval for this course of action from > the sponsor PMC. Bear in mind we are still in the incubator anyway so > there is plenty of time for folks to review the code, watch the > community in action, get involved and participate before attempts are > made to leave the incubator. > > > >>> The idea of incubation is that the project is still not > >>> a part of Apache and hasn't quite become a meritocracy etc.. > >> > >> I understand that, which is why we are asking for the sponsor, the > >> Geronimo PMC to vote. > > > > That's very convoluted to my mind, although it *is* currently > > early in the morning here. > > :) > > > A package gets accepted as a podling, > > and then later the sponsor, a group external to the podling, > > decides to add more to it? > > Well no-one has decided yet, that's why we're voting ;) - but the > point of the vote was to ask the sponsor PMC to allow the podling to > be able to accept a code donation as well as canvassing the > ServiceMix community to see if they'd like to accept it. (Maybe this > caused some confusion having just 1 vote?) > > > > Admittedly the podling itself isn't > > allowed to make the decision, but that's still an odd scenario. > > Regardless of whether it has happened before, it's clearly > > an exception rather than the rule, and therefore subject to > > scrutiny. > > OK. But I thought it was fine for issues to come up in votes, for > them to be debated & addressed and then later for action to be taken? > Its certainly been my impression of how things tend to work on all > the apache projects i've been on - apologies if I'm mistaken. > > > >>> The way this particular potential donation has been handled proves > >>> without a shadow of a doubt that this project (ServiceMix) is not > >>> running The Apache Way. > >> I don't see how the project is not following the Apache Way. I find > >> this comment particularly puzzling as you voted yourself in to be a > >> mentor of the ServiceMix project. > > > > And I find it particularly troubling that a mentor of the > > podling in question is so strongly opposed to this tack. > > My objection was more to that sentence - of labelling the ServiceMix > project as not following the Apache Way when the main issue in > Sanjiva's mail to me seems to be my handling of the vote. i.e. I'd > much rather people say "bad James, you're not acting in an Apache > Way" or "you really messed up that vote" than to make, what feels at > least, a little derogatory comment about the entire ServiceMix > community as a whole which has been working very hard to follow the > incubation process and the Apache Way. > > > > If Sanjiva, a mentor of ServiceMix and therefore supposedly > > closer to it than most.. if *he* thinks there's something > > awkward about the way this is being handled, then I think > > attention should be paid to him. > > Absolutely; we're all paying attention to everyone's comment on this > issue. > > James > --- > http://radio.weblogs.com/0112098/ > > -- Davanum Srinivas : http://wso2.com/blogs/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 11:33, Rodent of Unusual Size wrote: James Strachan wrote: On 3 Feb 2006, at 09:18, Sanjiva Weerawarana wrote: Absolutely -1: The first time I ever saw any of this topic was Wed, 1 Feb 2006 12:20:32 -0700 (Thu, 01:20 LKT) and now at Thu, 2 Feb 2006 16:22:28 + (22:22 LKT) you want to have a vote on it? You've GOT to be kidding. I called a vote to see what people thought about it, particularly the project sponsor, the geronimo PMC. You don't vote to get opinions or discussion. The actual text being voted on was: "accept the donation into the ServiceMix incubator project" The contributors want to donate their code to the ServiceMix community and all indications are that the ServiceMix community want to accept the code and want to work with the contributors; so I thought it was right to seek approval for this course of action from the sponsor PMC. Bear in mind we are still in the incubator anyway so there is plenty of time for folks to review the code, watch the community in action, get involved and participate before attempts are made to leave the incubator. The idea of incubation is that the project is still not a part of Apache and hasn't quite become a meritocracy etc.. I understand that, which is why we are asking for the sponsor, the Geronimo PMC to vote. That's very convoluted to my mind, although it *is* currently early in the morning here. :) A package gets accepted as a podling, and then later the sponsor, a group external to the podling, decides to add more to it? Well no-one has decided yet, that's why we're voting ;) - but the point of the vote was to ask the sponsor PMC to allow the podling to be able to accept a code donation as well as canvassing the ServiceMix community to see if they'd like to accept it. (Maybe this caused some confusion having just 1 vote?) Admittedly the podling itself isn't allowed to make the decision, but that's still an odd scenario. Regardless of whether it has happened before, it's clearly an exception rather than the rule, and therefore subject to scrutiny. OK. But I thought it was fine for issues to come up in votes, for them to be debated & addressed and then later for action to be taken? Its certainly been my impression of how things tend to work on all the apache projects i've been on - apologies if I'm mistaken. The way this particular potential donation has been handled proves without a shadow of a doubt that this project (ServiceMix) is not running The Apache Way. I don't see how the project is not following the Apache Way. I find this comment particularly puzzling as you voted yourself in to be a mentor of the ServiceMix project. And I find it particularly troubling that a mentor of the podling in question is so strongly opposed to this tack. My objection was more to that sentence - of labelling the ServiceMix project as not following the Apache Way when the main issue in Sanjiva's mail to me seems to be my handling of the vote. i.e. I'd much rather people say "bad James, you're not acting in an Apache Way" or "you really messed up that vote" than to make, what feels at least, a little derogatory comment about the entire ServiceMix community as a whole which has been working very hard to follow the incubation process and the Apache Way. If Sanjiva, a mentor of ServiceMix and therefore supposedly closer to it than most.. if *he* thinks there's something awkward about the way this is being handled, then I think attention should be paid to him. Absolutely; we're all paying attention to everyone's comment on this issue. James --- http://radio.weblogs.com/0112098/
[jira] Closed: week of 02-03-2006
Project: Apache Geronimo Status: Resolved, Closed (24 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1573] Spring integration -- wrap our components in spring interfaces ** Bug * [GERONIMO-1578] Including wadi and its dependencies in the jetty configuration/classpath breaks numerous bits of geronimo * [GERONIMO-1287] IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms * [GERONIMO-1441] "Build path contains duplicate entry" errors for some geronimo projects in eclipse * [GERONIMO-1456] geronimo-1.0-src.zip has a meta-inf folder in the root directory * [GERONIMO-1489] Minor fixes/updates to jUDDI webapp and Tomcat config * [GERONIMO-1336] Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails * [GERONIMO-1570] jetty is setting hosts instead of virtual hosts * [GERONIMO-1569] improve packaging plugin control of logging. * [GERONIMO-1562] itests broken when Geronimo moved to 1.0 * [GERONIMO-1561] Misspelling in Kernel Exception Message * [GERONIMO-1545] CMP update statements will cause incorrect trigger firing in a database * [GERONIMO-1541] Unable to deploy applications in new Minimal and WEB-JMS assemblies * [GERONIMO-1419] javax.mail.internet.InternetHeaders has some non implemented features * [GERONIMO-1550] Current IDL files break the OpenEJB build * [GERONIMO-1528] javax.mail.BodyPart does not implement setParent() method * [GERONIMO-1530] javax.mail.Service does not properly implement the protocol between javamail infrastructure and transport handlers. * [GERONIMO-1540] Fix security vulnerability in jsp-examples ** Improvement * [GERONIMO-1571] Just a suggestion to state in the source distributin's BUILDING.txt file that compilation requires a JDK compatible with version 1.4, and that 1.5 will not work. * [GERONIMO-1554] Installer - Move advanced features to non-default installer path (simplify default installation) * [GERONIMO-1527] InternetAddress does not properly implement address parsing. ** Task * [GERONIMO-1544] Installer - Straighten out licensing issues for IzPack sub-components. * [GERONIMO-1549] Geronimo Specs 1.1-SNAPSHOT
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Hi James, > We're not sucking in another project. Its a contribution of code > only. How is this any different than has already happened on > Geronimo, Agila (twister), Harmony etc? Geronimo is not an incubating project and hence can bring more stuff in. The Agila/Twister merger was done thru the incubator (and is still ongoing and IMO unlikely to complete). Harmony- I'm not sure what you're referring to (I haven't followed it much). > Huh? We've held a vote in open so folks can express their opinions. i > don't see how the project is not following the Apache Way. I find > this comment particularly puzzling as you voted yourself in to be a > mentor of the ServiceMix project. Indeed :) .. and IMO an incubating project should not be taking code donations or doing I have asked for guidance from the incubator PMC to make sure I'm not out of line .. if so I will profoundly apologize! Sanjiva.
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: > On 3 Feb 2006, at 09:18, Sanjiva Weerawarana wrote: > >>Absolutely -1: The first time I ever saw any of this topic was >>Wed, 1 Feb 2006 12:20:32 -0700 (Thu, 01:20 LKT) >>and now at >>Thu, 2 Feb 2006 16:22:28 + (22:22 LKT) >>you want to have a vote on it? You've GOT to be kidding. > > I called a vote to see what people thought about it, particularly the > project sponsor, the geronimo PMC. You don't vote to get opinions or discussion. The actual text being voted on was: "accept the donation into the ServiceMix incubator project" >>The idea of incubation is that the project is still not >>a part of Apache and hasn't quite become a meritocracy etc.. > > I understand that, which is why we are asking for the sponsor, the > Geronimo PMC to vote. That's very convoluted to my mind, although it *is* currently early in the morning here. A package gets accepted as a podling, and then later the sponsor, a group external to the podling, decides to add more to it? Admittedly the podling itself isn't allowed to make the decision, but that's still an odd scenario. Regardless of whether it has happened before, it's clearly an exception rather than the rule, and therefore subject to scrutiny. >>The way this particular potential donation has been handled proves >>without a shadow of a doubt that this project (ServiceMix) is not >>running The Apache Way. > > Huh? We've held a vote in open so folks can express their opinions. Again -- you don't use a vote to discuss or collect opinions. Votes are primarily for decision-making, and this one certainly was phrased that way. > I don't see how the project is not following the Apache Way. I find > this comment particularly puzzling as you voted yourself in to be a > mentor of the ServiceMix project. And I find it particularly troubling that a mentor of the podling in question is so strongly opposed to this tack. If Sanjiva, a mentor of ServiceMix and therefore supposedly closer to it than most.. if *he* thinks there's something awkward about the way this is being handled, then I think attention should be paid to him. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+M/nJrNPMCpn3XdAQJ65AP+Nabfv2dmZPDEzWsycpaT+z8RTYSNDwx/ VEmeyRhicADWxjcJShwNKbsuRGq17tmfRoU2KETMUC2iWUyvgyuGiux5bkd6L6LT RjGGCAzCLyIpDfa3EakOoTj3kS63ZGcrVq4zy8lpxL/oQmXWaSj9PInmai+SyI2E WukqhVEqajY= =KDor -END PGP SIGNATURE-
login-service refactoring: authentication by assertion: saml and csi-v2
Here is an outline of the login-service and authentication by assertion;
There are at least 2 use cases for authentication by assertion: SAML and
CSI-V2;
SAML defines browser profile for inter-domain transfer: user agent is
transferred from the source site in one domain to the destination site in
another domain. To make long story short, destination site receives an
assertion from the source site that vouches for the caller identity;
There are 2 ways a user can log in: directly into the web-app, or by
inter-domain transfer; There are 2 issues to consider for authentication by
assertion: how to parse an assertion, and how to verify that we trust it; In
keeping with the notion that security realm is application authentication
policy, here is how security-realm is put together:
security-realm name="hello" {
trust-rules => either embedded or a reference to the trust-managing
gbean;
direct-login-module sufficient
saml-art-login-module trust-ref sufficient
}
For the user that is logging in directly, direct-login-module will succeed;
for inter-domain transfer saml-art-login-module will succeed; trust rules
are either defined within security realm or by the trust-manager gbean;
Trust manager will decide if we trust assertion issuer;
CSI-V2:
I'd like csi-v2 implementation to interact with the Geronimo login service
and delegate login and trust evaluation to it;
Here is csi-v2 security-realm configuration:
Csi-v2-security-realm name = "csi-v2" {
Trust-rules => either embedded or a reference to the trust-manager
gbean;
Auth-token-login-module-ref required => reference to a login module
that will authenticate a user specified by the auth-token; if no auth-token
present lm.login() will return false, meaning 'ignore this login module'
Csi-v2-login-module trust-ref required
}
First login module will try authenticating auth token if present; second
login module will examine csi-v2 assertions, evaluate trust rules, and
populate subject with delegated principals; Authenticated subject from the
auth-token-login-module is passed in the login-module shared-state;
csi-v2 callback handler has methods to set transport identity (sensitive
call, allowed for trusted code only), authentication-token, identity-token,
proxy trust rules, etc;
Then csi-v2 interceptor (trusted code) will call: csi-v2-callback-handler
cbh = new csi-v2-callback-handler(); cbh.setTransportIdentity(...) etc;
Then:
SubjectId subjid = login-service.login("csi-v2-security-realm-name", cbh);
Subject subj = login-service.getSubject(subjid); etc...;
More detail on delegated principals and trust rules later.
Comments?
Simon
