[Design of JBoss Build System] - Re: maven-buildmagic-thirdparty-plugin won't pickup source f
by scott.stark＠jboss.org
Ok, I'm still seeing some sources be excluded. For example, the org.jboss.aop sources:
| [537][valkyrie: thirdparty]$ mvn -Pdownload-sources package
| ...
| [INFO] Scanning for projects...
| WAGON_VERSION: 1.0-beta-2
| [INFO] ------------------------------------------------------------------------
| [INFO] Building JBoss Application Server Thirdparty Build
| [INFO] task-segment: [package]
| [INFO] ------------------------------------------------------------------------
| [INFO] snapshot org.jboss.cache:jbosscache-support:1.3-SNAPSHOT: checking for updates from repository.jboss.org
| [INFO] snapshot org.jboss.cache:jbosscache-support:1.3-SNAPSHOT: checking for updates from snapshots.jboss.org
| [INFO] [dependency:sources {execution: download-sources}]
| [INFO]
| [INFO] The following files have been resolved:
| [INFO] none
| [INFO]
| [INFO] The following files where skipped:
| [INFO] ant:ant:java-source:sources:1.6.5
| ...
| [INFO] org.jboss.aop:jboss-aop-as4-deployer:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jboss-aop-deployer-jdk50:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jboss-aop-jboss4-jdk50:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jboss-aop-jdk50:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jboss-aop-jdk50-client:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jboss-standalone-aspect-library-jdk50:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:jrockit-pluggable-instrumentor:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:pluggable-instrumentor:java-source:sources:2.0.0.CR9
| [INFO] org.jboss.aop:resources:java-source:sources:2.0.0.CR9
| ...
| [INFO] [source:jar {execution: attach-sources}]
| [INFO] ------------------------------------------------------------------------
| [INFO] BUILD SUCCESSFUL
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 15 seconds
| [INFO] Finished at: Thu May 22 07:00:06 PDT 2008
| [INFO] Final Memory: 26M/47M
| [INFO] ------------------------------------------------------------------------
| [536][valkyrie: thirdparty]$ !ls
| ls jboss/aop/lib/
| jboss-aop-as4-deployer.jar
| jboss-aop-deployer-jdk50.jar
| jboss-aop-jboss4-jdk50.jar
| jboss-aop-jdk50-client.jar
| jboss-aop-jdk50.jar
| jboss-standalone-aspect-library-jdk50.jar
| jrockit-pluggable-instrumentor.jar
| pluggable-instrumentor.jar
| [537][valkyrie: thirdparty]$
|
What controls this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152705#4152705
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152705
17 years, 10 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by jhalliday
OK, I'm inclined to go with the XAResourceRecovery / XAResourceRecoveryRegistry outlined above for now and see how it works out. Changes to the contents of the array of resources between recovery passes may cause problems, but we'll revisit that if it does. I think it's more likely that the array will contain just a single resource in most cases though.
I also prefer to avoid a lifecycle for resources e.g. 'close()'. The existing recovery mechanism in JBossTS has lifecycle issues so I'm tending towards a stateless design at the moment if only because anything different is good :-) If a connector needs to clean up a resource for some reason it can just unregister and re-register. Short of stopping the recovery process, there is no reason why the transaction manager would ever be done with a resource. As long as the transaction server is alive it should keep querying periodically to see if there are any new problems. Paranoia is a good thing.
Adrian, I've checked in the new interface files to the integration trunk. Please look them over, modify if you wish and put out a new integration module release if you have time. Otherwise I'll try and figure out how to do it tomorrow.
http://jira.jboss.com/jira/browse/JBAS-5541
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152685#4152685
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152685
17 years, 10 months
[Design of EJB 3.0] - Re: EJBTHREE-1062 and metadata
by ALRubinger
"emuckenhuber" wrote : But shouldn't metadata validate and fail when parsing the example above?
No, why would it fail?
"emuckenhuber" wrote : Which would be ok as the return type of the RemoteHome extends EJBObject - it would just set MyStateful as Remote interface - and @Remote will be more or less ignored.
| Is that ok / the expected behaviour?
I think we should introduce another fail-fast and validate @Remote as the spec intends - for use in business remotes only. To allow EJB2.x Remotes in there is redundant and confusing. For this we'll need consensus from the other devs.
Also note that the IllegalArgumentException you show should reference the spec and give a more clear error message than that given. Can't add x because of y says Spec z. :)
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152674#4152674
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152674
17 years, 10 months
[Design the new POJO MicroContainer] - Re: EAR structure mock scanning
by alesj
"alesj" wrote :
| OK, I'll try to extract my previous code - or see if it can be directly reused - to add ear scanning for javaee annotations.
| Or even generic for structure deployers as well.
Wow, this even surprised me.
The code is completely generic *already*. :-)
I just needed to change a single modifier into public - which I don't see why I didn't have it before - and all the code is there. ;-)
| private void scanEar(VirtualFile root, List<EarModule> modules) throws IOException
| {
| ClassLoader classLoader = getClass().getClassLoader();
| GenericAnnotationResourceVisitor visitor = new GenericAnnotationResourceVisitor(classLoader);
| ClassFilter included = null;
| ClassFilter excluded = null;
| ResourceFilter filter = visitor.getFilter();
| List<VirtualFile> children = root.getChildren();
| for (VirtualFile child : children)
| {
| VFSResourceVisitor.visit(new VirtualFile[]{child}, included, excluded, classLoader, visitor, filter);
| AnnotationEnvironment env = visitor.getEnv();
| Set<Class<?>> statelessClasses = env.classIsAnnotatedWith(Stateless.class);
| // logic here ...
| // mark module as EJB3, ...
| }
|
So, someone needs to explain me now what is the logic behind JEE annotations and how the modules are marked.
e.g. what annotations mark some type (OK, I know the EJB3 one's, but have no clue about the others)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152659#4152659
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152659
17 years, 10 months
[Design of POJO Server] - Re: JBVFS-26 - Optimizing the VFS PathTokenizer
by alesj
"adrian(a)jboss.org" wrote :
| 1) If StringTokenizer was replaced with an optimized lexer
| (e.g. like the one used to parse system property references from strings in common-core)
| then the check for an empty token could be done inline instead of string
| comparison.
|
This is now rewritten into this:
| public static String[] getTokens(String path)
| {
| if (path == null)
| throw new IllegalArgumentException("Null path");
|
| char[] chars = path.toCharArray();
| StringBuilder buffer = new StringBuilder();
| List<String> list = new ArrayList<String>();
| String specialToken = null;
|
| for (int index=0; index < chars.length; index++)
| {
| char ch = chars[index];
|
| if (ch == '/')
| {
| if (index > 0)
| {
| if (buffer.length() == 0 && specialToken == null)
| throw new IllegalArgumentException("A path element is empty: " + path);
|
| if (specialToken != null)
| list.add(specialToken);
| else
| list.add(buffer.toString());
|
| // reset
| buffer.setLength(0);
| specialToken = null;
| }
| }
| else if (ch == '.')
| {
| if (specialToken == null && buffer.length() == 0)
| specialToken = CURRENT_PATH;
| else if (specialToken == CURRENT_PATH && buffer.length() == 0)
| specialToken = REVERSE_PATH;
| else
| buffer.append(ch);
| }
| else
| {
| buffer.append(ch);
| }
| }
|
| // add last token
| if (specialToken != null)
| list.add(specialToken);
| else if (buffer.length() > 0)
| list.add(buffer.toString());
|
| return list.toArray(new String[list.size()]);
| }
|
and we do '==' check on special tokens. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152637#4152637
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152637
17 years, 10 months