date:20060316

I have not changed the forkmode value or anything. So far I have
always tried to run it just as I have downloaded it, just like the way
you guys are doing. If it works just the way it is for all of you,
then I figured that something else must be the problem with my
settings. (Maybe it doesn't like me).

Let me try commenting out the forkmode.

Cheers
Prasad

On 3/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
The patches that I submitted on March 13th were
 for creating network.log. Are you using forkmode? Have
 you tried commenting it out?
The network.log file is created only when the
 surefire-reports directory already exists! I have to
 figure out why? I do get LoginException and a lot of
 output is produced on the console. But the build ends
 successfully with no exception in the reports! It is
 quite strange.
These are the 2 LoginException I get :
 DEBUG [main] Added Application Configuration Entry
 kerberos-foobar
 Debug is  true storeKey false useTicketCache true
 useKeyTab false doNotPrompt tr
 ue ticketCache is null KeyTab is null
 refreshKrb5Config is false principal is nu
 ll tryFirstPass is false useFirstPass is false
 storePass is false clearPass is f
 alse
 Error calling function Protocol status: 1312
 A specified logon session does not exist. It may
 already have been terminated.
 Principal is null
 null credentials from Ticket Cache
[Krb5LoginModule] authentication
 failed
 Unable to obtain Princpal Name for authentication
 javax.security.auth.login.LoginException: Unable to
 obtain Princpal Name for aut
 hentication
at
 com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginM
 odule.java:622)
at
 com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Kr
 b5LoginModule.java:544)
at
 com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.ja
 va:475)
at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
 






 DEBUG [main] GBeanInstanceState for:
 geronimo.security:type=SecurityRealm,realm=
 TOOLAZYDOGS.COM State changed from stopped to starting
 DEBUG [main] GBeanInstanceState for:
 geronimo.security:type=SecurityRealm,realm=
 TOOLAZYDOGS.COM State changed from starting to running
 javax.security.auth.login.LoginException:
 java.lang.NullPointerException: target
  is null
at
 org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicP
 roxyManager.java:104)
at
 org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.connect
 (JaasLoginCoordinator.java:173)
at
 org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.initial
 ize(JaasLoginCoordinator.java:85)
at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
 java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
 sorImpl.java:25)
at
 java.lang.reflect.Method.invoke(Method.java:324)
at
 javax.security.auth.login.LoginContext.invoke(LoginContext.java:662)
at
 javax.security.auth.login.LoginContext.access$000(LoginContext.java:1
 29)
at
 javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at
 java.security.AccessController.doPrivileged(Native
 Method)
at
 javax.security.auth.login.LoginContext.invokeModule(LoginContext.java
 :607)
at
 javax.security.auth.login.LoginContext.login(LoginContext.java:534)
 --- Prasad Kashyap [EMAIL PROTECTED]
 wrote:

   All this applies to building from the security
 dir. I have to look into the strange path being
 generated for the user.properties file.

 Thanks
 Anita

  I seem to be the only one whose m2 security module
  is failing it's
  tests. I have tried this after a  fresh svn checkout
  and a clean local
  repository. The tests fail even when I run it from
  inside the module.
 
  All the test failures seem to have a common
  exception and root cause.
  I have attached just 1  surefire-report but the rest
  are similar.
 
  Can someone help me figure this out please ?
 
  Cheers
  Prasad
  
 ---
  Battery:
 
 org.apache.geronimo.security.jaas.ConfigurationEntryTest
 
 ---
  Tests run: 1, Failures: 0, Errors: 1, Time elapsed:
  1.141 sec
 
 
 test(org.apache.geronimo.security.jaas.ConfigurationEntryTest)
   Time elapsed: 1.111 sec   ERROR!
 
  [ stdout ]
 
 ---
 
  DEBUG [main] Starting boot
  DEBUG [main] GBeanInstanceState for: :role=Kernel
  State changed from stopped to starting
  DEBUG [main] GBeanInstanceState for: :role=Kernel
  State changed from starting to running
  DEBUG [main] Booted
  DEBUG [main] GBeanInstanceState for:
  geronimo.system:role=ServerInfo State changed

[jira] Created: (SM-351) servicemix-http should expose the endpoints' WSDL on a GET request

2006-03-16 Thread Guillaume Nodet (JIRA)

servicemix-http should expose the endpoints' WSDL on a GET request
--

 Key: SM-351
 URL: http://jira.activemq.org/jira//browse/SM-351
 Project: ServiceMix
Type: New Feature

  Components: servicemix-http  
Reporter: Guillaume Nodet
 Assigned to: Guillaume Nodet 
 Fix For: 3.0-M1




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

Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

2006-03-16 Thread Jules Gosnell


Filip Hanik - Dev Lists wrote:


gentlemen, not a committer here, but wanted to share some thoughts.

in my opinion, the Session API should not have to know about 
clustering or session replication, nor should it need to worry about 
location.

the clustering API should take care of all of that.


We are 100% in agreement here, Filip.

the solution that we plan to implement for Tomcat is fairly straight 
forward. Let me see if I can give an idea of how the API shouldn't 
need to worry, its a little lengthy, but it shows that the Session and 
the SessionManager need to know zero about clustering or session 
locations. (this is only one solution, and other solutions should 
demonstrate the same point, SessionAPI need to know nothing about 
clustering or session locations)


1. Requirements to be implemented by the Session.java API
  bool isDirty - (has the session changed in this request)
  bool isDiffable - is the session able provide a diff
  byte[] getSessionData() - returns the whole session
  byte[] getSessionDiff() - optional, see isDiffable, resets the diff 
data
  void setSessionDiff(byte[] diff) - optional, see isDiffable, apply 
changes from another node


So, delta-ed sessions, at whole session or attribute granularity ? and 
when will you be sending the deltas - immediately, end of 
request[-group], pluggable strategies ?



2. Requirements to be implemented by the SessionManager.java API
  void setSessionMap(HashMap map) - makes the map implementation 
pluggable


3. And the key to this, is that we will have an implementation of a 
LazyReplicatedHashMap

  The key object in this map is the session Id.
  The map entry object is an object that looks like this
  ReplicatedEntry {
 string id;//sessionid
 bool isPrimary; //does this node hold the data
 bool isBackup; //does this node hold backup data
 Session session; //not null values for primary and backup nodes
 Member primary; //information about the primary node
 Member backup; //information about the backup node
  }

  The LazyReplicatedHashMap overrides get(key) and put(id,session)


interesting...

So all the nodes will have the a sessionId,ReplicatedEntry 
combinations in their session map. But only two 


two is a fixed number or deploy-time parameter ?


nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB 
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new 
one, and do a publish to the entire cluster of the locations.


As you can see, all-to-all communications only happens when a Session 
is (created|destroyed|failover). Other than that it is 
primary-to-backup communication only, and this can be in terms of 
diffs or entire sessions using the isDirty or getDiff. This is 
triggered either by an interceptor at the end of each request or by a 
batch process for less network jitter but less accuracy (but adequate) 
for fail over.


I see - that answers my question about when replication occurs :-)



As you can see, access time is not relevant here, nor does the Session 
API even know about clustering.


yes !



In tomcat we have separated out group communication into a separate 
module, we are implementing the LazyReplicatedHashMap right now just 
for this purpose.


positive thoughts, criticism and bashing are all welcome :)


This approach has much more in common with WADI's - in fact there is lot 
of synergy here. I think the WADI and TC clustering teams could learn a 
lot from each other. I would be very interested in sitting down with you 
Filip and having a long chat about session management. Do you have a 
Tomcat clustering-specific list that I could jump onto ? You might be 
interested in popping in on [EMAIL PROTECTED]  and learning a little 
more about WADI ?


regards,

Jules



Filip


 




--
Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it.

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training  Support.
**/

