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

[Design of JBoss ESB] - Re: General message receive functionality

by derry

"mark.little(a)jboss.com" wrote : It would be interesting to discuss this further, but our roadmap for our first GA release is quite tight, so you would probably have to put up with some periods of silence from us during the conversations. Best place for them would be in this forum though. Don't worry Mark. This is an application that should run on top of JBossESB and other JBoss services, I think. So it is more a sub-project to JBossESB. I can put together some more thoughts in this forum the next days. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978803#3978803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978803

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: API Issues integrating 2.0.0.DR1 in HEAD

by manik.surtani＠jboss.com

anonymous wrote : | 3) Let's expose the TransactionManager as a Configuration property. In the session repl case, the cache is using special transaction manager. The session repl code needs to get it so it can control the tx. For other use cases, if the environment (like JBoss AS) supports it why not dependency inject the TM into the cache rather using a TransactionManagerLookup? TransactionManagerLookup becomes a fallback for cases where we can't dependency inject. | * What callback do I need to provide for the DI from the MC? * The TM can be retrieved using the CacheSPI, again perhaps this could be downgraded to be accessible from Cache. Accessing this from the Configuration doesn't make much sense since the Configuration should be a valid, testable and checkable object even when the cache is not running while the TM is a resource that should only be available when the cache is running. anonymous wrote : | 4) Can we restore Node.getChildrenNames()? Iterating through the child collection and calling getFqn().getName() on each node is a pain. | I agree - will do. anonymous wrote : | 5) Why is Node.getChildren() a Collection and not a Set? I expect it's because Map.getValues() is a Collection, but properly this method should return Set. | You guessed why. :-) Does it make more sense as a Set? I suppose so, since only one instance of each child would exist. I'd need to think of an efficient way to do this though, as iterating and creating a new set every time getChildren() is called is sub-optimal. anonymous wrote : | 6) The Node interface desribes various returned Collections as being immutable. From a glance at NodeImpl it looks like they aren't. Also, it would be good to be more clear about thread safety as immutable and thread safe aren't the same. | Which ones aren't? I may have missed some. The point is not for thread safety, but so changes go through the Node or Cache API and hence the interceptor stack. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978801#3978801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978801

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: API Issues integrating 2.0.0.DR1 in HEAD

by manik.surtani＠jboss.com

anonymous wrote : | 1) How do you set an Option? I thought there was an InvocationContext.currentContext() or something. Doesn't seem to be. Only thing I see is a getter/setter in CacheSPI, but my code shouldn't need CacheSPI. | I did do InvocationContext.currentContext() for a while, but ran into problems when using multiple cache instances in the same JVM and thread. You would now have to do CacheSPI.getInvocationContext(), although I see your point about your not needing to use this interface. It is a bit heavy for the Cache interface though. Any other thoughts, otherwise I fear it would just have to be in Cache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978800#3978800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978800

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Documenting Limitations of FileCacheLoader

by manik.surtani＠jboss.com

Not just NFS, but most shared file systems including SMB do not have a proper notion of file locks (perhaps RHAT's GFS may be different). And Galder is right, FCL is not performant for large trees since this involves directory traversal, but then again I'm sure this depends on the file system used (ext3 vs reiserfs vs Windows NTFS, etc). To be honest, I tend to recommend not using this at all in production. I think a much better bet would be the JDBM cache loader, which is pretty poorly documented at the moment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978798#3978798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978798

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.1.3 release

by tom.baeyens＠jboss.com

we're trying to get it out the door. we should be able to get it through in the next few days. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978795#3978795 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978795

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - jBPM 3.1.3 release

by erlaan

Hi, Does anybody know when jBPM 3.1.3 will be release? I need to deploy jBPM on JBoss 4.0.4 and there is an ecache version conflict that is solved in jBPM 3.1.3. Thx, Ernst-Jan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978794#3978794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978794

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: eclipse classpath for examples

by tom.baeyens＠jboss.com

ideally the ant target will have a classpath target that is used to set the classpath for compiling and executing the examples. that target could also check if all the libs are present and if not, display an appropriate error message or start the download automatically View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978792#3978792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978792

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - ESB Message Store

by daniel.brum＠jboss.com

The code is now checked in for the general Message Store implementation for the ESB - replacing the old Rosetta Object Store (still there for now until we can remove it along with other changes) Very simple to use - you can see full test cases in org.jboss.soa.esb.esb.persistence.tests.MessageStoreUnitTest The design calls for a "service" implementation similar to what has already been done In the Message service (factory) - right now the only Message Store we have is a relational database persistence store. Someone could put in a file based Message Store if they wish, or something else. Getting a handle to the store: MessageStore store = MessageStoreFactory.getInstance().getMessageStore(MessageStoreType.DATABASE); | The Interface for now is simple: | public String addMessage(Message message); | public Message getMessage(String uid); *this might change to take in a jave.net.URI following the convention Mark uses throughout his code. The Message Store is for now, only useful for audit purposes. It will persist Message objects into a database. DB Schema's can be found under the {esb_home}/product/install/message-store/sql/ - It's a very simple table with 3 columns: uid, type, text. We can add more info if we need to later. For Unit Tests, I used Kurt's hypersonic util class for starting and loading a schema at each run. The one big change from how the persistence worked before vs. the new way is that this store is targeted to be an audit store, not an object store like we used in Rosetta. In the Rosetta way, we could effectively use the persistence DB to give us object persistence, lookup, update, a usable domain model if we wanted to, which is what I did in the TrailBlazer, using it to update Quote Requests into the store. That is no longer the case. This store is purely for audit trail right now. Hence why the new TrailBlazer will be totally different in the next iteration. You will need to update your jboss-properties.xml (install/conf) with your DB properties. For Unit Testing, you should be ok as I set it up to use HSQLDB. Expect some minor tweaking and javadoc/documentation over the next couple of days. If you get a chance to play around with this, your feedback would be appreciated, especially with the Apache DBCP pooling stuff. One change we could add is allowing the developer when deploying the ESB to choose a J2EE datasource connection, allowing use of that pool instead of the standalone dbcp. Will also be adding more Q/A tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978791#3978791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978791

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Why the JBoss-portal conflict with EJB3 in "all" model ?

by huishuai

I install "jboss-4.0.4.GA-Patch1-installer.jar" into "d:\jboss" folder, and I put "jboss-portal.sar" into "D:\jboss\server\all\deploy" folder, "EJB3" can work, but "portal" can't work, and I got message following, why ? HTTP Status 500 - -------------------------------------------------------------------------------- type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.IllegalStateException: Cannot get portal server org.jboss.portal.server.servlet.PortalServlet.getServer(PortalServlet.java:123) org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:272) org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172) javax.servlet.http.HttpServlet.service(HttpServlet.java:697) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs. -------------------------------------------------------------------------------- Apache Tomcat/5.5.17 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978789#3978789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978789

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redep

by thomas.diesler＠jboss.com

I think we can safely postpone this issue until the complete set of metadata is available in WebMetaData. A possible workaround is not to use exploded wars with jsr181 endpoints. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978780#3978780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978780

19 years, 5 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 October 2006