[JBoss JIRA] (JBDS-2641) jboss-deployment-structure file validation problem
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/JBDS-2641?page=com.atlassian.jira.plugin.... ]
Joshua Wilson commented on JBDS-2641:
-------------------------------------
I just found that if you use `<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:2.0">` it works.
> jboss-deployment-structure file validation problem
> --------------------------------------------------
>
> Key: JBDS-2641
> URL: https://issues.jboss.org/browse/JBDS-2641
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Beta1
> Reporter: Tomas Remes
> Fix For: 7.0.0.Beta2
>
>
> E.g. try to create new Seam2.3 project. There will be created jboss-deployment-structure.xml descriptor in WebContent/WEB-INF directory. Notice the following error:
> {noformat}
> vc-complex-type.2.4.a: Invalid content was found starting with element 'deployment'. One of '{ear-subdeployments-isolated, deployment, sub-deployment, module}' is expected. jboss-deployment-structure.xml /testproject/WebContent/WEB-INF line 2 XML Problem
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (JBIDE-14629) Errors when creating and deploying seam2 project with Seam 2.3.Final
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14629?page=com.atlassian.jira.plugi... ]
Joshua Wilson commented on JBIDE-14629:
---------------------------------------
I just found that if you use `<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:2.0">` it works.
> Errors when creating and deploying seam2 project with Seam 2.3.Final
> ---------------------------------------------------------------------
>
> Key: JBIDE-14629
> URL: https://issues.jboss.org/browse/JBIDE-14629
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.1.0.Beta1
> Environment: JBDS 7.0.0.Beta1-v20130519-0601-B206 with bundled JBoss EAP 6.1.0.Beta1
> Reporter: Vlado Pakan
> Assignee: Alexey Kazakov
> Fix For: 4.1.1.Final
>
> Attachments: seamerror.png
>
>
> ERROR: DefaultDS Database connection is defined with incorrect link to hsqldb.jar file with JDBC driver for HSQLDB.
> 1. Fix DefaultDS Database connection definition
> ASSERT: It's possible to connect to DefaultDS
> 2. Create new seam project with bundled JBoss EAP and JBoss Seam 2.3.Final
> ERROR: There is error in Problems view:
> !seamerror.png!
> 3. Start seam project on server
> ERROR: This error appear in Server log. Application is not deployed:
> {noformat}
> 3:58:45,950 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016012: Deployment deployment "seam.war" contains CDI annotations but beans.xml was not found.
> 13:58:46,430 INFO [org.jboss.as.server] (ServerService Thread Pool -- 26) JBAS018559: Deployed "seam-ds.xml" (runtime-name : "seam-ds.xml")
> 13:58:46,430 INFO [org.jboss.as.server] (ServerService Thread Pool -- 26) JBAS018559: Deployed "seam.war" (runtime-name : "seam.war")
> 13:58:46,431 INFO [org.jboss.as.server] (ServerService Thread Pool -- 26) JBAS018559: Deployed "hsqldb.jar" (runtime-name : "hsqldb.jar")
> 13:58:46,436 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.jdbc-driver.hsqldb_jar (missing) dependents: [service jboss.data-source.java:/seamDatasource]
> {noformat}
> Is this supported scenario?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (JBIDE-12860) JAX-RS validation problems are not linked
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12860?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-12860:
----------------------------------------
The reason of this issue is in the way how WST validation builder creates/uses IWorkbenchContext.
When you create/change any resource in the project the very first time then a new IWorkbenchContext is created and stored for the project.
We use this context to collect all the changed resources (created, modified, removed).
But when WST run validator jobs then it creates a new IWorkbenchContext instead of using the context used for collecting changed resources.
It doesn't matter how many time you change your resources. WST will use the same instance of IWorkbenchContext for entire Eclipse session and will use this instance to register changed resources. But WST will create a new instance of IWorkbenchContext every time it runs a validation job.
So It does not make sense.
How it affects us:
1. When you create a plain wst project then a new IWorkbenchContext is created. This instance will be used to register changed resources until you close the Eclipse.
JAX-RS validator (or any other CommonValidator extension) is ignored since JAX-RS is not enabled yet.
2. JAX-RS support is enabled. WST invokes a CommonValidatorManager job but provide a new instance of IWorkbenchContext. CommonValidatorManager creates a new JAX-RS validator (it's now enabled) and add it to the provided IWorkbenchContext instance. We already knew that IWorkbenchContext is created every time a validator job is invoked. So we keep all sensitive information in our own context which is provided by validator. But we the validator does not have access to the IWorkbenchContext created in the step #1 so it will never get the list of removed files.
It would work if WST created a new IWorkbenchContext every time it register changed resources and invokes validation jobs. Or if it used the same instance for every use.
But this weird mixture of different approaches is a pain.
We have already spent so much time on debugging WST validation and adopting our CommonValidation to every weird behaviour/bugs of WST that we made an ugly monster out of our CommonValidation which is hard to support and extend. We should have created in the first place our own independent validation builder instead of using WST. It would be much easier.
Now I'm going to fix this problem by refactoring our extension of IWorkbenchContext. We have to initialize validators every time the any instance of IWorkbenchContext is used. I hope it won't affect performance.
> JAX-RS validation problems are not linked
> -----------------------------------------
>
> Key: JBIDE-12860
> URL: https://issues.jboss.org/browse/JBIDE-12860
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.0.0.Beta1
> Reporter: Jaroslav Jankovič
> Assignee: Alexey Kazakov
> Labels: respin-b
> Fix For: 4.1.1.Beta1
>
>
> This case now fails:
> STEP: Create jaxrs problem with Application problem (Multiple application definition - one class extending Application and one application servlet definition in web.xml)
> STEP: comment servlet definition in web.xml
> ASSERT: problem marker in web.xml disappears
> ASSERT: problem marker in application class disappears
> FAIL: problem marker in application class doesn't disappear, because problem markers are not linked now -> project has to be built to correctly remove both problem markers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month