[jira] Resolved: (AMQ-630) After broker has shutdown, cannot shutdown a client application

 [ http://jira.activemq.org/jira//browse/AMQ-630?page=all ]
 
james strachan resolved AMQ-630:


 Resolution: Fixed
Fix Version: 4.0 M5

We used to have an infinite blocking request-response when closing clients, 
letting the broker konw that the client was shutting down. The code was patched 
a few days ago to use a timeout instead - so if the broker is down, the client 
will only wait until the timeout occurs before shutting down

 After broker has shutdown, cannot shutdown a client application
 ---

  Key: AMQ-630
  URL: http://jira.activemq.org/jira//browse/AMQ-630
  Project: ActiveMQ
 Type: Bug

 Versions: 4.0 M4
 Reporter: Kieran Murphy
  Fix For: 4.0 M5



 1.  Bring up a broker
 2.  Bring up a client application which connects to the broker
 3.  Stop the broker.
 4.  Now try to stop the client app -- it will not shutdown until the broker 
 is restarted.  
 Using failover:tcp to connect to broker.

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

[jira] Reopened: (AMQ-631) verify that HttpsTransportBrokerTest won't hang on other environment

2006-03-16 Thread Fritz Oconer (JIRA)

 [ http://jira.activemq.org/jira//browse/AMQ-631?page=all ]
 
Fritz Oconer reopened AMQ-631:
--


Still hangs on continuum boxes with 1.5 jdk. (iago, aladdin, jafar)

 verify that HttpsTransportBrokerTest won't hang on other environment
 

  Key: AMQ-631
  URL: http://jira.activemq.org/jira//browse/AMQ-631
  Project: ActiveMQ
 Type: Task

   Components: Test Cases
 Versions: 4.0 M5
 Reporter: Adrian Co
 Assignee: Adrian Co
  Fix For: 4.0 M5





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

[jira] Created: (AMQ-636) multicast discovery of network connectors can create 2 brokers in 1 JVM if the user changes the brokerName

multicast discovery of network connectors can create 2 brokers in 1 JVM if the 
user changes the brokerName
--

 Key: AMQ-636
 URL: http://jira.activemq.org/jira//browse/AMQ-636
 Project: ActiveMQ
Type: Improvement

Reporter: james strachan
 Fix For: 4.0 M5


Someone reported on IRC yesterday. The issue was the multicast discovery 
sending out a request, which happened to contain a broker name different to the 
one configured via XML.

To fix this we could consider enabling loopBackMode by default for multicast 
transport and multicast discovery

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

Re: OpenWire tight/loose encoding

2006-03-16 Thread Hiram Chirino

Hi Mats!

On 3/16/06, Mats Forslöf [EMAIL PROTECTED] wrote:
 Hi,

 We need some additional information on the OpenWire protocol to wrap up our 
 work on the C++ AMQ client.

 1. To use loose encoding what do we have to do, is it simply to set the tight 
 encoding attribute to false on the OpenWireFormat package and then send each 
 package attributes one after each other?


OpenWire should always start up in loose encoding mode, in version 1
of the protocol, with all options off by default.  This ensures
backward compatibitlity since future clients will beforced to be
backward compatible to even start talking.  The clients then exchange
a WireFormatInfo which contains information about the highest version
of the protocol and requested protocol options that should be turned
on.  After that exchange both sides can upgrade the version and
options to a set that is compatible between the 2 ends.

 2. What determines the order of the attributes on each package? The order now 
 seems to be determined by the groovy scripts.

They are in the order that they were defined in the orifinal Java
command classes.  The groovy script just preserves the order.


 3. What about the order of the boolean flags used in tight encoding, what 
 does each position stand for?


The bits in the BooleanStream are also serialized in the same order.

 I must ask you of some documentation on this because we cannot verify that 
 our code is correct otherwise.


Any time!  I guess we need to update the C++ guy to support loose
encoding since that is now the minimum requirement.  At least it's
much simpler to implement.  Should I work on that or have you guys
allready have that covered?

Regards,
Hiram

 Please help!

 Regards,
 Mats Forslöf



--
Regards,
Hiram

Re: daytrader benchmark results

2006-03-16 Thread Maxim Berkultsev

Matt,
thank you for clarification.
I've checked JMeter and as for meitlooksvalidtoget someperformance estimations.By the way, if thereis any standard configuration to test(I mean parameters for JMeter workload sessionlikenumber of threads, loop count, etc.), please let me know.

-- Best regards, Maxim Berkultsev, Intel Middleware Products Division
2006/3/16, Matt Hogstrom [EMAIL PROTECTED]: Maxim Berkultsev wrote: Hi Matt, thanks a lot for the reply. A few more questions...
The Y-Axis represents transactions per second.What is this value - is it a general magnitude like time or is it related to the type of request which is under study, (
i.e. number of JDBCRead transactions per second)? All the TPS metrics were gathered from the client.The goal was to get the server to 100% CPU utilization.
Before your reply I suppose that Web Server Manager portlet was used to perform monitoring, please see the post
http://www.mail-archive.com/dev@geronimo.apache.org/msg18979.html
No, the results are based on external requests per second by the client.Not by the servlet mentioned in the article. So the question is - do you use any additional client application (not
included in Daytrader), which provides workload for Geronimo? I use a load driver call WebSphere Studio Simulator.This is a toolthat I have had setup on my test environment for some time.At some point I'd like to
move to JMeter or some other load driver but I found the Java based load generators take too much compute resource so right now I'm using a C based one. Thank you. --
Best regards, Maxim Berkultsev, Intel Middleware Products Division Matt Hogstrom wrote: Hi Maxim, Comments inline...
Maxim Berkultsev wrote: Hello all, I've looked through Daytrader workload results and analysis for Geronimo
published at http://www-1.ibm.com/support/docview.wss?uid=swg27006724
For the bar diagrams, which show Geronimo and 'target' server indicators, immediate questions are: - what is the measure unit for values in Y-axis?
The Y-Axis represents transactions per second. - how are the values for 'target' performance received? One problem with performance measurments is that they typically incite many
people to claim victory or cry foul depending on the results.This is also complicated by the fact that many commercial products have a no benchmark
publish clause in their licenses.In order to have something to compare Geronimo to as well as avoid the inevitable fallout of naming a comparison point I did a series of measurments on other Open Source and commercial
AppServer products.I thook these results and created the competitive target metric. The competitive target metric is simply my estimation of a respectable
performance measurement.Meaning, as we achieve that metric one should be happy with the results. Note that these numbers are pretty old.I have a new set of data that I've
been saying will be out for a while.I guess its time to actually make that happen. So, for purposes of consumption I would wait a few days for the new report
to surface.We'll post it on our site. Also, could someone clarify if the performance data was collected on a client or a server side?
All the TPS metrics were gathered from the client.The goal was to get the server to 100% CPU utilization. Also, if you guys are willing we could use some of the newer Potomac
3.6Ghzchips:)

[jira] Created: (AMQ-635) ruby stomp client test failures against 4.x

ruby stomp client test failures against 4.x
---

 Key: AMQ-635
 URL: http://jira.activemq.org/jira//browse/AMQ-635
 Project: ActiveMQ
Type: Bug

Versions: 4.0 M4
Reporter: james strachan
 Assigned to: james strachan 
 Fix For: 4.0 M5


The test suite for Ruby Stomp is not currently working against SVN HEAD of 
ActiveMQ 4.x

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

Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows

2006-03-16 Thread Jacek Laskowski

2006/3/16, anita kulshreshtha [EMAIL PROTECTED]:
 Jacek,
   We need to change to surefire-plugin version
 2.2-SNAPSHOT.

Good shot! You're doing a great job with the migration. Thanks!

Will give it a try and commit the changes soon. I'm working with the
m2 sources so I need to be very careful to not introduce something
that's not supposed to work in a previous yet stable release of Maven
itself and its plugins.

 Anita

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Closed: (GERONIMO-1497) DatabasePoolPortlet Unable to save connection pool

2006-03-16 Thread Aaron Mulder (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1497?page=all ]
 
Aaron Mulder closed GERONIMO-1497:
--

Resolution: Duplicate

 DatabasePoolPortlet Unable to save connection pool
 --

  Key: GERONIMO-1497
  URL: http://issues.apache.org/jira/browse/GERONIMO-1497
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0
 Reporter: Gao Yong Pan
 Assignee: Donald Woods
  Fix For: 1.2


 New a database pool using the wizard from admin console and save settings. 
 The save will success on installation which
 path doesn't contain a space, if a space is in its install path, like 
 c:\program file\geronimo1.0\, then it will fail
 with following execption when you try to save or view the plan.
 15:04:03,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
 java.lang.NullPointerException
  at sun.misc.URLClassPath$3.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.misc.URLClassPath.getLoader(Unknown Source)
  at sun.misc.URLClassPath.getLoader(Unknown Source)
  at sun.misc.URLClassPath.findResource(Unknown Source)
  at java.net.URLClassLoader$2.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findResource(Unknown Source)
  at java.lang.ClassLoader.getResource(Unknown Source)
  at 
 org.apache.geronimo.deployment.tools.loader.AbstractDeployable.init(AbstractDeployable.java:57)
  at 
 org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.init(ConnectorDeployable.java:37)
  at 
 org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813)
  at 
 org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339)
  at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
  at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
  at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
  at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at 
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
  at 
 org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
  at 
 org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
  at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
  at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
  at 
 org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
  at 
 org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:8
 2)
  at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
  at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
  at 
 org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272)
  at 
 org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
  at 
 org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50)
  at 
 org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53)
  at 
 org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47)
  at 
 org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60)
  at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
  at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
  at

