We have a generic logging framework that ships as part of JBossTS, though it isn't tied to it. It interfaces with all of the logging implementations and provides support for I18N/L10N compatibility. There's actually a JIRA task for that already.
I don't have a strong preference. But I know this framework works and users have been able to plug in their own (proprietary) logging implementations without affecting the system (TS in this case). I'd suggest at least giving it a look. My intention was to use it for the first GA (or maybe the 2nd). In the meantime, log4j is probably good enough for us.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961695#3961695
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961695
Messages need to be delivered to the message listeners of a session in a serial order.
Currently we are implementing this by the session maintaining a EDU.oswego.cs.dl.util.QueuedExecutor which queues up deliveries for listeners in the session.
The QueuedExecutor maintains it's own thread which excecutes Runnables from the queue, one by one.
I would like to avoid maintaining a thread per session, and be able to execute the Runnables using a global pool, but still maintaining serial order on a per session basis.
This could be done by maintaining a queue per session, but actually executing the Runnables on a thread from this global pool.
I'd like to avoid writing this class myself, but I can't see how I can use the Doug Lea concurrent classes to do this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961681#3961681
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961681
Thanks for your quick and detailed response!
"max.andersen(a)jboss.com" wrote :
| Gavin is busy doing other things; so feel free to attack it ;)
Gee, I was hoping it was all done for us ;-)
"max.andersen(a)jboss.com" wrote :
| of course. Just need someone to step up and contribute ;)
I'm catching your drift.... let me see if I can carve out some cycles within the intensity of my current projects, and take a closer look at what I can contribute.
I grabbed 2.0.0.Alpha1a recently, and will sometime soon be checking to see if there are any current rev-eng/generator/template compatibility problems vis-a-vis Seam 1.0.1.GA &/or the JEMS installer 1.2.0's portal profile.
I really would like to do the full FreeMarker template set for a Facelets version.
(+ an early call for collaborators: if any Hibernate gurus have sample java or jsp source chunks they can post on this thread for what would be the optimal generated output in terms of working with composite keys and recursive associations, I'd be happy to convert and merge them into FreeMarker templates for generating the Facelets xhtml and the backing EJB3 Session bean.)
anonymous wrote :
| Great to see you back - and I hope you find time to contribute :)
Thanks for the warm welcome again, and while it won't be this week, I'll definitely be back in touch on this thread with detailed replies to each of yours.
-- Howard "hxp" Pearlmutter
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961675#3961675
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961675
I remember playing with something like this..
The other way around would be to configure the JMS (Destination Mngr)to protected by the same realm as JBCS. This way the user would have an authernticated, and have authorization to publish.
That I partially know( and there was some beer in the conversation) to configure the some realm hierarchy, and make the JMS accept JBCS realm authenticaed users.
In both case I think this would be:
- invasive and complex.
- but still much more elegant than usernames/passwords all over config files.
The main idea is that if you have access to the publish codebase why not use the JAAS that is already there vs trick with semi-secret passwords.
+ password maintance would be really painfull.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961669#3961669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961669
I just remove all the invokers except for the JVM invoker. I don't see the type of security you mention to be generically useful enough to incorporate it as it would complicate security pretty dramatically. Besides you'd have to store the user/password for the mail listener locally anyway and if anyone has the abillity to deploy an app then they presumably have the abillity to get at that password. I'm not 100% against it if you can demonstrate it in a non-invasive generically useful way...but this seems like a special requirement and I don't see a great deal of non-perception-only security added by it... Maybe I'm wrong...but I don't see it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961659#3961659
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961659