copilot-setting: Instructions file for GitHub Copilot

XML Configuration Conventions

Conventions for Spring XML config (applicationContext*.xml), Hibernate hbm.xml mappings, and Maven POM files. Transaction management rules: instructions/spring-hibernate.instructions.md.

Spring XML

• One config file per concern (e.g., applicationContext-dao.xml, applicationContext-service.xml)
• Bean IDs: camelCase, descriptive (orderService, transactionManager)
• Transaction: <tx:advice> + <aop:config> on service layer — see instructions/spring-hibernate.instructions.md
• Transaction manager bean is org.springframework.orm.hibernate4.HibernateTransactionManager with the sessionFactory from org.springframework.orm.hibernate4.LocalSessionFactoryBean — the hibernate3 package and DataSourceTransactionManager both leave the Session unbound, so every getCurrentSession() throws
• A <tx:advice> with no <aop:config><aop:advisor advice-ref="..."/> is inert: nothing auto-proxies a bare advice, the context starts clean with no warning, and every service method runs non-transactional. An advisor whose pointcut matches nothing fails the same silent way — verify by observing a rollback, not by reading the XML
• <tx:method>: read-only="true" for get* / find* / list* / count*, and rollback-for on any method that throws a checked exception — without it Spring commits the transaction the service threw to abort (instructions/spring-hibernate.instructions.md)
• A test-scoped context declares its own dataSource — never point it at the live database: test-class @Transactional auto-rollback does not cover DDL or anything a stored procedure commits

Spring Security XML

Spring Security 3.2 predates the 4.0 secure-by-default flip. Every rule here is a default a 4.x-trained model assumes it does not have to write.

• <csrf/> and <headers/> are both off unless declared inside <http> (4.0 turned both on by default) — omit them and the app has neither CSRF protection nor security headers, with no error. The 3.2 XSD has no disabled attribute on <csrf>, so a <csrf disabled="true"/> copied from 4.x fails schema validation
• A bare <headers/> installs the full 3.2 default set (nosniff, X-Frame-Options: DENY, X-XSS-Protection, cache-control, HSTS on HTTPS). Adding any child element replaces the whole set rather than extending it — <headers><frame-options policy="SAMEORIGIN"/></headers> silently drops the other four; list every header you still want. 4.0's defaults-disabled attribute does not exist in 3.2
• <http use-expressions="true"> is required before any access="hasRole(...)" — 3.2 defaults it to false (4.0 flipped it), and without it the expression is parsed as a literal config attribute that no voter supports, aborting context startup with IllegalArgumentException: Unsupported configuration attributes
• hasRole('X') in 3.2 matches the granted authority exactly and adds no ROLE_ prefix (4.0 introduced the prefixing) — write hasRole('ROLE_ADMIN'). This one fails silently: the user holding ROLE_ADMIN is simply denied with a 403, no startup error and nothing in the log
• Password encoding: <password-encoder hash="bcrypt"/> under <authentication-provider> (needs spring-security-crypto); never pair it with <salt-source> — bcrypt salts internally and the parser rejects the combination outright (instructions/security.instructions.md)
• Force HTTPS with one mechanism, not both: <intercept-url requires-channel="https"/> here, or <transport-guarantee>CONFIDENTIAL</transport-guarantee> in web.xml. Behind a TLS-terminating proxy either one loops redirects unless Tomcat's RemoteIpValve is configured