July 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Collaboration Server] - Re: Setup JBoss Collaboration Server on Solaris with non-gui

by gohip＠ichibancomputers.com

did you get it varamthanapon? I.e. the setup working on Solaris? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957438#3957438 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957438

19 years, 9 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: Collaboration other services?

by gohip＠ichibancomputers.com

I'm sure Andrew and all, would be ecstatic if you submitted a chat/IM patch ;) It would be easy to implement SMS(possibly also MMS), I have already dealt with the java SMSLibrary, and it would not be hard to "plug it in". The only thing holding anyone back from doing so is that to SMS to users, you'd have to have a GSM Modem, a mobile device wiredto server, or go through one of the SMS service aggregators, several of which, have Java Libraries. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957437#3957437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957437

19 years, 9 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Quartz, timer unification, message inflow RAR

by weston.price＠jboss.com

anonymous wrote : | The idea of this RAR is that it is portable to *ANY Java EE Vendor*. | Of course it is. That's what a RAR is, that's what a RAR gives you. anonymous wrote : | All this RAR is a simpler User API for using Quartz so that a quartz job can post to an MDB. Nothing more. | Ok, that's fine. Again, and this probably should have been a seperate threaad, but all I was saying is that the JIRA task: http://jira.jboss.org/jira/browse/JBAS-3206 should be pushed back from the 4.0.5 release. Again, this was in response to QA requesting that all non-critical tasks be moved so we can focus on 5.0. anonymous wrote : | Yes, it is bare bones, but it works. And, it is documented somewhat as a EJB3 tutorial. | Ok. Did you let anyone know about these tests, the documentation for the adapter? I don't regularly peruse the EJB3 project, so, I am not sure how I would have known this unless you posted this somewhere. If you feel these test are adequate for the 4.0.x release, so be it. anonymous wrote : | To be honest, since all you guys have been assholes about this crap, then do whatever the hell you want. I seriously don't care anymore. | Sorry you feel that way, but unfortunately the Quartz RAR was checked into the connector project, not in varia, not in EJB3. Believe me, if I could make it go away, I would. However, it ended up 'appearing' right before a 4.0.4 release, and was tentativly slated for the next 4.0.5 release. Again, this is *NOT* about getting rid fo the RAR no matter how much you want to make it look like that. It is about pushing back the task of getting it production ready to a later release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957430#3957430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957430

19 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Use of Throwable in method signatures

by scott.stark＠jboss.org