[jira] Commented: (GERONIMO-1506) DB info portlet should use new GeronimoVersion

2006-03-16 Thread Aaron Mulder (JIRA)

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

Aaron Mulder commented on GERONIMO-1506:


It looks like the new alternative is to omit the version number -- we should 
revist this issue when the configId change is complete.

 DB info portlet should use new GeronimoVersion
 --

  Key: GERONIMO-1506
  URL: http://issues.apache.org/jira/browse/GERONIMO-1506
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.1
 Reporter: Paul McMahan
 Assignee: Aaron Mulder
  Fix For: 1.1, 1.2
  Attachments: GERONIMO-1506.patch

 The DB info portlet currently refers to the system database using a hard 
 coded version number.  It should use the new GeronimoVersion.GERONIMO_VERSION 
 for the version number instead.  Without this fix the DB info portlet shows 
 no data.

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

[jira] Closed: (GERONIMO-1720) Update instructions for Create Database Pool -- Show Deployment Plan

2006-03-16 Thread Aaron Mulder (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1720?page=all ]
 
Aaron Mulder closed GERONIMO-1720:
--

Fix Version: 1.1
 Resolution: Invalid

Closed at the submitter's request

 Update instructions for Create Database Pool -- Show Deployment Plan
 --

  Key: GERONIMO-1720
  URL: http://issues.apache.org/jira/browse/GERONIMO-1720
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0
 Reporter: Song
  Fix For: 1.1


 Following instructions has an error: tranql-connector-1.1.rar is located 
 under geronimo_home/repository/tranql/rars, not geronimo_home/
 
 Deploy Command:
   To deploy a database pool from the command line using this plan, copy 
 and paste it to a file (say, plan-file.xml) and save it. Then run a command 
 like:
 cd GERONIMO_HOME
 java -jar bin/deployer.jar deploy plan-file.xml \
 tranql-connector-1.1.rar
 Add to EAR:
   Instead of deploying as a top-level database pool, you can deploy this 
 pool as part of an EAR. To add a database pool to an EAR using this plan:
1. Copy and paste the plan to a file
2. Save the plan file to the top level of your EAR
3. Copy the RAR file from GERONIMO_HOME/tranql-connector-1.1.rar to the 
 top level of your EAR
4. Create a META-INF/geronimo-application.xml file in your EAR that has a 
 module entry like this (substituting the correct RAR file name and plan file 
 name):
 application
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-1.0;
configId=MyApplication
   module
 connectorrar-file-name.rar/connector
 alt-ddplan-file-name.xml/alt-dd
   /module
 /application

-- 
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: ActiveMQ Graduation From Incubator

2006-03-16 Thread Dain Sundstrom



On Mar 15, 2006, at 3:32 PM, Noel J. Bergman wrote:


Dain Sundstrom wrote:


Our goal when starting the incubation process of ActiveMQ, OpenEJB,
ServiceMix, WADI, and XBean, was to consolidate the Geronimo
community.


Consolidating the community is a good thing.  I've long wanted to  
see a

number of those projects at the ASF.

The vision was to have a single community focused on building a  
modular

server architecture based on a single core.


No disagreement.  The question at hand is simple and specific.  Are  
you
going to actually make one community from the bunch, with everyone  
having

access to work on every piece of code?  Are you going to have a large,
single, PMC with everyone having binding decisions over every  
aspect of the

project?

THAT is a TLP.


Yes, that is exactly what we are talking about.


each of the sub projects would be deliverable as a standalone
(basically the core with one plugin installed).


Separate from destination, but that sounded fine right up to the  
last point.
What is the core?  If I just want ActiveMQ, or I just want OpenEJB,  
or I
just want ... can I get it, or do I have to take some code Geronimo  
stuff,
too?  From what Alan Cabrera said last night, it sounded as if  
there have
been some complaints about that, specifically in his example with  
OpenEJB.

Or in my case, if we want to use ActiveMQ for JMS in James, what other
non-ActiveMQ bits would we required to deal with in order to get  
the code

that was apparently separable earlier?


The problem is not sharing a single core, it is that the core we  
have, GBean, is too intrusive.  XBean was designed to not be intrusive.



end up with just a bunch of separate TLPs because of some
unknown apache rules.


I'm expressing a personal opinion that the projects would be better  
off as
TLPs that collaborate with Geronimo.  From what I am being told,  
that is not
an uncommon view within those communities, although there are  
questions as
to whether to go TLP directly or via Geronimo.  Perhaps that ought  
to be put
forward for the individuals who make up the communities to directly  
answer?

:)


I think you are starting to see the responses. :)

-dain

RE: OpenWire tight/loose encoding

2006-03-16 Thread Mats Forslöf

Hi Hiram

Thanks for the update. We have already selected the loose encoding as the 
default encoding in the C++ client, it's good to see that we have selected the 
same. The tight encoding is deferred to a future release since it is a bit more 
complicated and we wanted something up and running. We're just finished a 
architectural re-design in the C++ client that makes a lot less code to 
maintain and a bit easy to add other protocols (see previous posts regarding 
C++ refactoring suggestion).

Will get back soon with a new patch udpate including updated groovy scripts.

Regards,
Mats


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino
Sent: den 16 mars 2006 13:46
To: activemq-dev@geronimo.apache.org
Subject: Re: OpenWire tight/loose encoding

Hi Mats!

On 3/16/06, Mats Forslöf [EMAIL PROTECTED] wrote:
 Hi,

 We need some additional information on the OpenWire protocol to wrap up our 
 work on the C++ AMQ client.

 1. To use loose encoding what do we have to do, is it simply to set the tight 
 encoding attribute to false on the OpenWireFormat package and then send each 
 package attributes one after each other?


OpenWire should always start up in loose encoding mode, in version 1 of the 
protocol, with all options off by default.  This ensures backward 
compatibitlity since future clients will beforced to be backward compatible to 
even start talking.  The clients then exchange a WireFormatInfo which contains 
information about the highest version of the protocol and requested protocol 
options that should be turned on.  After that exchange both sides can upgrade 
the version and options to a set that is compatible between the 2 ends.

 2. What determines the order of the attributes on each package? The order now 
 seems to be determined by the groovy scripts.

They are in the order that they were defined in the orifinal Java command 
classes.  The groovy script just preserves the order.


 3. What about the order of the boolean flags used in tight encoding, what 
 does each position stand for?


The bits in the BooleanStream are also serialized in the same order.

 I must ask you of some documentation on this because we cannot verify that 
 our code is correct otherwise.


Any time!  I guess we need to update the C++ guy to support loose encoding 
since that is now the minimum requirement.  At least it's much simpler to 
implement.  Should I work on that or have you guys allready have that covered?

Regards,
Hiram

 Please help!

 Regards,
 Mats Forslöf



--
Regards,
Hiram

Re: ActiveMQ Graduation From Incubator

2006-03-16 Thread Dain Sundstrom


+1

I couldn't have said it better myself.

-dain

On Mar 15, 2006, at 4:27 PM, David Blevins wrote:

If you ask me what my opinion on OpenEJB's future or James' opinion  
on ActiveMQ's future, we'll both probably tell you TLP is a good  
goal eventually.


