You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <wes...@jb...> - 2006-06-29 14:19:50
|
Ok. But using this approach would require that the RAR not be in the deploy directory (as you said) and they use the alternateDD/jar to point to the RAR and then override. At least from what I am hearing. I guess I am not clear on what the Deployer actually gets in the DeploymentInfo. Just the alternateDD, or is it actually packed in a RAR that just provides the 'wrapping'? I will take a look at JSR88. No reason why we couldn't support both approaches. Do the jboss-ra.xml stuff first and then add the alternate DD support. Man, I am wicked sorry about the idiocy on this one. I have no clue what I was thinking. You can shoot me when you come to Westford...you sort of already did in making me get up and talk in front of people..;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954387#3954387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954387 |
|
From: <sco...@jb...> - 2006-06-29 14:19:31
|
This second way is what you should look at because its the way deployers/components need to operate in jboss5 with the profile service. Given a rar to deploy/add to a profile, there has to be a management view that externalizes the settings that can be set by management tools. This info needs to be stored in the associated server profile outside of the rar. I'm working on merging the current profile service work with the virtual deployment framework in the system2 module to tie this together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954386#3954386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954386 |
|
From: ScottMarlowNovell <do-...@jb...> - 2006-06-29 14:05:01
|
Most of the discussions for JBCACHE-399 have been private. Below is the text from a recent 1-1 conversation.
anonymous wrote :
| (07:47:49) smarlow_sssw: Hi Ben, is now a good time to talk about the issues with the original implementation approach suggested by JBCache-399 (support of Map Key as non-string)?
| (07:49:41) ben_w_wang: sure.
| (07:50:20) ben_w_wang: so you are saying the hashCode is not reliable across vm?
| (07:52:57) smarlow_sssw: I understand what he was trying to suggest, however, to generate the hashcode style FQN, we would have to serialize the key object to a byte array and generate our own hashcode from that. That is the only way I think to have a hashcode style FQN that is the same across different VMs. VM implementations use the Java objects physical member address as the hashcode.
| (07:53:52) ben_w_wang: Will that be too much if user provide his own?
| (07:54:09) smarlow_sssw: sorry, I'm referring to the system.identityHashCode(Object x) method.
| (07:54:54) smarlow_sssw: The default HashCode is also not dependable across different VMS as you don't know how it was implemented by the passed in object.
| (07:55:41) smarlow_sssw: I like his idea but we would need a way to generate the hashcode ourselves I think.
| (07:56:42) smarlow_sssw: sorry, I didn't read your response till now. If the user provides their own hashcode and we trust them, sure.
| (07:57:18) smarlow_sssw: so we could document that users have to implement hashcode to be reliable across the cluster.
| (07:57:45) ben_w_wang: yes, I think this is reasonable (at least to me).
| (07:58:16) ben_w_wang: in generail, I don't expect the key object to be that complicated anyway.
| (07:58:31) ben_w_wang: why won;t you throw it out to the forum to see what other people think?
| (08:02:08) smarlow_sssw: The downside is that this approach isn't safe for objects that don't provide a reliable hashcode function and we cannot tell the difference between good and bad. We will get reports of failure to locate objects from the map (as we will look at the wrong location).
|
| One other issue is dealing with collisions. We need to support multiple values being under the "value" location. I'm not sure how to do this yet.
| (08:02:50) smarlow_sssw: the collision issue is because many different values can have the same hashcode.
| (08:04:08) ben_w_wang: yeah, that's the problem, I think.
| (08:04:57) ben_w_wang: what about the UID? It is unique.
| (08:09:22) smarlow_sssw: We could map UID to the key and maintain the mapping across the cluster. The trick would just be to keep the key ==> UID map up to date. I think that the node that originates the Map update (at Map.Put time) will be responsible for generating the UID. Whichever node removes an entry from the map, will be responsible for removing its UID from the cluster.
| (08:11:24) ben_w_wang: oh, so that doesn't quite work either. :-(
| (08:12:27) smarlow_sssw: I think it could work but I think it would require support at the core Cache level (below PojoCache).
| (08:12:41) smarlow_sssw: In JBC I mean.
| (08:13:11) smarlow_sssw: On a different note, is my current implementation that bad?
| (08:13:24) smarlow_sssw: other than jdbc cache loader, what else is wrong?
| (08:13:48) smarlow_sssw: :)
| (08:17:06) ben_w_wang: nothing except the cache loader and we have this problem of triggering a recursive infinite loop, remember? I am surprised that test case work for you. :-)
| (08:17:41) smarlow_sssw: I thought the recursive loop only would occur if someone called Key.toString ?
| (08:37:18) ben_w_wang: if user defines hashCode and equals in the Key object, I think you will trigger it.
| (08:37:40) ben_w_wang: THis is one thing that I need Kabir to fix on the AOP side, if possible, actually.
| (08:38:29) smarlow_sssw: that sounds like the test case I added, let me take a look.
| (08:42:14) smarlow_sssw: I added "static class SerializableKeyValue implements Serializable" to the CachedMapAopTest.
|
| There are two member variables:
| Integer ivalue;
| String svalue;
|
| public int hashCode()
| {
| return ivalue.hashCode() + svalue.hashCode();
| }
|
|
| (08:42:27) smarlow_sssw: public boolean equals(Object o)
| {
| if(o == this)
| {
| return true;
| }
| if(! (o instanceof SerializableKeyValue)) {
| System.out.println("equals: not instanceof SerializableKeyValue , it is a " + o.getClass().getName());
| return false;
| }
| SerializableKeyValue val = (SerializableKeyValue)o;
| return val.ivalue == this.ivalue && val.svalue == this.svalue;
| }
| (08:42:57) smarlow_sssw: perhaps I need to add a certain type of data to hit the recursive case?
| (08:43:29) ben_w_wang: OK, Serializable won't have the problem. If it is PojoCacheable, then it is a problem.
| (08:45:03) smarlow_sssw: If I remove the serializable tag, will be automatically try to treat it as PojoCacheable?
| (08:45:29) ben_w_wang: No, it won't. You will need to declare it.
| (08:46:06) ben_w_wang: But for now, we can say it has to be Serializable. Then only restriction is cache loader. I am fine with this solution untill we can solve it from AOP.
| (08:49:00)
| smarlow_sssw: before we leave the map problem though, should I add a test that the key is serializable? I did this at first but later removed it as I didn't know if the cache mode is local or replicated. Should I just always require the key to be serializable?
| (08:49:38) smarlow_sssw: It might be helpful if I through an exception on non-serilizable key, so people know about the restriction (if they don't read the doc). :)
| (08:49:57) ben_w_wang: yeah, can you create two separate test cases then?
| (08:50:17) smarlow_sssw: yes, I'll create a negative test for this.
|
We can continue further discussions here, I thought the above conversation might be useful to others, which is why i'm including it here.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954373#3954373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954373
|
|
From: <ad...@jb...> - 2006-06-29 14:03:49
|
The second approach is a way to do what JSR88 does. i.e. You have the original jar + an appserver specific desriptor This avoids having to modify somebody else's archive e.g. opening the jar add META-INF/jboss-ra.xml and then rejaring You have an alternate descriptor + deployer, e.g. jboss-rar.xml that points at the rar (not in the deploy directory) and add overriding configuration in the same descriptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954381#3954381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954381 |
|
From: <sco...@jb...> - 2006-06-29 14:01:31
|
I'm not following your question then. The MBeanProxyExt is simply used to obtain a typesafe proxy on the jmx bean whose management interface is MainDeployerMBean. The standard jmx equivalent is to use the javax.management.MBeanServerInvocationHandler: | ObjectName mainDeployer = ...; | MBeanServer server = ...; | MainDeployerMBean proxy = (MainDeployerMBean) MBeanServerInvocationHandler.newProxyInstance( | server, mainDeployer, MainDeployerMBean.class, false); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954379#3954379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954379 |
|
From: <hei...@jb...> - 2006-06-29 12:05:12
|
in order to get rid of the XB dependencies towards JAF & Mail i suggets we factor out the DataHandler from the XOP interfaces and use an equivalent class that's suffiecient to our needs:
I.e:
| public interface XOPMarshaller
| {
| boolean isXOPPackage();
| String addMtomAttachment(XOPObject obj, String elementNamespace, String elementName);
| String addMtomAttachment(byte[] data, String elementNamespace, String elementName);
| }
|
| public class XOPObject {
|
| private Object content;
| private String contentType;
|
| public XOPObject(Object content) {
| this.content = content;
| }
|
| public Object getContent() {
| return content;
| }
|
| public String getContentType() {
| return contentType;
| }
|
| public void setContentType(String contentType) {
| this.contentType = contentType;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954339#3954339
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954339
|
|
From: <wes...@jb...> - 2006-06-29 12:01:40
|
Right, right...I got it...after I hear something about 50 times I usually understand... I was already working on a jboss-ra.xml, this would seem to be the best case to introduce it. Could you talk about the second case a bit more. This would seem to be the most interesting. Adding jboss-ra.xml is fine but I just want to understand what you thoughts on the alternative approach would be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954337#3954337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954337 |
|
From: <ad...@jb...> - 2006-06-29 11:55:05
|
No. See my earlier comments. The order is: ResourceAdapter deployer 1) Create rar 2) Apply properties (ra.xml) 3) Apply overrides (THIS IS MISSING AND IS JBAS-3343) 4) rar.start() ManagedConnectionFactory deployer 11) Create MCF (waits for rar to full start) 12) Apply properties from rar (ra.xml) 13) Apply properties from mcf (ra.xml) 14) Apply overrides (-ds.xml) The simplest solution is to allow a jboss-ra.xml inside the rar. Another would be to have an alternate dds with the rar not getting directly deployed, e.g. | <rar> | <rar-file>/some/path/to/rar</rar-file> | <ra-config-property> | etc. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954336#3954336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954336 |
|
From: <wes...@jb...> - 2006-06-29 11:50:57
|
Sigh...ok...this morning sucks... Now that I have proven beyond a shadow of a doubt how utterly f*(@*$ stupid I really am...is there anything wrong with overriding the ResourceAdapter with *-ds.xml properties when we start the deployment? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954335#3954335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954335 |
|
From: <wes...@jb...> - 2006-06-29 11:44:27
|
Ok, so I propose the following: *-ds.xml is modified Adding <ra-config-property> </ra-config-property> <config-property scope="ra"/> This will give us enough to set the property on the adatper. Agreed? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954334#3954334 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954334 |
|
From: <wes...@jb...> - 2006-06-29 11:42:46
|
Sigh...ok...now I am a complete idiot... I see it....Damnit... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954333#3954333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954333 |
|
From: <wes...@jb...> - 2006-06-29 11:41:53
|
Where in RAR deployment do we apply the properties for a ResourceAdapter? We definitely do it for the ManagedConnectionFactory, but not for the adapter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954332#3954332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954332 |
|
From: <ad...@jb...> - 2006-06-29 11:41:50
|
Resynch your tree. They work fine for me and cruisecontrol agrees. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954331#3954331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954331 |
|
From: <ad...@jb...> - 2006-06-29 11:37:48
|
"wes...@jb..." wrote : And for some reason...as if literally on cue...we get 2 questions about this in the user forum, and the JIRA task itself... | | One thing we could do is add a new element to the *-ds.xml file specifically naming RA level properties. Something like: | | <ra-config-property> | | Or, add a 'scope' attribute to the existing element. I am inclined to the former just because it is more clear. | | You can't specify rar properties in the -ds.xml (managed connection factory) It is too late. The rar is already initialized and start() invoked. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954330#3954330 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954330 |
|
From: <ad...@jb...> - 2006-06-29 11:36:10
|
"wes...@jb..." wrote : | We definitely don't do the first one, hence the JIRA task, but we also don't allow for the second condition at all. Typical case would be an RA with the following properties: | | RA | ServerName = "localhost" | Port = "8080" | | | MCF | ServerName = "" | Port = "" | | (Yes, yes, stupid example I know) | What are you talking about? We apply the rar properties from the ra.xml to the ResourceAdapter We also apply the rar properties onto the MCF, there are tests for this. Your example is stupid. In this case, if they specify ServerName="" on the MCF then that is the ServerName. If they want the rar value then they shouldn't specify it on the MCF. The jira issue is about modifying the ResourceAdapter properties without having to modify the ra.xml, e.g. using an alt-dd or jboss-ra.xml, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954329#3954329 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954329 |
|
From: <ad...@jb...> - 2006-06-29 11:28:03
|
I already discussed this Thomas and you pointed to the thread where we discussed in more detail. In the 4.0.4 MC deployer there is no link between beans and mbeans. It is the deployment (an MBean) that takes part in jmx dependencies. The only way to satisfy a dependency would be to add a "kludge" to the MC deployment descriptor (or use an alternate dds) that lets you express | <deployment> | <jmx-depends>jboss:server=something</jmx-depends> | which would then get added to the MC deployment's MBean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954325#3954325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954325 |
|
From: vickyk <do-...@jb...> - 2006-06-29 10:52:45
|
| // Call create on the service Proxy
| try
| {
| ctx.proxy.create();
| sequenceNo++;
| Notification createMsg = new Notification(ServiceMBean.CREATE_EVENT,
| this, sequenceNo);
| createMsg.setUserData(serviceName);
| sendNotification(createMsg);
| }
|
Above is the code snippet from the ServiceController .create(ObjectName serviceName , Collection depends) .
I am not able to understand
1) Who receives the Notification Message from the sendNotification(createMsg);
2) And how is this used ?
Some direction with reference to the code will be helpful .
Regards
Vicky
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954321#3954321
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954321
|
|
From: Markus.Schaefer <do-...@jb...> - 2006-06-29 10:03:29
|
I found a potential solution for that problem in a different context: http://jira.jboss.com/jira/browse/JBAS-2357 describes a workaround for a IndexOutOfBoundException in Tomcat on high request rates. (We encountered the problem running stress-tests on our system.) The solution is to set the following JVM-property when starting JBoss: -Dorg.jboss.security.SecurityAssociation.ThreadLocal=true This seems to solve the run-as-role problem described above as well! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954307#3954307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954307 |
|
From: oglueck <do-...@jb...> - 2006-06-29 09:34:29
|
In http://jboss.org/jbossBlog/blog/dimitris/?permalink=Clustered_Singletons_simplified.txt you state this works for MDBs only as of 4.0.4. I don't see why this should not work with 4.0.3 (but I have not tried). Could you explain? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954304#3954304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954304 |
|
From: <hei...@jb...> - 2006-06-29 09:07:00
|
anonymous wrote : This way we can avoid additional synchronisation... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954295#3954295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954295 |
|
From: <hei...@jb...> - 2006-06-29 09:05:51
|
Well, after the last improvement (LinkedList->ArrayList), it became evident that creating the reflection wrapper (getter, setter, field access) is the biggest bottleneck. I did some quick prototype, similiar to what you did with ClassInfo and FieldInfo and it turned out that performance increased significantly. IMO you are on the right way. Although i would suggest to cache this information per Marshaller/Unmarshaller instance and not statically/globally. This way we can additional synchronisation and it would still be possible for the callee to reuse particular instances per usecase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954293#3954293 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954293 |
|
From: gmeroz <do-...@jb...> - 2006-06-29 07:55:02
|
Jboss version: jboss-4.0.3SP1 JDK: sun jdk1.5.0_06 when there are no resources availible on the machine, the JBoss is shuted down unexpectedly. This is the error thrown: # # An unexpected error has been detected by HotSpot Virtual Machine # # Internal Error (4A41564123414C4C530E4350500018), pid=2572, tid=2304 # # Java VM Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # An error report file with more information is saved as hs_err_pid2572.log # # If you would like to submit a bug report, please visit i've seen related links in this forum, saying the CVS latest version may have solve it. Does anyone knows if it was solved and in which version? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954270#3954270 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954270 |
|
From: <ben...@jb...> - 2006-06-29 07:53:46
|
Manik, not sure if TransactionTable has it. But can the Cache SPI also expose the underlying transaction manager or the underlying tx if there is any? Use case in PojoCache is I need to know during attach or detach if there is ongoing tx. If not, I will need to start one for the batch processing purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954269#3954269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954269 |
|
From: <hei...@jb...> - 2006-06-29 07:46:27
|
I agree with thomas. Especially since our deployment problem doesn't exists anymore. I managed to tweak the eventing parts to lazily access the naming service. That means we can take our time and start looking at the mc2jmx bridge scott suggested. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954265#3954265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954265 |
|
From: pventurelli <do-...@jb...> - 2006-06-29 07:37:08
|
can i use the linux binary version or do I need to compile the native side of jboss profiler? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954257#3954257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954257 |