The Throwable just results in is a boilerplate code block like the following that does not actually require handling of the runtime errors: | try | { | kernelDeployer = new BasicXMLDeployer(context.getKernel()); | } | catch(Error e) | { | throw e; | } | catch(Exception e) | { | throw e; | } | catch(Throwable e) | { | // Should not happen | throw new Exception("Failed to create BasicXMLDeployer", e); | } | This still does not really solve the problem you are after as I have ignored the runtime exceptions/errors as before. It seems what we really need is a KernelAction wrapper similar to a PriviledgedAction that integrates with the caller's kernel state to ensure exceptions are properly reflected in the state machine. I don't see how to force use of this though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957429#3957429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957429

19 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Asynchronous acknowledgements

by timfox

"adrian(a)jboss.org" wrote : You must have some notion of NACKs, otherwise how do you handle | all the cases that need redeliveries? | | e.g. An error during a message listener | The spec says that for auto ack or dups_ok then the same message must be redelivered immediately. No need to send anything to the server here since we already have the message on the client and we just retry the onMessage method up to a maximum number of times. anonymous wrote : | e.g.2. Closing a CLIENT_ACKNOWLEDGE session without | acknowledging the messages | In this case when the sesssion closes, the server gets the "close session" invocation and knows which messages have been sent to the session but not acked so it just nacks (cancels) them back to the queue. No need to send a nack for each message from client to server. anonymous wrote : | e.g.3. closing the receiver there is a race condition | on the server delivering a message | | receiver -> I want a message | server -> there is none, just wait | sender -> send message | server -> queue delivery of message | receiver -> close() | delivery -> Oh! The receiver has vanished -> NACK! | Right. In this case we send a nack from client to server. In messaging terminology we call it a "cancel" :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957428#3957428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957428

19 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: VFSDeploymentScanner questions

by scott.stark＠jboss.org

I don't see why the hot deployment notion cannot be the baseline tool for deployment, and still have integration with the ProfileService. My concern with regard to leaving the hot deployment notion as something completely separate from the ProfileService is that it won't be used. If we wan't a similar prod compatible ease of use deployment, at least for single node systems, there will have to be some service that integrates hot deployment type of additions to the ProfileService. As far as I can see the only reason not to look at building the hot deployment service on top of the ProfileService would be the additional time it takes to complete an initial implementation. I can create a MainDeployer based implementation as a starting point to allow jboss5 to get to the point of deploying the existing configurations and look at an alternate implementation independently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957426#3957426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957426

19 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Does JBoss port of phpBB support attachments?

by julien＠jboss.com

this forum is not the one based on JBoss Portal, it's an old old one (nukes) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957422#3957422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957422

19 years, 9 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Quartz, timer unification, message inflow RAR

by bill.burke＠jboss.com

"weston.price(a)jboss.com" wrote : Unless you feel it is adequately tested and documented and can be included in the 4.0.5 release. I have yet to hear anything on the subject from you. | | I for one am not thrilled with a ResourceAdapter that, regardless of whether there are any deployed endpoints or not, decides to fire up a default scheduler. A scheduler that is | | a) Undocumented | | b) Could conflict with any existing schedulers that people may be running in previous release | | c) Consumes resources without even an attempt to be integrated with our existing thread pools etc, etc | | I mean really dude, you are treating this RAR as the 'holy grail' of Timer integration when all it really does, stupidly might I add, is register an MDB listener for a single Quartz job. So I guess if I am intersted in listening to say...3 jobs...do I need 3 endpoints? How about 10? What if I never deploy an endpoint at all...do I still want the Scheduler up and running....doing nothing but showing up in a ThreadDump. | | How about support, have they been told about the adapter and what it means when it starts showing up in profiling info or clients, god forbid, actually try and use it? | | At the very least, I think for 4.0.5, the RAR should go in the docs directory giving the client a choice if they want to deploy the adapter or not. | | You are not listening to me. I'm not looking for this to be the "holy grail" for Timers. I just want it available as an optional Quartz deployment mechanism and integration with MDB. That RAR *IS NOT*, I repeat *IS NOT* the basis for any Timer integration. All this RAR is a simpler User API for using Quartz so that a quartz job can post to an MDB. Nothing more. | <ejb-jar> | <message-driven> | <ejb-class>my.specific.job.class</ejb-class> | <activation-spec> | <name>Cron</name> | <value>1 2 * * * 4/5</value> | </activation-spec> | </message-driven> | </ejb-jar> | The idea of this RAR is that it is portable to *ANY Java EE Vendor*. Yes, it is bare bones, but it works. And, it is documented somewhat as a EJB3 tutorial. To be honest, since all you guys have been assholes about this crap, then do whatever the hell you want. I seriously don't care anymore. Bill View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957417#3957417 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957417

19 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Asynchronous acknowledgements

by adrian＠jboss.org

For some simple examples, look at org.jboss.test.jbossmq.test.UnackedUnitTestCase View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957411#3957411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957411

19 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Asynchronous acknowledgements

by adrian＠jboss.org

You must have some notion of NACKs, otherwise how do you handle all the cases that need redeliveries? e.g. An error during a message listener e.g.2. Closing a CLIENT_ACKNOWLEDGE session without acknowledging the messages e.g.3. closing the receiver there is a race condition on the server delivering a message receiver -> I want a message server -> there is none, just wait sender -> send message server -> queue delivery of message receiver -> close() delivery -> Oh! The receiver has vanished -> NACK! etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957409#3957409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957409

19 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2006