We've more or less been running as TLPs in relation to Geronimo for  
the past two plus years already, just at Codehaus.  We've seen how  
that plays out and we'd like to try a much more unified front for a  
while and see what shakes out.  We're all ready for a change in the  
status-quo.


The Geronimo world is awkward and unbalanced.  We have too tight  
integration with OpenEJB such that the standalone version of that  
completely disappeared.  We have too little integration with  
ActiveMQ such that the things you can do with standalone ActiveMQ  
you can't do with the Geronimo ActiveMQ.  We have parts of Geronimo  
which could very well become separately reusable components, like  
the transaction manager or the XBean code.  We're aren't  
successfully leveraging each other's communities to the fullest.   
All in all, we don't make decisions together and lean on each other  
as much as we could.


I'd really like to see all our projects rolled up, balanced out,  
then split up again along possibly different lines with potentially  
more standalone pieces than we see now.


TLP is a good goal, but I really see value in the journey.

-David

Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows

2006-03-16 Thread ian . d . stewart

Jacek,

You should (untested) be able to make this dependeny explict by adding the
following to your parent POM:

dependency
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-surefire-plugin/artifactId
  version2.2-SNAPSHOT/version
/dependency


HTH,
Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078



   
  Jacek Laskowski 
   
  [EMAIL PROTECTED]To:   
dev@geronimo.apache.org   
  m   cc:  
   
   Subject:  Re: [jira] Commented: 
(MSUREFIRE-78) forkMode=once or pertest does not work   
  03/16/2006 11:11  on windows  
   
  AM
   
  Please respond to 
   
  dev   
   

   




2006/3/16, anita kulshreshtha [EMAIL PROTECTED]:
 Jacek,
   We need to change to surefire-plugin version
 2.2-SNAPSHOT.

Good shot! You're doing a great job with the migration. Thanks!

Will give it a try and commit the changes soon. I'm working with the
m2 sources so I need to be very careful to not introduce something
that's not supposed to work in a previous yet stable release of Maven
itself and its plugins.

 Anita

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (AMQ-637) Enhance ActiveMQInput/Outputstream to use a real TCP connection.

[ http://jira.activemq.org/jira//browse/AMQ-637?page=comments#action_35766 
] 

james strachan commented on AMQ-637:


Sounds fine with me :)

BTW is the idea that the socket will only be open for the duration of the input 
stream, so that the transfer is independent of the underlying JMS connection? 

We do need to chunk the message on the broker side to avoid it having to load 
the whole stream into RAM; is this OK with you?

 Enhance ActiveMQInput/Outputstream to use a real TCP connection.
 

  Key: AMQ-637
  URL: http://jira.activemq.org/jira//browse/AMQ-637
  Project: ActiveMQ
 Type: Improvement

 Reporter: Robert Newson



 Currently the ActiveMQInputStream and ActiveMQOutputStreams chunk large 
 messages into 64k chunks.
 Instead of that, could the act of calling getInputStream(Destination) 
 negotiates a new TCP socket connection? Using ActiveMQ will still give us 
 location transparency, but will the full streaming power of TCP.
 I spoke with Hiram about this and he thought it would be a fairly simple 
 enhancement. I'm happy to work with him on this as we have a strong need for 
 this functionality.

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

Re: OpenWire tight/loose encoding

2006-03-16 Thread James Strachan

Great stuff Mats!

BTW as a background; tight v loose is one of those trade offs; loose
is simpler to code and may use less CPU whereas tight uses the minimum
possible network bandwidth. Depending on your use case loose could
actually be the best choice - but its certainly the easiest to
implement - so there's no real reason why non-Java clients need to
worry too much about supporting it.

James

On 3/16/06, Mats Forslöf [EMAIL PROTECTED] wrote:
 Hi Hiram

 Thanks for the update. We have already selected the loose encoding as the 
 default encoding in the C++ client, it's good to see that we have selected 
 the same. The tight encoding is deferred to a future release since it is a 
 bit more complicated and we wanted something up and running. We're just 
 finished a architectural re-design in the C++ client that makes a lot less 
 code to maintain and a bit easy to add other protocols (see previous posts 
 regarding C++ refactoring suggestion).

 Will get back soon with a new patch udpate including updated groovy scripts.

 Regards,
 Mats


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino
 Sent: den 16 mars 2006 13:46
 To: activemq-dev@geronimo.apache.org
 Subject: Re: OpenWire tight/loose encoding

 Hi Mats!

 On 3/16/06, Mats Forslöf [EMAIL PROTECTED] wrote:
  Hi,
 
  We need some additional information on the OpenWire protocol to wrap up our 
  work on the C++ AMQ client.
 
  1. To use loose encoding what do we have to do, is it simply to set the 
  tight encoding attribute to false on the OpenWireFormat package and then 
  send each package attributes one after each other?
 

 OpenWire should always start up in loose encoding mode, in version 1 of the 
 protocol, with all options off by default.  This ensures backward 
 compatibitlity since future clients will beforced to be backward compatible 
 to even start talking.  The clients then exchange a WireFormatInfo which 
 contains information about the highest version of the protocol and requested 
 protocol options that should be turned on.  After that exchange both sides 
 can upgrade the version and options to a set that is compatible between the 2 
 ends.

  2. What determines the order of the attributes on each package? The order 
  now seems to be determined by the groovy scripts.

 They are in the order that they were defined in the orifinal Java command 
 classes.  The groovy script just preserves the order.

 
  3. What about the order of the boolean flags used in tight encoding, what 
  does each position stand for?
 

 The bits in the BooleanStream are also serialized in the same order.

  I must ask you of some documentation on this because we cannot verify that 
  our code is correct otherwise.
 

 Any time!  I guess we need to update the C++ guy to support loose encoding 
 since that is now the minimum requirement.  At least it's much simpler to 
 implement.  Should I work on that or have you guys allready have that covered?

 Regards,
 Hiram

  Please help!
 
  Regards,
  Mats Forslöf
 


 --
 Regards,
 Hiram



--

James
---
http://radio.weblogs.com/0112098/

Location of the log files

2006-03-16 Thread anita kulshreshtha

Hi,
Many test programs use log4j.properties file with
a line :
log4j.appender.R.File=target/test-reports/network.log
or a line like this in the *Test.java :
props.put(file, target/login-audit.log);

In maven1 builds they are taken as relative to the
build directory. But in m2 build they are not being
resolved consistently. Here is an example where it is
resolved to :

Caused by: java.io.FileNotFoundException:
C:\DOCUME~1\User\LOCALS~1\Temp\target\login-audit.log
(The system cannot find the path specified)
at java.io.FileOutputStream.openAppend(Native Method)
 How are these resolved?

Thnaks
Anita

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

[jira] Commented: (AMQ-637) Enhance ActiveMQInput/Outputstream to use a real TCP connection.

2006-03-16 Thread Robert Newson (JIRA)

[ http://jira.activemq.org/jira//browse/AMQ-637?page=comments#action_35767 
] 

Robert Newson commented on AMQ-637:
---


Some kind of connection pooling might be even better, but in the absence of 
that I'd be happy for the socket to exist only for the duration of the input 
stream. I'd definitely prefer it to be separate from the underlying JMS 
connection.

Avoiding having the whole stream in RAM is a primary goal for us. We expect to 
see 99% of our incoming messages at around 2k, but the 1% are likely to be 
enormous (potentially up to 1gb). By negotiating a tcp stream I was hoping that 
we could use its blocking behaviour to cap the amount of RAM consumed on either 
side. In our case, we're writing the data we receive to a file system.

The way I would plan to handle the two cases we have is to send an initial 
request message with the size of the payload and then switch to the streaming 
case at some threshold. For small messages, we'd include the payload in that 
request.



 Enhance ActiveMQInput/Outputstream to use a real TCP connection.
 

  Key: AMQ-637
  URL: http://jira.activemq.org/jira//browse/AMQ-637
  Project: ActiveMQ
 Type: Improvement

 Reporter: Robert Newson



 Currently the ActiveMQInputStream and ActiveMQOutputStreams chunk large 
 messages into 64k chunks.
 Instead of that, could the act of calling getInputStream(Destination) 
 negotiates a new TCP socket connection? Using ActiveMQ will still give us 
 location transparency, but will the full streaming power of TCP.
 I spoke with Hiram about this and he thought it would be a fairly simple 
 enhancement. I'm happy to work with him on this as we have a strong need for 
 this functionality.

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

