May 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Graphic Installer for Messaging

by clebert.suconic＠jboss.com

That's why I was looking into this. Since this setup is using our release-admin.xml, I wanted to look at how this would work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043779#4043779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043779

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Graphic Installer for Messaging

by vladimir.ralev＠jboss.com

We started working on AS 4.2 installer in the trunk and the payload is not available online right now. The installer mentioned earlier was for 4.0.5. You can check out revision 693 of the trunk if you want to build it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043777#4043777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043777

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Graphic Installer for Messaging

by timfox

The installer needs to be changed anyway (from 1.2.0.sp2) since we won't be doing scoped deployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043773#4043773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043773

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Graphic Installer for Messaging

by clebert.suconic＠jboss.com

Vladimir... I was trying to use this setup.. and the build is not working now. I tried to fix it.. but I didn't understand how this works... Can you take a look real quick on what's going on? Also.. would be possible to have this setup working on trunk? I mean.. it would be really nice to give the user the option if he wanst JBossMQ or JBossMessaging on JEMS setup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043772#4043772 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043772

17 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Original file name as message property for File/FTP gateways

by derek.adams

I have some code that adds the originating filename as a property on messages coming from file or FTP gateways. In our business case, we needed to be able to take the original filename, modify it with a timestamp and use that as the filename on an outgoing FTP. Our solution was an action that executes a chain of strategies on the incoming filename, passing the end result to a NotifyFTP action. The config looks like this... | <jbossesb parameterReloadSecs="5" xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."> | <providers> | <jms-provider name="JBossMQ" connection-factory="ConnectionFactory" jndi-URL="localhost"> | <jms-bus busid="MyESBChannel"> | <jms-message-filter dest-name="queue/A" dest-type="QUEUE"/> | </jms-bus> | </jms-provider> | <fs-provider name="MyFileProvider"> | <fs-bus busid="MyFileBus"> | <fs-message-filter directory="/temp" input-suffix=".esbdat" work-suffix=".esbInProcess" post-delete="true" | post-directory="processed" post-suffix=".esbDone" error-delete="true" error-directory="processed" error-suffix=".esbERROR"/> | </fs-bus> | </fs-provider> | <ftp-provider name="MyFtpProvider" hostname="localhost"> | <ftp-bus busid="MyFtpBus"> | <ftp-message-filter directory="/" username="anonymous" password="none" input-suffix=".esbdat" work-suffix=".esbInProcess" | post-delete="true" post-directory="processed" post-suffix=".esbDone" error-delete="true" error-directory="processed" | error-suffix=".esbERROR" passive="false" protocol="ftp"/> | </ftp-bus> | </ftp-provider> | </providers> | <services> | <service category="FirstServiceESB" name="SimpleListener" description="Hello World"> | <listeners> | <fs-listener name="InFromFile" busidref="MyFileBus" maxThreads="1" is-gateway="true" poll-frequency-seconds="3"/> | <ftp-listener name="InFromFTP" busidref="MyFtpBus" maxThreads="1" is-gateway="true" poll-frequency-seconds="8"/> | <jms-listener name="EsbListener" busidref="MyESBChannel" maxThreads="1" is-gateway="false"/> | </listeners> | <actions> | <action name="BuildFilename" class="org.jboss.soa.esb.actions.naming.FileNameGeneratorAction"> | <property name="strategies" value=""> | <strategies> | <strategy class="org.jboss.soa.esb.actions.naming.strategy.ChangeSuffixNamingStrategy" newSuffix="proc"/> | <strategy class="org.jboss.soa.esb.actions.naming.strategy.AddTimestampNamingStrategy"/> | </strategies> | </property> | </action> | <action name="SendToFTP" class="org.jboss.soa.esb.actions.Notifier"> | <property name="okMethod" value="notifyOK"/> | <property name="notification-details" value=""> | <NotificationList type="OK"> | <target class="NotifyFTP"> | <ftp URL="ftp://user:password@server.com/home/user" filename="{org.jboss.soa.esb.naming.result}"/> | </target> | </NotificationList> | </property> | </action> | </actions> | </service> | </services> | </jbossesb> The FileNameGeneratorAction uses the message property for originating filename set in the gateway by default (can be changed via action props) and writes the result to a well-known message prop name. The NotifyFTP action picks up the result value and uses that as the filename it writes. I figure that this may be helpful to other people with similar requirements, so I was wondering if I should check the code in. Alternatively, I can add a JIRA and attach the updates so people can take a look before it goes in the trunk. Thanks, Derek View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043770#4043770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043770

