[Design of JBoss Tools (dev)] - Re: Incorporate Hibernate Search into Hibernate Tools idea
by vyemialyanchyk
anonymous wrote : You could do something like use meta attributes that hibernate tools support to annotate which things you want to be searched and users can then either use reveng.xml to indicate which fields needs indexing or use a programmatic strategy to compute it.
This is seems be better. I have a smattering knowledge of Hibernate Search.
anonymous wrote : So if the generation is pretty simplistic (i.e. nothing fancy) then it could be integrated into reverse engineering/code generation but not sure if its really useful/will be used.
I think it could be usefull.
anonymous wrote : What other good index search tools are there and why should we generalize them ? Hibernate only support many db's because the db's has a common language (SQL, tables, rows, columns,..). Index search tools doesn't afaik...and again - why not just focus on Lucene ?
This is could be a topic for a long discussion... In a general case - index search tool consist of index (analog of DB) for some documents/items, and query in a common case is just a string (Lucene generalize this, but in common case this is just a string) - no SQL just a string in a common case (of cause it is possible to use some preconditioning). What does mean a good index tool? There are many parameters here as portability, index speed, search speed, maximum number of documents in index, relevancy of results, simplicity to configure, etc. I have to test a lot of index tools cause this is intresting question for me. Lucene is a most famous, it has a god infrastructure and many projects use it, but it is not the best for all parameters which I describe above. I will not admit some other index search tool - cause this is not a main topic here, but I admit that there are others, and possibility to select is a greate posibility for the user, for developer. "focus on Lucene?" why not :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203377#4203377
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203377
17 years, 2 months
[Design of EJB 3.0] - Re: Versioning
by ALRubinger
So there's 2 issues we're discussing:
1) How to model releases in JIRA
2) Are GA dependencies a prereq for a GA release?
Regarding JIRA, we've discussed the following:
* Rename ejb3-as-int to ejb3-project. This defines the components used in a release, and its version becomes the "Release Version".
* Create ejb3-as5-int, ejb3-as6-int outside the scope of projects/ejb3 and under something like projects/ejb3-as-int. These bring in ejb3-project and also add target-specific configs. They are what's brought into AS.
* Add a field for "Fix Component Version" to denote what version of a component has the fix (ie, ejb3-proxy:1.0.0-GA would be a valid value)
I think we're still debating the qualifier issue. Since this morning I hold firm in my previous arguments.
Carlo has brought up that "GA" means "supported". We don't support any community releases (this is for EAP). And we also don't dictate when EAP is released, so there's nothing blocking someone wanting to adopt a Beta-level component into the platform. Once its there, we have to support it.
So I use "GA" to mean "mature" (==stable, feature-complete, tested). And I'm happier applying that label to the whole of EJB3, not to the individual components which comprise it.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203344#4203344
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203344
17 years, 2 months
[Design of OSGi Integration] - Re: Current roadmap
by alesj
"david.lloyd(a)jboss.com" wrote :
| Manifests (even OSGi Manifests) are dead simple to parse - you could just do it with plain regular expressions even - and the metadata model can't be all that complex. I don't see anything in the OSGi spec to make be believe otherwise, in any case.
|
If it's that simple I would be more than happy if you could do it. ;-)
I don't doubt it's not doable via regexp (I did part of my BSc thesis on them ;-),
but I very much doubt it's gonna be nice at the end.
Hence javacc or possibly antlr usage -- keeping the parsing in rule files.
The stuff that get's ugly is imports/exports.
With its attributes, =, :=, :, [, ", ... details.
I never know which goes where. :-)
The metadata should be simple,
it just takes some effort to go from feature to feature
and create proper parsing --> osgi md --> jboss cl md tests.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203332#4203332
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203332
17 years, 2 months
[Design of POJO Server] - Re: JBAS-6061 or weird nested jar
by alesj
"jaikiran" wrote : I added a new test to the existing testcase org.jboss.test.virtual.test.ExceptionHandlerTestCase. Does this look good enough?
|
Aha, I see where the problem is.
It's this lines:
(*)
| URL jarFileURL = getResource("/vfs/test/zipeinit.jar");
| VFS jarFileVFS = VFS.getVFS(jarFileURL);
| VirtualFile root = jarFileVFS.getRoot();
|
as you're by-passing previous cached root.
| VFS parentFolderVFS = VFS.getVFS(parentFolderURL); // <-- CACHED HERE
|
We need to fix the code (btw: where is this?) that does this,
to use the right VFS method, the one that uses cache.
(*) should be re-written to use this:
| URL jarFileURL = getResource("/vfs/test/zipeinit.jar");
| VirtualFile root = VFS.getCachedFile(jarFileURL);
|
"jaikiran" wrote :
| P.S: I think there is a typo in this existing testcase:
| // Jaikiran: Is this a typo? Or is this intentional? The _sqljdbc.jar should be sqljdbc.jar isn't it?
| |
It doesn't matter actually.
With '_' it's just more precise on the fact that it matches only true temp names.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203311#4203311
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203311
17 years, 2 months
[Design of POJO Server] - Re: JBAS-6061 or weird nested jar
by jaikiran
I added a new test to the existing testcase org.jboss.test.virtual.test.ExceptionHandlerTestCase. Does this look good enough?
Index: src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java
| ===================================================================
| --- src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java (revision 83104)
| +++ src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java (working copy)
| @@ -25,10 +25,12 @@
| import java.util.List;
|
|
|
| import junit.framework.Test;
|
| +
|
| import org.jboss.virtual.VFS;
|
| import org.jboss.virtual.VirtualFile;
|
| import org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler;
|
|
|
| +
|
| /**
|
| * ExceptionHandlerTestCase.
|
| *
|
| @@ -57,4 +59,29 @@
| List<VirtualFile> children = child.getChildren();
|
| assertTrue(children.isEmpty());
|
| }
|
| +
|
| + /**
|
| + * Cover the parent folder containing the jar with a {@link ExceptionHandler}
|
| + * and then try to load the jar (present in the parent folder) to test
|
| + * whether the exceptionhandler is applied to the child jar as well
|
| + *
|
| + * @throws Exception
|
| + */
|
| + public void testExceptionHandlerForJarFiles() throws Exception
|
| + {
|
| + // Set a exception handler on parent folder
|
| + URL parentFolderURL = getResource("/vfs/test");
|
| + VFS parentFolderVFS = VFS.getVFS(parentFolderURL);
|
| + // let's add the sqljdbc.jar to the list of names that the exception handler has to handle
|
| + parentFolderVFS.setExceptionHandler(new NamesExceptionHandler("sqljdbc.jar"));
|
| +
|
| + // Now let's create a VFS for the child jar
|
| + URL jarFileURL = getResource("/vfs/test/zipeinit.jar");
|
| + VFS jarFileVFS = VFS.getVFS(jarFileURL);
|
| + VirtualFile root = jarFileVFS.getRoot();
|
| + // time to access the messed up jar file. The NamesExceptionHandler is expected to handle this.
|
| + VirtualFile child = root.findChild("sqljdbc.jar");
|
| + List<VirtualFile> children = child.getChildren();
|
| + assertTrue(children.isEmpty());
|
| + }
|
| }
|
|
This one reproduces the error:
-------------------------------------------------------------------------------
| Test set: org.jboss.test.virtual.test.ExceptionHandlerTestCase
| -------------------------------------------------------------------------------
| Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.132 sec <<< FAILURE!
| testExceptionHandlerForJarFiles(org.jboss.test.virtual.test.ExceptionHandlerTestCase) Time elapsed: 0.016 sec <<< ERROR!
| java.lang.RuntimeException: Failed to read zip file: org.jboss.virtual.plugins.context.zip.ZipFileWrapper@1c74f37 - /tmp/vfs-nested.tmp/65e546ff_sqljdbc.jar
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:570)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:700)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChildren(ZipEntryContext.java:772)
| at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChildren(ZipEntryHandler.java:149)
| at org.jboss.virtual.plugins.context.DelegatingHandler.getChildren(DelegatingHandler.java:120)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:171)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:288)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
| at org.jboss.virtual.VFS.visit(VFS.java:429)
| at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:423)
| at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:372)
| at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:353)
| at org.jboss.test.virtual.test.ExceptionHandlerTestCase.testExceptionHandlerForJarFiles(ExceptionHandlerTestCase.java:84)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:154)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
| at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:163)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:84)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:261)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:875)
| Caused by: java.util.zip.ZipException: error in opening zip file
| at java.util.zip.ZipFile.open(Native Method)
| at java.util.zip.ZipFile.<init>(ZipFile.java:203)
| at java.util.zip.ZipFile.<init>(ZipFile.java:234)
| at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
| at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.acquire(ZipFileWrapper.java:245)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.initEntries(ZipEntryContext.java:466)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:561)
| ... 35 more
|
I haven't commited the test since i am not sure what's the policy on commiting (without a fix) failing/error testcases.
P.S: I think there is a typo in this existing testcase:
// Jaikiran: Is this a typo? Or is this intentional? The _sqljdbc.jar should be sqljdbc.jar isn't it?
| vfs.setExceptionHandler(new NamesExceptionHandler("_sqljdbc.jar"));
| VirtualFile root = vfs.getRoot();
| VirtualFile zipeinit = root.findChild("zipeinit.jar");
| VirtualFile child = zipeinit.findChild("sqljdbc.jar");
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203300#4203300
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203300
17 years, 2 months
[Design of JBoss jBPM] - Re: decision conditions
by salaboy21
if you see the class Decision.java you should see the last lines:
| if (transition==null) {
| transition = getDefaultLeavingTransition();
| log.debug("decision didn't select transition, taking default "+transition);
| }
|
| // since the decision node evaluates condition expressions, the condition of the
| // taken transition will always be met. therefor we can safely turn off the
| // standard condition enforcement in the transitions after a decision node.
| transition.removeConditionEnforcement();
|
| } catch (Exception exception) {
| raiseException(exception, executionContext);
| }
|
| log.debug("decision "+name+" is taking '"+transition+"'");
| executionContext.leaveNode(transition);
|
that means that if no transition is elected then the defaultTransition is taken.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203299#4203299
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203299
17 years, 2 months