Console Patches

2006-03-16 Thread Aaron Mulder

I'm looking at console issues and patches in JIRA.  The following ones
look like good candidates.  Does anyone have any comments or thoughts
on which ones may be or not be ready or any dependencies between them?

Thanks,
Aaron

Patches:
1037: confirmation when deleting things
1130: make more generic web statistics for Jetty (NOTE: waiting on
updated patch from Joe), see also 1408
1182: web connector portlet confirmation, cancel button, etc.
1196: keystore portlet improvements (empty alias blows up)
1199: keystore portlet improvements (display fingerprints)
1396: more consistent look and feel for tables
1413: set JSPs to UTF-8
1414: set icon for about page
1426: console breakage on Windows with spaces in install path
1484: display logged-in username
1498: not serializable exception due to JDBC driver download
1503: keystore portlet improvements (passwords)
1524: allow selection of multiple JDBC driver JARs
1529: show Geronimo version number in console
1531: keystore portlet enhancements (delete cert/key)
1572: better error if cookies are disabled
1634: NoClassDefFoundError in log viewer (NOTE: Jeff looking at this)
1699: missing JDOM classes (NOTE: Jeff looking at this)
1700: stack trace printed if deploy app that's already deployed
1701: improvements to EJB portlet

No patch yet, but should be looked at:
1273: More context info when adding JMS protocol
1376: display URL for deployed web apps
1388: Make sure Go button is visible
1390: Link not always visible
1391: keystore error, looks like keystore issues described above
1592: Add new security realm type
1692: Next server restart after console edits dumps stack trace
1704: Need to be able to select a JAR for a security realm
1705: AJAX progress bar for JDBC driver download
1711: Add restart option for web connector
1721: Ability to delete a security realm
1741: Ability to redeploy an application
1746: Change to log config file not respected on restart

Re: Console Patches

2006-03-16 Thread Hernan Cunico


Hi Aaron,
here are a few more related to the console, these falls in the second group (no 
patch yet)

1641: Using default Console Realm, when delete a user it will not be removed 
from the groups.
1663: Ability to test database pool connections after editing.
1664: Export / Import configurations capability.

Cheers!
Hernan

Aaron Mulder wrote:

I'm looking at console issues and patches in JIRA.  The following ones
look like good candidates.  Does anyone have any comments or thoughts
on which ones may be or not be ready or any dependencies between them?

Thanks,
Aaron

Patches:
1037: confirmation when deleting things
1130: make more generic web statistics for Jetty (NOTE: waiting on
updated patch from Joe), see also 1408
1182: web connector portlet confirmation, cancel button, etc.
1196: keystore portlet improvements (empty alias blows up)
1199: keystore portlet improvements (display fingerprints)
1396: more consistent look and feel for tables
1413: set JSPs to UTF-8
1414: set icon for about page
1426: console breakage on Windows with spaces in install path
1484: display logged-in username
1498: not serializable exception due to JDBC driver download
1503: keystore portlet improvements (passwords)
1524: allow selection of multiple JDBC driver JARs
1529: show Geronimo version number in console
1531: keystore portlet enhancements (delete cert/key)
1572: better error if cookies are disabled
1634: NoClassDefFoundError in log viewer (NOTE: Jeff looking at this)
1699: missing JDOM classes (NOTE: Jeff looking at this)
1700: stack trace printed if deploy app that's already deployed
1701: improvements to EJB portlet

No patch yet, but should be looked at:
1273: More context info when adding JMS protocol
1376: display URL for deployed web apps
1388: Make sure Go button is visible
1390: Link not always visible
1391: keystore error, looks like keystore issues described above
1592: Add new security realm type
1692: Next server restart after console edits dumps stack trace
1704: Need to be able to select a JAR for a security realm
1705: AJAX progress bar for JDBC driver download
1711: Add restart option for web connector
1721: Ability to delete a security realm
1741: Ability to redeploy an application
1746: Change to log config file not respected on restart

[jira] Updated: (GERONIMO-1646) Module migration to Maven2: tomcat-builder

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

Anita Kulshreshtha updated GERONIMO-1646:
-

Attachment: pom.patch

This can be built from tomcat-builder directory.
If tomcat does not build from top down build, build it form tomcat dir. and 
comment it out in the parent pom.
Need to test it in top down build.

 Module migration to Maven2: tomcat-builder
 --

  Key: GERONIMO-1646
  URL: http://issues.apache.org/jira/browse/GERONIMO-1646
  Project: Geronimo
 Type: Sub-task
   Components: Tomcat
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Anita Kulshreshtha
  Attachments: pom.patch

 It's a task to help keep track of the progress of the tomcat-builder module 
 build migration to Maven2

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

Re: Console Patches

2006-03-16 Thread Paul McMahan

Here's one more that has a patch:
973: Add security to /console-standard

thanks,
Paul

On 3/16/06, Aaron Mulder [EMAIL PROTECTED] wrote:
 I'm looking at console issues and patches in JIRA.  The following ones
 look like good candidates.  Does anyone have any comments or thoughts
 on which ones may be or not be ready or any dependencies between them?

 Thanks,
 Aaron

 Patches:
 1037: confirmation when deleting things
 1130: make more generic web statistics for Jetty (NOTE: waiting on
 updated patch from Joe), see also 1408
 1182: web connector portlet confirmation, cancel button, etc.
 1196: keystore portlet improvements (empty alias blows up)
 1199: keystore portlet improvements (display fingerprints)
 1396: more consistent look and feel for tables
 1413: set JSPs to UTF-8
 1414: set icon for about page
 1426: console breakage on Windows with spaces in install path
 1484: display logged-in username
 1498: not serializable exception due to JDBC driver download
 1503: keystore portlet improvements (passwords)
 1524: allow selection of multiple JDBC driver JARs
 1529: show Geronimo version number in console
 1531: keystore portlet enhancements (delete cert/key)
 1572: better error if cookies are disabled
 1634: NoClassDefFoundError in log viewer (NOTE: Jeff looking at this)
 1699: missing JDOM classes (NOTE: Jeff looking at this)
 1700: stack trace printed if deploy app that's already deployed
 1701: improvements to EJB portlet

 No patch yet, but should be looked at:
 1273: More context info when adding JMS protocol
 1376: display URL for deployed web apps
 1388: Make sure Go button is visible
 1390: Link not always visible
 1391: keystore error, looks like keystore issues described above
 1592: Add new security realm type
 1692: Next server restart after console edits dumps stack trace
 1704: Need to be able to select a JAR for a security realm
 1705: AJAX progress bar for JDBC driver download
 1711: Add restart option for web connector
 1721: Ability to delete a security realm
 1741: Ability to redeploy an application
 1746: Change to log config file not respected on restart

[jira] Updated: (GERONIMO-1645) Module migration to Maven2: tomcat

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

Anita Kulshreshtha updated GERONIMO-1645:
-

Attachment: pom.patch

added  java.endorsed.dirs system property. 

 Module migration to Maven2: tomcat
 --

  Key: GERONIMO-1645
  URL: http://issues.apache.org/jira/browse/GERONIMO-1645
  Project: Geronimo
 Type: Sub-task
   Components: Tomcat
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Anita Kulshreshtha
  Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, 
 pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, pom.xml, 
 pom.xml, tomcat-tests.patch

 It's a task to help keep track of the progress of the tomcat module build 
 migration to Maven2

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

[jira] Assigned: (GERONIMO-1723) Module migration to Maven 2: axis-builder

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

Anita Kulshreshtha reassigned GERONIMO-1723:


Assign To: Anita Kulshreshtha

 Module migration to Maven 2: axis-builder
 -

  Key: GERONIMO-1723
  URL: http://issues.apache.org/jira/browse/GERONIMO-1723
  Project: Geronimo
 Type: Sub-task
   Components: webservices
 Reporter: Jacek Laskowski
 Assignee: Anita Kulshreshtha
  Fix For: 1.x


 It's a task to help keep track of the progress of the module build migration 
 to Maven2

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