17 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Cluster Aware Cache Policy for the Jaas Security Manager

by anil.saldhana＠jboss.com

Stefan, u r on the right track. The cluster aware cache policy should not be the default. Only customers needing it will configure it. I will take a more detailed look at your description and get back to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043737#4043737 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043737

17 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler On Solaris

by clebert.suconic＠jboss.com

Let me know if the Solaris instructions aren't helpful. also... in your parameters: -XrunjbossInspector:/export/home/jboss/jboss-profiler-1.0.CR4,include=com.magti,start=org.jboss the include is saying.. the only classes you want to analyze are com.magti... you don't want to look at anything else. The start is saying... on a thread... only start capturing when you have a class of org.jboss on the stack trace. I would try the plain parameter first, like: -XrunjbossInspector:/export/home/jboss/jboss-profiler-1.0.CR4 And filter out stuff later after you got your first report. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043682#4043682 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043682

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Identity module constraint needed

by david.lloyd＠jboss.com

"david.lloyd(a)jboss.com" wrote : It looks to me like there ought to be a unique constraint across either the GROUP_ and ROLE_ columns or just the GROUP_ column within the identity JBPM_ID_MEMBERSHIP table. I misstated - I mean across USER_, GROUP_, and ROLE_, or just USER_ and GROUP_. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043668#4043668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043668

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Identity module constraint needed

by david.lloyd＠jboss.com

It looks to me like there ought to be a unique constraint across either the GROUP_ and ROLE_ columns or just the GROUP_ column within the identity JBPM_ID_MEMBERSHIP table. The effect would be to prevent a user from being in the same group more than one time, or barring that, require that each membership within the same group has a unique role. Agree/disagree? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043667#4043667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043667

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: including graphical information in the process definitio

by estaub

David, anonymous wrote : I disagree - it's XML, and XML doesn't exist for human consumption. Ideally true, but in practice, there's currently no alternative to reading the XML if you need to see both the big picture and some details at the same time. A good example might be to consider the case where you're reading a process definition and want to understand the data flow through the process variables. Do you want to click on every node to see where each variable is used? How much longer would that take than searching the XML? Would you be willing to do two or three passes, looking for different details each time, as you might if you were searching the XML? If you had to open a dialog box for every node, how would your memory retention compare with doing a search through the XML? I think it will be at least two years, if ever, before GPD is at a level where reading the XML isn't really necessary. anonymous wrote : If you're using the GPD, then you shouldn't need to hand-edit the XML anyway. | Agreed, assuming the usability is good in all cases. But my concern is about reading, not writing. By way of analogy, imagine if you were using some UML-based code editor, and the only way it allowed you to see the source file was in a very modal fashion. You could navigate to a method and open it, but you couldn't scroll through the source. What would this do to your ability to see the big picture? If you ever tried VisualAge For Java, you've seen this. anonymous wrote : I don't find it at all confusing to mix that information as illustrated above - using Facelets you do that all the time, sometimes with as many as 10 or more namespaces. | Given the overall goals of the project, I think the bar probably should be higher than "not confusing". The current schema is about as easy to read as it could possible be, and I think that, if possible, it should stay that way until GPD is far more advanced than it is now. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043661#4043661 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043661

17 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2007