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: <max...@jb...> - 2005-05-26 12:07:24
|
this is a eclipse "feature" and bound to how your jvm works. I dont know of any JVM that can handle signature change such as add a method. It does support changing a method though. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879151#3879151 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879151 |
From: abhi954 <nu...@jb...> - 2005-05-26 10:39:37
|
Hi During debugging, whenever i make some changes in the code and compile them, an error pops up saying hot code replace failed - add method not implemented. i want to use hot code replace since a lot of effort is saved redeploying the application. I am using Eclipse 3.0.2 with jboss 3.2.3 integrated. Regards, Abhishek Bhargava View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879143#3879143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879143 |
From: <ovi...@jb...> - 2005-05-26 06:05:47
|
I am trying to consolidate discussions held on various threads about how to= implement transactional support. For simplicity, I would start with two si= mple use cases, and then work my way up from here: 1. Transactionally sending multiple NON_PERSISTENT messages 2. Transactionally receiving multiple NON_PERSISTENT messages 1. Transactionally sending multiple NON_PERSISTENT messages In this case we only care that our messages are atomically delivered to the= destination. The discussion does not include the processing of the ACKs ge= nerated by final consumers. The consumer-generated ACKs are handled the usu= al way. Once a session has been declared "transactional", there is always an active= transaction associated with it. All messages sent by session's Producers a= re automatically associated to this transaction and they keep accumulating = until the transaction is committed. Our current interceptor architecture al= lows us to keep these non-committed messages on the client or on the server= , depending on where we place the interceptor. An advantages of keeping non-committed messages on client is that we minimi= ze network traffic, as Tim pointed out earlier. The disadvantage is that we are in danger of running out of memory. Most li= kely we will have no control over client's memory and no access to storage = to spill messages to. For a long running transaction/big messages it is pos= sible to run out of memory. This is not a problem on the server side, where= supposedly we have access to external reliable storage to spill message to= , if we need it. It is also possible to combine these two approaches by transferring non-com= mitted messages from client to server once the amount of memory they use go= over a certain threshold.We should probably worry about this in the future= , but not now. I would suggest to start with the simplest approach: non-com= mitted messages accumulate on client. This is what JBossMQ does too. The in= terceptor should be written in such a way that it does not depend on anythi= ng client-specific, so we can later move it to the server if necessary. So, functionality we need so far is: - generate TxIDs and associate them with sessions; these TxID could be JTA = XIDs or something that we generate if no JTA transaction is available. Part= s of this is already available. - maintain a <TxID - unacked messages list> map. Parts of this is already a= vailable, as far as I know. - on transacted send() stop the invocation propagation and add the message = to the non-committed message list, instead of forwarding it to the server. - on commit() send non-committed messages in bulk to the server - on rollback() drop non-committed messages Once the non-committed messages arrive in bulk on the server, we need to ma= ke sure that either all of them are accepted by the destination, or none of= them is. JBossMQ handle this as follows: JMSDestinationManager receives the array co= ntaining non-committed messages and adds them to the destination (BasicQueu= e) one by one, within the scope of a transaction. It uses a org.jboss.mq.p= m.Tx for that. The destination first caches messages and only deals with me= ssage references. If the message is PERSISTENT, the queue transactionally p= ersists (TXID) in JMS_TRANSACTIONS and (MESSAGEID, DESTINATION, MESSAGEBLOB= , TXID, "A") in JMS_MESSAGES. This doesn't happen if the message is NON_PER= SISTENT. Finally, the queue registers AddMessagePostCommitTask/AddMessagePo= stRollbackTasks with the transaction. No message is delivered to the destin= ation at this stage yet. On commit, the persistence manager deletes from th= e database the messages corresponding to the current transaction that are m= arked "D" and the transaction itself and physically sends the messages to t= he destination, one by one, by running previously-registered AddMessagePost= RollbackTasks in a loop. An interesting question at this point would be what happens if one of the A= ddMessagePostCommitTasks fails. For NON_PERSISTENT messages, some of the me= ssages will be delivered to clients, and some won't. This situation is with= in the provisions of the spec, because NON_PERSISTENT messages may be lost. To summarize, BasicQueue is not transactional, but JMSDestinationManager en= forces a transactional behavior when uses it. In our case, we need to achieve a similar behavior when sending the bulk no= n-committed messages to the destination Receiver. I see several possibiliti= es: 1. Insert a transactional layer between SessionServerDelegate the target Re= ceiver. For NON_PERSISTENT messages, nothing goes to the database, the wrap= per only register something similar to AddMessagePostCommitTask/AddMessageP= ostRollbackTasks for each message with the local transaction manager. This = is the logging Adrian mentioned. On commit, messages will delivered one by = one in a loop to Receiver.handle(). Anything else than a positive acknowled= gment from the destination rolls back the transaction. 2. Subclass Receiver to provide this functionality. Write a new Transaction= alReceiver type that works with a transaction manager (and a MessageStore, = for persistent messages) to provide transactionality in a way that was desc= ribed above. If we do this with a XAResource we get 2PC wiring in there fro= m the beginning. 3. Add a new method boolean handle(Set) to Receiver. However, the implement= ation of the method must provide in a way or another the behavior that I've= described above. 2. Transactionally receiving multiple NON_PERSISTENT messages In this case, we only care about acknowledgments returning from the consumi= ng Session. The Session either acknowledges all received messages, or none. Positive ACKs keep accumulating until transaction commits. Same discussion = as where to accumulate them applies here as well. For the time being, let's= keep them on the client side. The interceptor that manages them should do = it in a way that that does not depend on anything client-specific. Additional functionality that we need is: - maintain a map <TxID - acknowledgments> - on transacted receive() add the acknowledgment to the acknowledgment list= , instead of sending it to the server - on commit() send acknowledgments in bulk to the server - on rollback() drop the acknowledgments; the server will eventually redeli= ver the corresponding messages. When the ACK set reaches the server, we have a similar situation: we need t= o make sure that either all of them are accepted by the Channel, or none of= them is. Whatever solution is chosen for messages could be also applied fo= r acknowledgments. View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv= iewtopic&p=3D3879122#3879122 Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin= g&mode=3Dreply&p=3D3879122 |
From: aows <nu...@jb...> - 2005-05-26 01:01:09
|
i don't have a windows box, but, does it install jboss as a service in windows? We have a product we are distributing with jboss... On my spare time i'm building an installer with izpack and the plan is to install jboss as a service... If your installer does it, i would like to see how, and if it doesn't well, i'll get around it and may be able to contribute that... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879115#3879115 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879115 |
From: <ad...@jb...> - 2005-05-26 00:46:41
|
Bug report: http://jira.jboss.com/jira/browse/JBAS-1850 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879112#3879112 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879112 |
From: ossiejnr <nu...@jb...> - 2005-05-26 00:44:42
|
Hi, I'm new to AOP and have been trying to get a sample running to add an interceptor when the java.io.PrintStream print() method is called. My jboss-aop.xml file contains this bind: <bind pointcut="call(* java.io.PrintStream->print(java.lang.String)) AND within(HelloAOP)"> | <interceptor class="HelloObjectInterceptor"/> | </bind> I then have an interceptor class which outputs some other info (to System.err). My main class then calls System.out.print but it doesn't appear to run the interceptor. I don't get any errors. Any ideas? Thanks Chris View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879110#3879110 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879110 |
From: <ad...@jb...> - 2005-05-26 00:28:42
|
"sco...@jb..." wrote : Ok, but you are talking about the correct way to do this in jb5. I need to do this in 4.0.3 so there is going to have to be some hacking like xmbean interceptors and a scripting framework. | | In terms of a configuration database, one of our current problems is that we mix configuration and definition. This can be factored out, and layered into defaults, server settings, domain settings, etc. I still don't know how this gets mapped to a command line or gui driven installation. For example using the jms service: | | - there is a security configuration and associated service | - there are one or more transport layers with additional dependencies on other services as in the case of http | - the choice of a persistence service can cascade to jca and a datasource configurations and services | - etc. | | At one extreme with a user driven install where every component needs to be customized to a setting different from the default views of the configuration and and wizard chains are needed. The other extreme is a testsuite target definition that simply lists the required services that are needed to procude a server install using the defaults. This testsuite usecase is what we need first. | Yes, it is not an easy problem. There are competing requirements between for example: * Just use my only configured DataSource you stupid *$%@ * Use this explicit DataSource, I want control!!!! At least those two extremes (monomorphorisms and explicitness) are well understood. Things inbetween can get very fuzzy :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879108#3879108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879108 |
From: <ad...@jb...> - 2005-05-26 00:24:37
|
I forget to add a comment... We are not just talking about an installer, we are talking about a consistent view/technology across ant/installer/testsuite/deployers/admin-console/web-console/jsr88/etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879107#3879107 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879107 |
From: erinol0 <nu...@jb...> - 2005-05-25 23:33:45
|
I noticed while setting up a XADataSource in JBoss 4.0.2 that properties with lowercase names propagate through to function calls (i.e. if you set a xa-datasource-property named port, an attempt is made to call setport, not setPort). I took a look in org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory, and I noticed that when setting properties, you just pull them off the list. Would it be reasonable to make sure that the first letter of the property name is a capital letter, or more reasonable to add a note to the dtd that the first letter is case sensitive? I know that this seems like a trivial point, but a bean accessor/mutator should never be lowercase for the first letter following "set" or "get" anyway. Thanks. Raj View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879103#3879103 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879103 |
From: <sco...@jb...> - 2005-05-25 23:20:48
|
Ok, but you are talking about the correct way to do this in jb5. I need to do this in 4.0.3 so there is going to have to be some hacking like xmbean interceptors and a scripting framework. In terms of a configuration database, one of our current problems is that we mix configuration and definition. This can be factored out, and layered into defaults, server settings, domain settings, etc. I still don't know how this gets mapped to a command line or gui driven installation. For example using the jms service: - there is a security configuration and associated service - there are one or more transport layers with additional dependencies on other services as in the case of http - the choice of a persistence service can cascade to jca and a datasource configurations and services - etc. At one extreme with a user driven install where every component needs to be customized to a setting different from the default views of the configuration and and wizard chains are needed. The other extreme is a testsuite target definition that simply lists the required services that are needed to procude a server install using the defaults. This testsuite usecase is what we need first. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879101#3879101 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879101 |
From: adamw <nu...@jb...> - 2005-05-25 22:31:48
|
Hello, the usual way of including a jsp page in the portlets output is: PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher("/WEB-INF/jsp/something.jsp"); rd.include(req, resp); But this enables me to read jsp's which are in the portlet's war. How can I read and include jsp's which are somewhere on my disk? I would like to put there an absolute path, for example. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879097#3879097 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879097 |
From: <tom...@jb...> - 2005-05-25 18:41:41
|
jBPM's persistence is done with a wrapper around a hibernate Session and SessionFactory. (the wrapped session contains the hibernate queries and things like that) the jBPM counterparts are called JbpmSessionFactory and JbpmSession. So i want to create a JBPMDeployer that puts the hibernate SessionFactory *and* the JbpmSessionFactory in JNDI. I wanted to reuse the HARDeployer as a base class of the JBPMDeployer to reuse (and not duplicate) the managed properties. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879073#3879073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879073 |
From: mikek753 <nu...@jb...> - 2005-05-25 18:39:34
|
bump any one has the same problem? or just I'm ... tnx View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879071#3879071 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879071 |
From: <ste...@jb...> - 2005-05-25 18:31:57
|
The reason I ask that is because, aside from the aut-detection, all the other stuff there can be done directly through Hibernate itself. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879069#3879069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879069 |
From: <ste...@jb...> - 2005-05-25 18:29:55
|
So if you are not using the "auto-detection" fecture, why exactly even use the HARDeployer? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879067#3879067 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879067 |
From: prasadgudipati <nu...@jb...> - 2005-05-25 17:46:34
|
Guys, Can the latest jobss be integrated with latest tomcat? i.e jboss 4.0.2 with tomcat 5.5.9? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879064#3879064 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879064 |
From: prasadgudipati <nu...@jb...> - 2005-05-25 17:44:31
|
Hi guys, What is the jboss and tomcat combination available in the market now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879063#3879063 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879063 |
From: <ad...@jb...> - 2005-05-25 16:44:12
|
And yes, acknowledgements must be persisted/logged as well. e.g. JBossMQ's JDBC2 does this by logically deleting the message TXOP="D" during the prepare and physically deleting it at commit. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879062#3879062 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879062 |
From: <ad...@jb...> - 2005-05-25 16:41:57
|
I've said it before, look at the JBossMQ implementation. This is how it should be done. It is call write ahead logging. Step 1 - Log the changes that are to be made (where messages are reliable) Step 2a - If everything ok, make the changes permenant Step 2b - otherwise, rollback any logged changes that were made For XA, steps 1 and 2 could be different server invocations (prepare/commit/rollback) under 2PC. The write ahead logging/persisting is a requirement (for JMS reliable messages) even if you don't have a transaction. When the send() method returns it *must* be guaranteed that the message is eventually delivered (even if that requires booting a different server from the log e.g. because the original server blew up :-). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879060#3879060 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879060 |
From: akommare <nu...@jb...> - 2005-05-25 16:21:25
|
Hi Scott, jbossweb-tomcat55.sar/jsf-libs/myfaces-impl.jar is not part of the downloadable 4.0.2 distribution. Do we need to get it from someplace else? Thanks - Anil. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879058#3879058 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879058 |
From: <ad...@jb...> - 2005-05-25 15:34:07
|
Forgetting the implementation details within JBoss for the moment. The issue for the build is to make available a "database" of configuration. This database should include something like: * The available components e.g. jms * The jars required to support the components e.g. jbossmq.jar * The mandatory config for a component e.g. jbossmq-service.xml * Optional/alternate config for a component (and the default) e.g. hsqldb-jdbc2-service.xml + alternates * Extra config/jars for a component e.g. jms over http requries the httpil servlet * The policies used by the component e.g. jms message cache should use a caching policy or memory config/info For JBoss5 I want to differentiate the generic idea like jms or jms persistence and the specific implementation like jbossmq or jdbc2 and also group components into something that can be easily referenced like "I want jms" rather than I want these five config files. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879053#3879053 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879053 |
From: <ad...@jb...> - 2005-05-25 15:22:35
|
"sco...@jb..." wrote : | 3. Some optional services need to be registered before others. The binding service and jsr77 service both operation as listeners of mbean registration events and need to be registered before any services that they should intercept. This is not a functional dependency that can be addressed with a depends tag. These services should really be custom interceptors on the SARDeployer. | The main issue here is a lack of support for cross-cutting in the current JMX kernel deployment, i.e. the ability to override/enhance deployments by adding advices to the deployment process. I don't like the XMBean interceptor approach, because it isn't really pluggable in terms of hot deployment or only including advices for services/policies that are deployed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879051#3879051 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879051 |
From: <ad...@jb...> - 2005-05-25 15:14:34
|
"ad...@jb..." wrote : More importantly, not all depdencies (some of which are really optional) | are explicitly declared | And I didn't mention the most obvious/pervasive one, which is JNDI. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879050#3879050 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879050 |
From: <ad...@jb...> - 2005-05-25 15:13:01
|
"sco...@jb..." wrote : | 2. The conf/jboss-service.xml has a number of services that significantly increase the minimal footprint. Either this needs to be stripped down to a minimal view (just the hot deployment service), or services that are candidates for static configuration would need a mbean descriptor artifact fragment to allow for inclusion into the conf/jboss-service.xml as part of the install. | The only reason conf/jboss-service.xml is not just the URLDeploymentScanner is because some default policies need to be set (like the RMI codebase needs to be set before JRMP is used) and more importantly, not all depdencies (some of which are really optional) are explicitly declared e.g. EJBs -> TM EJBs -> JCA EJBs -> DataSource EJBs -> JMS Invokers -> TM and similar for TC5 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879049#3879049 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879049 |
From: <ad...@jb...> - 2005-05-25 15:08:03
|
I'll answer each issue individually. We should probably fork off some issues into different threads otherwise the arguments will be unfollowable. "sco...@jb..." wrote : | 1. The current jars and descriptors are too monolithic. For the jars this means uneccessary size and dependencies. For the descriptors this means service configurations are combined that disallow finer grained installations | I couldn't agree more. anonymous wrote : | 4. Customization of the selected services is not a notion that exists in the current release build process. Post installation steps like configuring scoped classloading, call by value invocations, security, a custom datasource, enabling SSL, etc. are all configuration steps that would require the component artifacts to identify the configuration elements that should be transformed along with the variables availble. Something like velocity templatized descriptors along with supported varaibles would need to be declared. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3879047#3879047 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3879047 |