[jira] Updated: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface

2006-03-16 Thread Joe Bohn (JIRA)

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

Joe Bohn updated GERONIMO-1130:
---

Attachment: 1130_WebServerStatsJetty.patch

Things have changed somewhat since this patch was first created.  This is an 
updated version of the patch for revision 386247.

Once again this patch was created on win-xp from the geronimo root directory on 
trunk.

 Implement WebServer Manager (statistics gathering/reporting) management 
 interface
 -

  Key: GERONIMO-1130
  URL: http://issues.apache.org/jira/browse/GERONIMO-1130
  Project: Geronimo
 Type: New Feature
   Components: management, console
 Versions: 1.0-M5
  Environment: all
 Reporter: Joe Bohn
  Fix For: 1.2
  Attachments: 1130_WebServerStatsJetty.patch, StatsJetty5.1.5.patch, 
 StatsJetty5.1.7rc05.patch, StatsJettyG1.0.patch

 Jetty has a statistics gathering and reporting capability that is support in 
 the console via the Web Server Manager portlet.  We should provide similar 
 monitoring capabilities for tomcat.
 However, the Jetty implementation is tightly bound to Jetty.  We need a more 
 generic interface build upon the principles of JSR77 to address statistical 
 information for the web server (both jetty and tomcat).

-- 
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: Console Patches

2006-03-16 Thread Joe Bohn


Aaron,

Regarding 1130, I just attached a new version of the patch for the 
current trunk so it is ready to go be considered.   Please use the newly 
added patch (1130_WebServerStatsJetty.patch).


1408 would be fine to include in the second group of JIRAs (those w/o 
patches) but it really isn't directly related to this JIRA.  This only 
deals with the web server statistics ... not the Network Listeners 
portlet that is presented on the same page.


Thanks for looking into these.
Joe



Aaron Mulder wrote:

I'm looking at console issues and patches in JIRA.  The following ones
look like good candidates.  Does anyone have any comments or thoughts
on which ones may be or not be ready or any dependencies between them?

Thanks,
Aaron

Patches:
1037: confirmation when deleting things
1130: make more generic web statistics for Jetty (NOTE: waiting on
updated patch from Joe), see also 1408
1182: web connector portlet confirmation, cancel button, etc.
1196: keystore portlet improvements (empty alias blows up)
1199: keystore portlet improvements (display fingerprints)
1396: more consistent look and feel for tables
1413: set JSPs to UTF-8
1414: set icon for about page
1426: console breakage on Windows with spaces in install path
1484: display logged-in username
1498: not serializable exception due to JDBC driver download
1503: keystore portlet improvements (passwords)
1524: allow selection of multiple JDBC driver JARs
1529: show Geronimo version number in console
1531: keystore portlet enhancements (delete cert/key)
1572: better error if cookies are disabled
1634: NoClassDefFoundError in log viewer (NOTE: Jeff looking at this)
1699: missing JDOM classes (NOTE: Jeff looking at this)
1700: stack trace printed if deploy app that's already deployed
1701: improvements to EJB portlet

No patch yet, but should be looked at:
1273: More context info when adding JMS protocol
1376: display URL for deployed web apps
1388: Make sure Go button is visible
1390: Link not always visible
1391: keystore error, looks like keystore issues described above
1592: Add new security realm type
1692: Next server restart after console edits dumps stack trace
1704: Need to be able to select a JAR for a security realm
1705: AJAX progress bar for JDBC driver download
1711: Add restart option for web connector
1721: Ability to delete a security realm
1741: Ability to redeploy an application
1746: Change to log config file not respected on restart




--
Joe Bohn
joe.bohn at earthlink.net

He is no fool who gives what he cannot keep, to gain what he cannot 
lose.   -- Jim Elliot

Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows

Hmm.. I tried to use the 2.2-SNAPSHOT. It couldn't find that in any repo.

I tried to build it. But the copy in the trunk still says, 2.1.3-SNAPSHOT .
(http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-surefire-plugin/pom.xml?view=markup)

I couldn't find the discussion in the maven dev list that Brett mentioned.

I am missing something here.


Cheers
Prasad


