[Design of JBoss Build System] - maven.opts for building thirdparty module
by jaikiran
For building AS against the latest release of EJB3, we used to pass the maven.opts[1] param to bring in the latest released version:
./build.sh -Dmaven.opts="-Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0 -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0"
|
This works on 5_x branch where this maven.opts is being used. But doesn't work on AS trunk. I find no reference to this property in the AS build file. What is the equivalent property in AS trunk or how do we configure the build to pass these properties?
[1] It was thirparty.maven.opts at one point in time and then changed to maven.install.opts and now on 5_x branch is maven.opts.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237654#4237654
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237654
16 years, 7 months
[Design of JBoss ESB] - Re: Problems with transmitting content from ESB to jBPM via
by andreskusa
Hi Bernd,
thanks, that helped!
For all who are interested, here are some details of the solution:
The esbToBpmVars are read by jBPM like this
String esbToBpmXml = toEpr.getAddr().getExtensionValue(Constants.ESB_TO_BPM_VARS_TAG);
So, this variable needs to be set into the EPR of the Call-Object of the header.
And it should contain the XML code of the mappings that I put before into the properties of the jbpmCallback-Action, i.e.:
| <property name="esbToBpmVars">
| <mapping esb="messageContent" bpm="bpmMessageContent" />
| <mapping esb="settingsESB" bpm="bpmSettingsESB" />
| </property>
|
So, the setting of this variable looks finally like that:
| String esbToBpmVars = "<property name=\"esbToBpmVars\"> ";
| esbToBpmVars = esbToBpmVars + "<mapping esb=\"messageContent\" bpm=\"bpmMessageContent\" /> ";
| esbToBpmVars = esbToBpmVars + "<mapping esb=\"settingsESB\" bpm=\"bpmSettingsESB\" /> ";
| esbToBpmVars = esbToBpmVars + "</property> ";
|
| PortReference portReference = replyTo.getAddr();
| portReference.addExtension(Constants.ESB_TO_BPM_VARS_TAG, esbToBpmVars);
| message.getHeader().getCall().setTo(replyTo);
|
Cheers,
Andre Skusa, Wincor Nixdorf, Germany
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237641#4237641
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237641
16 years, 7 months
[Design the new POJO MicroContainer] - Re: MC tools
by alesj
"flavia.rainone(a)jboss.com" wrote :
| But, of course, I can't change the meta data classes, adding a method that generates the XML form of each one of them. So, how can I get rid of my if instanceof statements and still generate proper XML for every meta data type?
|
| I guess I missed what you're trying to tell me. So, please, elaborate :)
I don't know the name of the pattern, but it's trivial to do it. ;-)
Instead of changing the classes, you can write proper adapters / delegates.
e.g. (pseudo code)
| // T --> SMD side metadata type; e.g. ServiceInjectionValueMetaData
| // U --> BMD side metadata type; e.g. AbstractInjectionValueMetaData
| interface SMD2BMD<T, U>
| {
| Class<T> mappingClass();
|
| U toBMD(T t);
|
| String toXML(U u);
| }
|
Where now instead of multiple ifs, you would simply do something like this:
| Map<?, ?> adapters = ...;
| SMD2BMD s2b = adapters.get(smd.getClass());
| if (s2b == null)
| {
| // no exact mapping class match, lets iterate
| for (Class key : adapters.keySet())
| {
| if (key.isInstance(smd))
| {
| s2b = adapters.get(key);
| break;
| }
| }
| if (s2b == null)
| throw new IllegalArgumentException("No such mapping " + smd);
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237634#4237634
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237634
16 years, 7 months
[Design the new POJO MicroContainer] - JBKERNEL-36
by jaikiran
Moving our mail discussion to the forum
"kabir" wrote :
| Hi Ales,
|
| Please see my comment here: https://jira.jboss.org/jira/browse/JBKERNEL-36
|
|
"jaikiran" wrote :
| Hi Kabir,
|
| Which retrieval stores the ComponentMetaData by MethodSignatures? I tried to find them but could not. And shouldn't those retrievals be storing the CMD by Signature (instead of MethodSignature or DeclaredMethodSignature), since the contract with the retrieval is established through a Signature:
|
| MetaDataRetrieval getComponentMetaDataRetrieval(Signature signature);
|
|
"kabir" wrote :
| I don't know what puts them there, but if you put a breakpoint in AOPConstructorJoinpoint and then run for example aop-mc-int/MetaDataTestCase you will see that the MemoryMetaDataLoader internally stores all the component metadatas keyed by MethodSignature - these are for methods, so it is probably keyed by Signature like you say since constructors/fields would probably use their appropriate Signature impl.
|
| The problem with your suggested fix was that DeclaredMethodSignature and MethodSignature did not match on equals() and hashCode(), something I fixed in my commit for https://jira.jboss.org/jira/browse/JBMDR-57. So in the MemoryMetaDataLoader if you had a ComponentMetaDataRetrieval with an entry for MethodSignature(getIntProperty()), when you try to look up the ComponentMetaDataRetrieval pasing in a DeclaredMethodSignature(PropertyBean.getIntProperty()) the ComponentMetaDataRetrieval would not be found.
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237617#4237617
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237617
16 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - native-src in kit
by gaohoward
i built a distro, and blindly try the native-src according to the README. When I ran bootstrap, I got following error in ubuntu:
$ chmod +x bootstrap
$ ./bootstrap
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 186.
Use of uninitialized value $libtoolize in pattern match (m//) at /usr/bin/autoreconf line 186.
configure.ac:47: error: possibly undefined macro: AC_DISABLE_STATIC
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:48: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: /usr/bin/autoconf failed with exit status: 1
configure: error: cannot find install-sh or install.sh in build-aux "."/build-aux
make: *** No targets specified and no makefile found. Stop.
ant in fedora 10, I get a succssful build. But the .so file is not in the path specified in readme.
It's under ./src/.libs , not ./native/src/.libs/
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237602#4237602
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237602
16 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Still some examples fail
by gaohoward
Also sometimes I got another failure with symmetric:
[java] JBMServer err:17:15:15,641 WARNING [org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Channel disconnected:2
[java] JBMServer err:17:15:15,963 SEVERE [org.jboss.messaging.core.server.impl.MessagingServerPacketHandler] Failed to reattach session
[java] JBMServer err:java.lang.IllegalStateException: More than one replicating connection!
[java] JBMServer err: at org.jboss.messaging.core.server.impl.MessagingServerImpl.freezeBackupConnection(MessagingServerImpl.java:843)
[java] JBMServer err: at org.jboss.messaging.core.server.impl.MessagingServerImpl.checkActivate(MessagingServerImpl.java:788)
[java] JBMServer err: at org.jboss.messaging.core.server.impl.MessagingServerImpl.reattachSession(MessagingServerImpl.java:480)
[java] JBMServer err: at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handleReattachSession(MessagingServerPacketHandler.java:298)
[java] JBMServer err: at org.jboss.messaging.core.server.impl.MessagingServerPacketHandler.handlePacket(MessagingServerPacketHandler.java:128)
[java] JBMServer err: at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1562)
[java] JBMServer err: at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$400(RemotingConnectionImpl.java:887)
[java] JBMServer err: at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:488)
[java] JBMServer err: at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:570)
[java] JBMServer err: at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
[java] JBMServer err: at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
[java] JBMServer err: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
[java] JBMServer err: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
[java] JBMServer err: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:387)
[java] JBMServer err: at org.jboss.netty.handler.codec.frame.FrameDecoder.fireMessageReceived(FrameDecoder.java:284)
[java] JBMServer err: at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:261)
[java] JBMServer err: at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
[java] JBMServer err: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
[java] JBMServer err: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
[java] JBMServer err: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
[java] JBMServer err: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
[java] JBMServer err: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
[java] JBMServer err: at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
[java] JBMServer err: at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
[java] JBMServer err: at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
[java] JBMServer err: at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
[java] JBMServer err: at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
[java] JBMServer err: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
[java] JBMServer err: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
[java] JBMServer err: at java.lang.Thread.run(Thread.java:595)
......
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237589#4237589
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237589
16 years, 7 months