You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -31,9 +31,9 @@ CAP Java 3.0 increased some minimum required versions:
31
31
32
32
| Dependency | Minimum Version |
33
33
| --- | --- |
34
+
| Cloud SDK | 5.9.0 |
34
35
|@sap/cds-dk| ^7 |
35
36
| Maven | 3.6.3 |
36
-
| Cloud SDK | 5.9.0 |
37
37
38
38
CAP Java 3.0 no longer supports @sap/cds-dk ^6.
39
39
@@ -46,6 +46,19 @@ If you are using the root path `/` for a readiness or liveness probe in Kyma you
46
46
47
47
[Learn more about the Production Profile.](developing-applications/configuring#production-profile){.learn-more}
48
48
49
+
### Removed MTX Classic Support
50
+
51
+
Support for classic MTX (@sap/cds-mtx) has been removed. Using streamlined MTX (@sap/cds-mtxs) is mandatory for multitenancy.
52
+
If you're still using MTX Classic refer to the [multitenancy migration guide](../guides/multitenancy/old-mtx-migration).
53
+
54
+
In addition, the deprecated `MtSubscriptionService` API, has been removed. It has now been superseeded by the `DeploymentService` API.
55
+
As part of this change the compatibility mode for the `MtSubscriptionService` API has been removed. Besides the removal of the Java APIs this includes the following behavioural changes:
56
+
57
+
- During unsubscribe, the tenant's content (like HDI container) is now deleted by default when using the new `DeploymentService` API.
58
+
- The HTTP-based tenant upgrade APIs provided by the CAP Java app have been removed, use the [`Deploy` main method](/java/multitenancy#deploy-main-method) instead. This includes the following endpoints:
59
+
-`/mt/v1.0/subscriptions/deploy/**` (GET & POST)
60
+
-`/messaging/v1.0/em/<tenant>` (PUT)
61
+
49
62
### Removed feature `cds-feature-xsuaa`
50
63
51
64
The feature `cds-feature-xsuaa` has been removed. Support for XSUAA and IAS has been unified under the umbrella of `cds-feature-identity`.
@@ -59,18 +72,13 @@ If you have customized the security configuration, you need to adapt it to the n
59
72
[Learn more about the security configuration.](./security#xsuaa-ias){.learn-more}
60
73
[Learn more about migration to SAP´s `spring-security` library.](https://github.com/SAP/cloud-security-services-integration-library/blob/main/spring-security/Migration_SpringXsuaaProjects.md)
61
74
62
-
### Removed MTX Classic Support
75
+
### Proof-Of-Possession enforced for IAS-based authentication
63
76
64
-
Support for classic MTX (@sap/cds-mtx) has been removed. Using streamlined MTX (@sap/cds-mtxs) is mandatory for multitenancy.
65
-
If you're still using MTX Classic refer to the [multitenancy migration guide](../guides/multitenancy/old-mtx-migration).
77
+
In IAS scenarios, the [Proof-Of-Possession](https://github.com/SAP/cloud-security-services-integration-library/tree/main/java-security#proofofpossession-validation) is now enforced by default for incoming requests for versions starting from `3.5.1` of the [SAP BTP Spring Security Client](https://github.com/SAP/cloud-security-services-integration-library/tree/main/spring-security).
66
78
67
-
In addition, the deprecated `MtSubscriptionService` API, has been removed. It has now been superseeded by the `DeploymentService` API.
68
-
As part of this change the compatibility mode for the `MtSubscriptionService` API has been removed. Besides the removal of the Java APIs this includes the following behavioural changes:
79
+
Because of this, applications calling a CAP Java application will need to send a valid client certificate in addition to the JWT token. In particular, applications using an Approuter have to set `forwardAuthCertificates: true` on the Approuter destination pointing to your CAP backend.
69
80
70
-
- During unsubscribe, the tenant's content (like HDI container) is now deleted by default when using the new `DeploymentService` API.
71
-
- The HTTP-based tenant upgrade APIs provided by the CAP Java app have been removed. This includes the following endpoints:
72
-
-`/mt/v1.0/subscriptions/deploy/**` (GET & POST)
73
-
-`/messaging/v1.0/em/<tenant>` (PUT)
81
+
[Learn more about Proof-Of-Possession.](./security.md#proof-of-possession){.learn-more}
74
82
75
83
### Lazy Localization by default
76
84
@@ -100,10 +108,60 @@ Some parameter defaults of the goal `generate` have been adjusted:
100
108
| Parameter | Old Value | New Value | Explanation |
101
109
| --- | --- | --- | --- |
102
110
|`sharedInterfaces`|`false`|`true`| Interfaces for global arrayed types with inline anonymous type are now generated exactly once. `sharedInterfaces` ensures such types are not generated as inline interfaces again, if used in events, actions or functions. |
103
-
|`uniqueEventContexts`|`false`|`true`| Determines whether the event context interfaces should be unique for bound actions and functions. |
111
+
|`uniqueEventContexts`|`false`|`true`| Determines whether the event context interfaces should be unique for bound actions and functions, by prefixing the interfaces with the entity name. |
104
112
105
113
Both these changes result in the generation of incompatible POJOs. To get the former POJOs, the new defaults can be overwritten by setting the parameters to the old values.
106
114
115
+
Consider the following example:
116
+
117
+
```cds
118
+
service MyService {
119
+
entity MyEntity {
120
+
key ID: UUID
121
+
} actions {
122
+
// bound action
123
+
action doSomething(values: MyArray);
124
+
}
125
+
}
126
+
127
+
// global arrayed type
128
+
type MyArray: many {
129
+
value: String;
130
+
}
131
+
```
132
+
133
+
With the new defaults the generated interface for the `doSomething` action looks like this:
134
+
135
+
```java
136
+
// uniqueEventContexts: true =>
137
+
// interface is prefixed with entity name "MyEntity"
// sharedInterfaces: false => global MyArray type is not used,
155
+
// instead an additional interface Values is generated inline
156
+
Collection<Values>getValues();
157
+
voidsetValues(Collection<Values>values);
158
+
159
+
interfaceValuesextendsCdsData {
160
+
// ...
161
+
}
162
+
}
163
+
```
164
+
107
165
### Adjusted Property Defaults
108
166
109
167
Some property defaults have been adjusted:
@@ -113,7 +171,7 @@ Some property defaults have been adjusted:
113
171
|`cds.remote.services.<key>.http.csrf.enabled`|`true`|`false`| Most APIs don't require CSRF tokens. |
114
172
|`cds.sql.hana.optimizationMode`|`legacy`|`hex`| SQL for SAP HANA is optimized for the HEX engine. |
115
173
|`cds.odataV4.lazyI18n.enabled`|`null`|`true`| Lazy localization is now enabled by default in multitenant scenarios. |
116
-
|`cds.auditLog.personalData.throwOnMissingDataSubject`|`false`|`true`| Raise errors for incomplete personal data annotations by default. |
174
+
|`cds.auditLog.personalData.`<br>`throwOnMissingDataSubject`|`false`|`true`| Raise errors for incomplete personal data annotations by default. |
117
175
|`cds.messaging.services.<key>.structured`|`false`|`true`|[Enhanced message representation](./messaging.md#enhanced-messages-representation) is now enabled by default. |
118
176
119
177
### Adjusted Property Behavior
@@ -122,6 +180,38 @@ Some property defaults have been adjusted:
122
180
| --- | --- |
123
181
|`cds.outbox.persistent.enabled`| When set to `false`, all persistent outboxes are disabled regardless of their specific configuration. |
124
182
183
+
### Removed Properties
184
+
185
+
The following table gives an overview about the removed properties:
|`cds.security.mock.users.<key>.unrestricted`| Special handling of unrestricted attributes has been removed, in favor of [explicit modelling](../guides/security/authorization#unrestricted-xsuaa-attributes). |
|`cds.multiTenancy.compatibility.enabled`| MtSubscriptionService API [has been removed](#removed-mtx-classic-support) and compatibility mode is no longer available. |
|`cds.sql.supportedLocales`| All locales are supported by default for localized entities, as session variables can now be leveraged on all databases. |
214
+
125
215
### Deprecated Session Context Variables
126
216
127
217
| Old Variable | Replacement |
@@ -130,38 +220,6 @@ Some property defaults have been adjusted:
130
220
|`$at.from`|`$valid.from`|
131
221
|`$at.to`|`$valid.to`|
132
222
133
-
### Removed Properties
134
-
135
-
The following table gives an overview about the removed properties:
|`cds.multiTenancy.compatibility.enabled`|| MtSubscriptionService API [has been removed](#removed-mtx-classic-support) and compatibility mode is no longer available. |
|`cds.security.mock.users.<key>.unrestricted`|| Special handling of unrestricted attributes has been removed, in favor of [explicit modelling](../guides/security/authorization#unrestricted-xsuaa-attributes). |
|`cds.sql.supportedLocales`|| All locales are supported by default for localized entities, as session variables can now be leveraged on all databases. |
@@ -197,17 +255,9 @@ The following table gives an overview about the removed properties:
197
255
198
256
The goal `addSample` from the `cds-maven-plugin` has been removed. Use the new goal `add` with the property `-Dfeature=TINY_SAMPLE` instead.
199
257
200
-
### Proof-Of-Possession enforced for IAS-based authentication
201
-
202
-
In IAS scenarios, the [Proof-Of-Possession](https://github.com/SAP/cloud-security-services-integration-library/tree/main/java-security#proofofpossession-validation) is now enforced by default for incoming requests for versions starting from `3.5.1` of the [SAP BTP Spring Security Client](https://github.com/SAP/cloud-security-services-integration-library/tree/main/spring-security).
203
-
204
-
Because of this, applications calling a CAP Java application will need to send a valid client certificate in addition to the JWT token. In particular, applications using an Approuter have to set `forwardAuthCertificates: true` on the Approuter destination pointing to your CAP backend.
205
-
206
-
[Learn more about Proof-Of-Possession.](./security.md#proof-of-possession){.learn-more}
207
-
208
258
## Cloud SDK 4 to 5 { #cloudsdk5 }
209
259
210
-
CAP Java `2.6.0` and higher is compatible with Cloud SDK in version 4 and 5. For reasons of backward compatibility, CAP Java assumes Cloud SDK 4 as the default. However, we highly recommend that you use at least version `5.7.0` of Cloud SDK. If you relied on the Cloud SDK integration package (`cds-integration-cloud-sdk`), you won't need to adapt any code to upgrade your CAP Java application to Cloud SDK 5. In these cases, it's sufficient to add the following maven dependency to your CAP Java application:
260
+
CAP Java `2.6.0` and higher is compatible with Cloud SDK in version 4 and 5. For reasons of backward compatibility, CAP Java assumes Cloud SDK 4 as the default. However, we highly recommend that you use at least version `5.9.0` of Cloud SDK. If you relied on the Cloud SDK integration package (`cds-integration-cloud-sdk`), you won't need to adapt any code to upgrade your CAP Java application to Cloud SDK 5. In these cases, it's sufficient to add the following maven dependency to your CAP Java application:
0 commit comments