On 3/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
 Jacek,
   We need to change to surefire-plugin version
 2.2-SNAPSHOT.

 Thnaks
 Anita
 Note: forwarded message attached.


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


 -- Forwarded message --
 From: Brett Porter (JIRA) [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Date: Wed, 15 Mar 2006 20:16:32 -0600 (CST)
 Subject: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not 
 work on windows
 [ http://jira.codehaus.org/browse/MSUREFIRE-78?page=comments#action_61177 
 ]

 Brett Porter commented on MSUREFIRE-78:
 ---

 It requires 2.2-SNAPSHOT of the surefire plugin. Instructions were details on 
 the [EMAIL PROTECTED] list if that's necessary.

  forkMode=once or pertest does not work on windows
  -
 
   Key: MSUREFIRE-78
   URL: http://jira.codehaus.org/browse/MSUREFIRE-78
   Project: Maven 2.x Surefire Plugin
  Type: Bug

   Environment: Win Xp
  Reporter: Anita Kulshreshtha
  Assignee: Brett Porter

 
 
  I am building a simple HelloWorldTest.java. The test builds fine with 'mvn 
  test'. When I use 'mvn -DforkMode=once test',
  I get BUILD ERROR. The surefire-reports directory is not created. One of 
  the 3 files left behind in the target directory is
  surefire-classloader.properties. Its contents are :
   #classpath entries
  #Wed Mar 15 08:09:47 EST 2006
  childDelegation=true
  classpath=D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\test-classes\:D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\classes\:C\:\\Documents
   and 
  Settings\\User\\.m2\\repository\\junit\\junit\\3.8.1\\junit-3.8.1.jar\:C\:\\Documents
   and 
  Settings\\User\\.m2\\repository\\org\\apache\\maven\\maven-plugin-api\\2.0\\maven-plugin-api-2.0.jar\:C\:\\Documents
   and 
  Settings\\User\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire\\1.5.3-SNAPSHOT\\surefire-1.5.3-SNAPSHOT.jar
 It uses ':' as a path separator. This issue was discusses earlier in 
  Msurefire-76 and closed.

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

[jira] Closed: (GERONIMO-1634) NoClassDefFoundError from Derby Log Viewer

2006-03-16 Thread Jeff Genender (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1634?page=all ]
 
Jeff Genender closed GERONIMO-1634:
---

Resolution: Fixed

Patch applied.  Thanks.

Sendingconfigs/console-jetty/project.xml
Sendingconfigs/console-tomcat/project.xml
Transmitting file data ..
Committed revision 386453.


 NoClassDefFoundError from Derby Log Viewer
 --

  Key: GERONIMO-1634
  URL: http://issues.apache.org/jira/browse/GERONIMO-1634
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.2
  Environment: windows XP  happens on tomcat and jetty
 Reporter: Joe Bohn
  Fix For: 1.2
  Attachments: LogViewerDep.patch

 Changes that were introduced (by me :-(  )  to eliminate unnecessary 
 dependencies and reduce the size of the minimal assembly exposed places where 
 dependencies were missing.  This particular one is that the console 
 configuration needs a dependency on geronimo.derby.
 This results in the following exception when attempting to view the derby 
 logs:
 13:51:55,441 ERROR [[DerbyLogViewer]] Servlet.service() for servlet 
 DerbyLogViewer threw exception
 java.lang.NoClassDefFoundError
 at 
 org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.class$(DerbyLogViewerPortlet.java:60)
 at 
 org.apache.geronimo.console.derbylogmanager.DerbyLogViewerPortlet.doView(DerbyLogViewerPortlet.java:60)
 at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
 at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
 at 
 org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
 at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at 
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
 at 
 org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
 at 
 org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
 at 
 org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
 at 
 org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
 at 
 org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
 at 
 org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at 
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
 at 
 org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
 at 
 org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
 at 
 org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
 at 
 org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp:64)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
 at

[jira] Closed: (GERONIMO-1699) jdom classes not available for information portlet

2006-03-16 Thread Jeff Genender (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1699?page=all ]
 
Jeff Genender closed GERONIMO-1699:
---

Resolution: Fixed

Patch applied...thanks.

Sendingconfigs/console-jetty/project.xml
Sendingconfigs/console-tomcat/project.xml
Transmitting file data ..
Committed revision 386454.


 jdom classes not available for information portlet
 --

  Key: GERONIMO-1699
  URL: http://issues.apache.org/jira/browse/GERONIMO-1699
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.2
  Environment: windows xp
 Reporter: Joe Bohn
  Fix For: 1.2
  Attachments: 1699_InfoPortlet.patch

 The jdom classes are not available to the console application since being 
 removed from j2ee-server.  The following messages are issues when the 
 information portlet is selected from the console:
 09:56:50,826 INFO  [DefaultConverterManager] Can't marshall org.jdom.Document 
 because converter 'jdom' is not available. The converter definition may be 
 missing
 , or required element may be missing from the CLASSPATH
 09:56:50,826 INFO  [DefaultConverterManager] Can't marshall org.jdom.Element 
 because converter 'jdom' is not available. The converter definition may be 
 missing,
  or required element may be missing from the CLASSPATH

-- 
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: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

2006-03-16 Thread Filip Hanik - Dev Lists


Hey Jules,
thanks for commenting, I will pop in on codehaus devlists.
The lazy replicated map supports more than one backup node, with a very 
small tweak in just one method, you can change it to be N number of 
backup nodes. N being configurable, just a matter of getting the conf 
param down to the impl level.


Apache Tribes, as I like to nickname the Tomcat group communication 
protocol, has an implementation at

http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/modules/groupcom/
including the LazyReplicatedMap and a MapDemo (you're gonna be awed by 
my Swing skills).


I am also in the place of implementing a regular ReplicatedMap, to use 
for context attribute replication, a feature sought after.


I will subscribe to the WADI list and we can continue over there re: 
session management.


Filip



Jules Gosnell wrote:

Filip Hanik - Dev Lists wrote:


gentlemen, not a committer here, but wanted to share some thoughts.

in my opinion, the Session API should not have to know about 
clustering or session replication, nor should it need to worry about 
location.

the clustering API should take care of all of that.


We are 100% in agreement here, Filip.

the solution that we plan to implement for Tomcat is fairly straight 
forward. Let me see if I can give an idea of how the API shouldn't 
need to worry, its a little lengthy, but it shows that the Session 
and the SessionManager need to know zero about clustering or session 
locations. (this is only one solution, and other solutions should 
demonstrate the same point, SessionAPI need to know nothing about 
clustering or session locations)


1. Requirements to be implemented by the Session.java API
  bool isDirty - (has the session changed in this request)
  bool isDiffable - is the session able provide a diff
  byte[] getSessionData() - returns the whole session
  byte[] getSessionDiff() - optional, see isDiffable, resets the diff 
data
  void setSessionDiff(byte[] diff) - optional, see isDiffable, apply 
changes from another node


So, delta-ed sessions, at whole session or attribute granularity ? and 
when will you be sending the deltas - immediately, end of 
request[-group], pluggable strategies ?



2. Requirements to be implemented by the SessionManager.java API
  void setSessionMap(HashMap map) - makes the map implementation 
pluggable


3. And the key to this, is that we will have an implementation of a 
LazyReplicatedHashMap

  The key object in this map is the session Id.
  The map entry object is an object that looks like this
  ReplicatedEntry {
 string id;//sessionid
 bool isPrimary; //does this node hold the data
 bool isBackup; //does this node hold backup data
 Session session; //not null values for primary and backup nodes
 Member primary; //information about the primary node
 Member backup; //information about the backup node
  }

  The LazyReplicatedHashMap overrides get(key) and put(id,session)


interesting...

So all the nodes will have the a sessionId,ReplicatedEntry 
combinations in their session map. But only two 


two is a fixed number or deploy-time parameter ?


nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the 
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new 
one, and do a publish to the entire cluster of the locations.


As you can see, all-to-all communications only happens when a Session 
is (created|destroyed|failover). Other than that it is 
primary-to-backup communication only, and this can be in terms of 
diffs or entire sessions using the isDirty or getDiff. This is 
triggered either by an interceptor at the end of each request or by a 
batch process for less network jitter but less accuracy (but 
adequate) for fail over.


I see - that answers my question about when replication occurs :-)



As you can see, access time is not relevant here, nor does the 
Session API even know about clustering.


yes !



In tomcat we have separated out group communication into a separate 
module, we are implementing the LazyReplicatedHashMap right now just 
for this purpose.


positive thoughts, criticism and bashing are all welcome :)


This approach has much more in common with WADI's - in fact there is 
lot of synergy here. I think the WADI and TC clustering teams could 
learn a lot from each other. I would be very interested in sitting 
down with you Filip and having a long chat about session management. 
Do you have a Tomcat clustering-specific list that I could jump onto ? 
You might be interested in popping in on [EMAIL PROTECTED]  and 
learning a little more about WADI ?


regards,

Jules



Filip

Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows

There are issues with the 2.2-SNAPSHOT.

1. With the connector module:
The connector module tests don't fail but spews a lot, A LOT, of a
java.lang.AssertError.

2. With the basedir system property:
The system property basedir set by the connector-builder module
seems to be stuck and used by other modules following it. So the tests
for the client-builder fails. When client-builder module's
PlanParsingTest reads the basedir system property, it gets it as set
to connector-builder !! If you skip the client-builder tests, then
tests of directory module downstream fails for the same reason. When
you skip the connector-builder tests, the basedir is set to j2ee,
another module further upstream.

The same problems are not seen in surefire 2.1.3-SNAPSHOT plugin.

Cheers
Prasad

On 3/16/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
I added the following section to the pluginRepositories and now it
downloaded the surefire-plugin 2.2-SNAPSHOT. But it also downloaded a
LOT of other pluigns too. So I am not sure if what I did was right.

pluginRepository
releases
enabledtrue/enabled
/releases
idApache CVS/id
nameApache CVS of the Central Repository/name
urlhttp://cvs.apache.org/maven-snapshot-repository/url
/pluginRepository

Cheers
Prasad

On 3/16/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Hmm.. I tried to use the 2.2-SNAPSHOT. It couldn't find that in any repo.

I tried to build it. But the copy in the trunk still says, 2.1.3-SNAPSHOT .
(http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-surefire-plugin/pom.xml?view=markup)

I couldn't find the discussion in the maven dev list that Brett mentioned.

I am missing something here.

Cheers
Prasad

On 3/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Jacek,
We need to change to surefire-plugin version
2.2-SNAPSHOT.

Thnaks
Anita
Note: forwarded message attached.

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

-- Forwarded message --
From: Brett Porter (JIRA) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed, 15 Mar 2006 20:16:32 -0600 (CST)
Subject: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does
not work on windows
[
http://jira.codehaus.org/browse/MSUREFIRE-78?page=comments#action_61177 ]

Brett Porter commented on MSUREFIRE-78:
---

It requires 2.2-SNAPSHOT of the surefire plugin. Instructions were
details on the [EMAIL PROTECTED] list if that's necessary.

forkMode=once or pertest does not work on windows
-

Key: MSUREFIRE-78
URL: http://jira.codehaus.org/browse/MSUREFIRE-78
Project: Maven 2.x Surefire Plugin
Type: Bug

Environment: Win Xp
Reporter: Anita Kulshreshtha
Assignee: Brett Porter

I am building a simple HelloWorldTest.java. The test builds fine with
'mvn test'. When I use 'mvn -DforkMode=once test',
I get BUILD ERROR. The surefire-reports directory is not created. One
of the 3 files left behind in the target directory is
surefire-classloader.properties. Its contents are :
#classpath entries
#Wed Mar 15 08:09:47 EST 2006
childDelegation=true
classpath=D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\test-classes\:D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\classes\:C\:\\Documents
and
Settings\\User\\.m2\\repository\\junit\\junit\\3.8.1\\junit-3.8.1.jar\:C\:\\Documents
and
Settings\\User\\.m2\\repository\\org\\apache\\maven\\maven-plugin-api\\2.0\\maven-plugin-api-2.0.jar\:C\:\\Documents
and
Settings\\User\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire\\1.5.3-SNAPSHOT\\surefire-1.5.3-SNAPSHOT.jar
It uses ':' as a path separator. This issue was discusses earlier in
Msurefire-76 and closed.

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

Re: [wadi-dev] Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

2006-03-16 Thread Jules Gosnell


Filip Hanik - Dev Lists wrote:


Hey Jules,
thanks for commenting, I will pop in on codehaus devlists.
The lazy replicated map supports more than one backup node, with a 
very small tweak in just one method, you can change it to be N number 
of backup nodes. N being configurable, just a matter of getting the 
conf param down to the impl level.


nice :-) - we are just getting the first cut of our in-vm replication 
service in place - it is similarly parameterisable, with a pluggable 
strategy for selecting suitable replication partners...


