[JBoss ESB Development] - Re: Supporting entry-point
by jeffdelong
A couple things I wanted to bring over from and email thread:
1) We should add ESB exitPoint handling out-of-the-box that is declared in the ESB service configuration and has similar object mapping as the entry points. Basically it would take the object inserted into the exit point, create a new ESBMessage, copy the object into the ESB Message based on the exit point configuration, and send the ESB message to a configured "destination" (similar to CBR).
2) Is the BusinessRulesProcessor able to be configured for "StreamMode"? Most CEP applications will require StreamMode to enable sliding window support, garbage collection of expired facts, etc. This is really important (a necessity), and is turned on through the API.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251942#4251942
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251942
15 years, 4 months
[Embedded JBoss Development] - Re: Archive Conversion Design Descussion
by johnbailey
I agree. I have taken some of the prototyping and implemented an ZipExporter as described. The example below demonstrates the usage.
| @Test
| public void testExportZip() throws Exception
| {
| // Get an archive instance
| MemoryMapArchive archive = new MemoryMapArchiveImpl("testArchive.jar");
|
| // Add some content
| Asset assetOne = new ClassLoaderAsset("org/jboss/declarchive/impl/base/asset/Test.properties");
| Path pathOne = new BasicPath("test.properties");
| archive.add(pathOne, assetOne);
| Asset assetTwo = new ClassLoaderAsset("org/jboss/declarchive/impl/base/asset/Test2.properties");
| Path pathTwo = new BasicPath("nested", "test2.properties");
| archive.add(pathTwo, assetTwo);
|
| // Export as Zip InputStream
| InputStream zipStream = ZipExporter.exportZip(archive);
|
| // Validate the InputStream was created
| Assert.assertNotNull(zipStream);
|
| // Create a temp file
| File outFile = File.createTempFile("test", ".zip");
| // Write Zip contents to file
| writeOutFile(outFile, zipStream);
|
| // Use standard ZipFile library to read in written Zip file
| ZipFile expectedZip = new ZipFile(outFile);
|
| // Validate first entry
| assertAssetInZip(expectedZip, pathOne, assetOne);
| assertAssetInZip(expectedZip, pathTwo, assetTwo);
|
| }
|
I will continue to work on the ExplodedExporter as well.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251931#4251931
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251931
15 years, 4 months
[Embedded JBoss Development] - Re: Archive Conversion Design Descussion
by ALRubinger
"johnbailey" wrote : 1. Change the internal storage archive of an existing container archive (this seems like the primary use case):
I think this is the only case we need to be concerned with at this point. If even that.
I hate to throw a wrench in this system, but I've recently had a moment of clarity and discussed a bit on IRC with Aslak earlier.
The thing is that storage engines aren't as interesting to the user as export format options.
For instance:
JavaArchive archive = ArchiveFactory.createJavaArchive("name.jar")
The above creates a Java container view, backed by default storage archive. The storage impl isn't important. It could be MemoryMap for the time being. What's nice about this is that the user doesn't care about the storage engine and just gets the view they want.
But what *is* important is an "export" option. After the user is done mucking around and adding resources, classes, and the like, he'll want to deploy it.
At this point the deployment tools can:
InputStream in = ZipExporter.exportZip(archive);
...obtaining the InputStream of a real JAR. In the case of Embedded, this gets passed into deployment and AS never knows that an archive was used at all. Or a user can serialize the thing to disk and make an actual JAR file. Alternatively:
File file = ExplodedExporter.exportExploded(archive,File parent);
...to obtain the root of an exploded representation.
So the shift in approach I'm proposing is that storage engines aren't as important as how archives are exported. We can process the add(), contains(), delete(), etc operations however are most efficient, and only when the user is done does he want some real view of it.
WDYT?
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251927#4251927
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251927
15 years, 4 months
[JBoss ESB Development] - How to configure webservice security for a Service exposed t
by ismail.seyfi@definitivelogic.com
I have a simple service that is exposed as a web service. I have a remote web application that submits a simple soap message to this end point. My service exposed through contract definition. I specified my actions mep to be RequestResponse. I then provided in/out xml schemas. The client is able to submit a sop request to this and get a response back.
What I want to do is integrate security into set up. I want to do the simplest possible scenario a the moment. I modified my soap message to contain a UsernameToken header. I modified my service definition to contain the security module. When I deploy this setting, I get an exception about AuthenticationRequest not being set in the SEcurityContext in the Message. I guess this is happening because I do not have a gateway set up and I am not using ServiceInvoker directly within my actions.
With the set up I have is it possible for me to integrate Security? If so how? If not do i need to have a gateway? jbr http?
thanks in advance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251850#4251850
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251850
15 years, 4 months