Apache Tribes, as I like to nickname the Tomcat group communication 
protocol, has an implementation at
http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/modules/groupcom/ 

including the LazyReplicatedMap and a MapDemo (you're gonna be awed by 
my Swing skills).


Hmmm.. - I shall need to take the time to look at this.



I am also in the place of implementing a regular ReplicatedMap, to use 
for context attribute replication, a feature sought after.


Yes - I have shied away from supporting distributed context attributes, 
since they are not specced - but, you never know :-)




I will subscribe to the WADI list and we can continue over there re: 
session management.


I look forward to seeing you over there,


Jules



Filip



Jules Gosnell wrote:


Filip Hanik - Dev Lists wrote:


gentlemen, not a committer here, but wanted to share some thoughts.

in my opinion, the Session API should not have to know about 
clustering or session replication, nor should it need to worry about 
location.

the clustering API should take care of all of that.


We are 100% in agreement here, Filip.

the solution that we plan to implement for Tomcat is fairly straight 
forward. Let me see if I can give an idea of how the API shouldn't 
need to worry, its a little lengthy, but it shows that the Session 
and the SessionManager need to know zero about clustering or session 
locations. (this is only one solution, and other solutions should 
demonstrate the same point, SessionAPI need to know nothing about 
clustering or session locations)


1. Requirements to be implemented by the Session.java API
  bool isDirty - (has the session changed in this request)
  bool isDiffable - is the session able provide a diff
  byte[] getSessionData() - returns the whole session
  byte[] getSessionDiff() - optional, see isDiffable, resets the 
diff data
  void setSessionDiff(byte[] diff) - optional, see isDiffable, apply 
changes from another node


So, delta-ed sessions, at whole session or attribute granularity ? 
and when will you be sending the deltas - immediately, end of 
request[-group], pluggable strategies ?



2. Requirements to be implemented by the SessionManager.java API
  void setSessionMap(HashMap map) - makes the map implementation 
pluggable


3. And the key to this, is that we will have an implementation of a 
LazyReplicatedHashMap

  The key object in this map is the session Id.
  The map entry object is an object that looks like this
  ReplicatedEntry {
 string id;//sessionid
 bool isPrimary; //does this node hold the data
 bool isBackup; //does this node hold backup data
 Session session; //not null values for primary and backup nodes
 Member primary; //information about the primary node
 Member backup; //information about the backup node
  }

  The LazyReplicatedHashMap overrides get(key) and put(id,session)


interesting...

So all the nodes will have the a sessionId,ReplicatedEntry 
combinations in their session map. But only two 



two is a fixed number or deploy-time parameter ?


nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the 
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new 
one, and do a publish to the entire cluster of the locations.


As you can see, all-to-all communications only happens when a 
Session is (created|destroyed|failover). Other than that it is 
primary-to-backup communication only, and this can be in terms of 
diffs or entire sessions using the isDirty or getDiff. This is 
triggered either by an interceptor at the end of each request or by 
a batch process for less network jitter but less accuracy (but 
adequate) for fail over.



I see - that answers my question about when replication occurs :-)



As you can see, access time is not relevant here, nor does the 
Session API even know about clustering.



yes !



In tomcat we have separated out group communication into a separate 
module, we are implementing the LazyReplicatedHashMap right now just 
for this purpose.


positive thoughts, criticism and bashing are all welcome :)



This approach has much more in common with WADI's - in fact there is 
lot of synergy here. I think the WADI and TC clustering teams could 
learn a lot from each other. I would be very interested in sitting 
down with you Filip and having a long chat about session

[jira] Created: (GERONIMO-1748) Site migration to Maven 2

2006-03-16 Thread John Sisson (JIRA)

Site migration to Maven 2
-

 Key: GERONIMO-1748
 URL: http://issues.apache.org/jira/browse/GERONIMO-1748
 Project: Geronimo
Type: Sub-task
  Components: website  
Versions: 1.2
Reporter: John Sisson
Priority: Minor
 Fix For: 1.2


Currently the Geronimo site is build using Ant.

The Ant build has been recently updated to use Velocity to 1.5-dev (I built 
from svn rev 386004) to fix issue where generated html files have inconsistent 
line endings when building the site on Windows ( see 
http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11613.html )

See http://svn.apache.org/viewcvs?rev=386059view=rev

A conversion to Maven 2 needs to use a version of velocity that has this fix.

You can test whether the version of velocity has the fix by:

* running touch * in cygwin in the geronimo\site\xdocs directory
* build the site
* attempt to check in the generated site files under geronimo\site\docs - if 
you don't get any errors about inconsistent line endings then you are using the 
fixed version of velocity.

For a list of dependencies required by velocity see the doco at 
http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/xdocs/jar-dependencies.xml
 . FYI, the current Ant build loads the jars in the geronimo\site\lib dir onto 
the classpath.

I don't know if velocity's project.xml file is up to date as they aren't doing 
builds with maven yet AFAIK.. 
http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/project.xml



-- 
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-1713) Module migration to Maven2: j2ee-builder

2006-03-16 Thread Prasad Kashyap (JIRA)

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

Prasad Kashyap updated GERONIMO-1713:
-

Attachment: j2ee-builder-apply-me.patch

Jacek,  hope this patch follows the proper convention. Sorry that my earlier 
patch didn't. It was the first time I was creating a new file in svn.

This new file has the ASL 2.0 in it.

This module's tests fail under surefire plugin 2.2-SNAPSHOT. It is because of 
the basedir system property bug in that version of the plugin. It has got 
nothing to do with this module. So you may happily apply  it and consider this 
module migrated.

 Module migration to Maven2: j2ee-builder
 

  Key: GERONIMO-1713
  URL: http://issues.apache.org/jira/browse/GERONIMO-1713
  Project: Geronimo
 Type: Sub-task
   Components: buildsystem
 Reporter: Anita Kulshreshtha
 Assignee: Prasad Kashyap
  Attachments: j2ee-builder-apply-me.patch, j2ee-builder.patch, test-setup.zip



-- 
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-1723) Module migration to Maven 2: axis-builder

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

Anita Kulshreshtha updated GERONIMO-1723:
-

Attachment: pom.patch

This module builds successfully even with maven-surefire 2.1.3-SNAPSHOT.

 Module migration to Maven 2: axis-builder
 -

  Key: GERONIMO-1723
  URL: http://issues.apache.org/jira/browse/GERONIMO-1723
  Project: Geronimo
 Type: Sub-task
   Components: webservices
 Reporter: Jacek Laskowski
 Assignee: Anita Kulshreshtha
  Fix For: 1.x
  Attachments: pom.patch

 It's a task to help keep track of the progress of the module build migration 
 to Maven2

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

[jira] Updated: (GERONIMO-1646) Module migration to Maven2: tomcat-builder

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

Anita Kulshreshtha updated GERONIMO-1646:
-

Attachment: pom.patch

Updated to use m2 geronimo-axis-builder jar. Please discard the previous patch.

 Module migration to Maven2: tomcat-builder
 --

  Key: GERONIMO-1646
  URL: http://issues.apache.org/jira/browse/GERONIMO-1646
  Project: Geronimo
 Type: Sub-task
   Components: Tomcat
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Anita Kulshreshtha
  Attachments: pom.patch, pom.patch

 It's a task to help keep track of the progress of the tomcat-builder module 
 build migration to Maven2

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

Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows